pliego de condiciones técnicas - … · pliego de condiciones técnicas 3/46 contenido...

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

Pliego de Condiciones Técnicas:

SOPORTE, ASISTENCIA FUNCIONAL Y TÉCNICA - CAU DE 2º NIVEL ESPECIALIZADO EN LAS TRAMITACIONES TELEMÁTICAS DEL DEPARTAMENTO.

Fecha: 08/02/2016 Referencia:

EJIE S.A.

Mediterráneo, 14

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y no puede ser utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato.

http://www.ejie.es/

Pliego de Bases Técnicas

Título de documento: SOPORTE, ASISTENCIA FUNCIONAL Y TÉCNICA - CAU DE 2º NIVEL ESPECIALIZADO EN LAS TRAMITACIONES TELEMÁTICAS DEL DEPARTAMENTO.

Histórico de versiones

Código:

Versión:

Fecha: 08/02/2016

Resumen de cambios:

Cambios producidos desde la última versión

Primera versión.

Control de difusión

Responsable: Ricardo Pereda

Firma: Fecha: 08/02/2016

Aprobado por: Patxi Ugarte

Firma: Fecha:

Referencias de archivo

Autor:

Nombre archivo:

Localización:

Pliego de Condiciones Técnicas 3/46

Contenido

Capítulo/sección Página

1 Introducción 5

2 Necesidad e idoneidad de la contratación 6

3 Objeto del contrato 7

3.1 Objeto y Alcance del Servicio 7

3.2 Descripción del Servicio 8

4 Duración del contrato 22

5 Presupuesto y valor estimado 23

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

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

Estilo 24

6.2 Metodología de pruebas 26

6.3 Modelo de aseguramiento de la calidad (SQA) 27

6.3.1. Plan SQA y actividades de aseguramiento de la calidad 28

6.4 Herramientas del ciclo de vida de las aplicaciones 28

6.5 Entorno Tecnológico 29

7 Configuración del Servicio 37

7.1 Organización del Equipo de Trabajo 37

7.1.1. Asignación de recursos a fases del proyecto 37

7.1.2. Equipo de Trabajo 37

7.2 Transferencia Tecnológica. 39

8 Mecanismos de Seguimiento, Control y Supervisión 40

8.1 Mecanismos de Seguimiento y Control. 40

8.2 Supervisión del proyecto 40

9 Modelo de facturación 41


10 Criterios de Adjudicación. 42

11 Finalización del servicio 45

12 Estructura y Formato de la Propuesta 46

12.1 Estructura normalizada y contenido de las

propuestas. 46


1 Introducción

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

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

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

Garantizar la interoperabilidad entre las distintas administraciones.

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

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

Aportando valor añadido.

Proporcionando soluciones competitivas.

Transmitiendo confianza a sus clientes.

Contando con personas cualificadas y comprometidas.

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

http://www.ejie.eus/


2 Necesidad e idoneidad de la contratación

Se pretende establecer un modelo operativo de atención a los usuarios externos de las aplicaciones web del departamento, que contemple el registro, atención de las incidencias, análisis, diagnóstico y resolución de las mismas. Con ello se aspira a aumentar el grado de uso y satisfacción de los usuarios de los servicios telemáticos proporcionados por el departamento.

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

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

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


3 Objeto del contrato

3.1 Objeto y Alcance del Servicio

El Departamento de Desarrollo Económico y Competitividad lleva unos años inmerso en un ambicioso proyecto de cambio interno que se sustenta fundamentalmente en tres pilares básicos:

La renovación de sus sistemas horizontales de tramitación por un nuevo núcleo de aplicativos (Gestor de expedientes, Gestor de ingresos, Escritorio, etc.) orientados a la digitalización completa de la información y a la transmisión electrónica de la misma, tanto a nivel externo (con ciudadanos y otros organismos de la administración), como interno (con generación e intercambio de documentos en formato electrónico).

La renovación progresiva de los diferentes Registros y Censos Administrativos que, junto con los sistemas de tramitación, forman la base de la actividad técnica específica del Departamento en el desarrollo de sus competencias.

La reingeniería de sus procedimientos administrativos, tanto para adaptarlos a la tramitación telemática, como para potenciar la eficiencia y eficacia de la actividad del Departamento, en base a la homogenización de la actividad administrativa, la racionalización de los recursos, y la optimización de los mecanismos utilizados.

Este proceso de migración actualmente ha conseguido los siguientes hitos:

Se han concluido los trabajos de desarrollo e implantación en producción del núcleo del sistema y de todos los elementos considerados como horizontales a toda la organización.

El proceso de reingeniería está también cerrado, y los procedimientos definidos, quedando pendiente mediante los proyectos correspondientes su implementación efectiva en la plataforma y su puesta en funcionamiento.

Se han mecanizado los servicios de Seguridad Industria, Turismo así como los procedimientos de autorizaciones, y se ha realizado el despliegue de sus correspondientes procedimientos en producción.

Se está realizando la migración de todos los procedimientos de ayudas a este nuevo sistema y se ha iniciado el análisis y diseño de la mecanización del servicio de Energía.

El Departamento se encuentra con que el número de servicios telemáticos que presta se ha incrementado notablemente, y a su vez el número de usuarios e incidencias es cada vez mayor y requieren una mayor atención.

Actualmente estas incidencias están siendo registradas y atendidas por el servicio que zuzenean pone a disposición de la ciudadanía para responder a aquellas preguntas y solicitudes relacionadas con la Administración a través del teléfono 012.

En esta situación, se ve la necesidad de implementar un servicio de atención (de 2º nivel) especializado en las temáticas propias del departamento, que complemente la labor del servicio de zuzenean para atender a aquellos usuarios externos cuyas cuestiones precisen de un mayor conocimiento técnico del “negocio y gestión” propios del departamento.


3.2 Descripción del Servicio

Organización del servicio:

Un CAU de primer nivel (ZUZENEAN – 012), encargado del registro, atención y resolución

de las cuestiones y problemas de índole general a cualquier tramitación de la

administración, y que derivará al CAU de segundo nivel aquellas cuestiones que no pueda

resolver por precisar de un mayor conocimiento técnico (normativas, etc.) de la cuestión.

Un CAU de segundo nivel (objeto de esta contratación), formado por personal experto

en cada uno de los sistemas del departamento que se encargará de resolver las

incidencias de índole especifica del “negocio” de cada tramitación telemática, que servirá

de refuerzo y retroalimentará al primero.

Requisitos que debe cumplir el servicio:

Atención a las incidencias derivadas por el CAU de primer nivel, los técnicos del

departamento, y recibidas a través de la web o directamente por teléfono.

Análisis y diagnóstico de cada una de las incidencias

Resolución de las mismas en función de su tipología:

Funcionales: Resolución de dudas sobre el funcionamiento especifico del

servicio de teletramitación, así como un registro de propuestas de mejora,

publicación de noticias, actualización de manuales, etc., que permitan mejorar el

sistema y el servicio prestado a los diferentes usuarios.

Configuración: Ayuda técnica para configurar los equipos de los usuarios de la

aplicación para permitir la teletramitación.

Técnicas – sistemas horizontales: Detección de problemas en los diferentes

sistemas informáticos dependientes de otros departamentos implicados en la

teletramitación de este departamento, en cuyo caso se documentará el problema

y se derivará a su responsable.

Técnicas – sistemas propios del departamento: Detección de problemas en los

sistemas informáticos específicos del departamento, en cuyo caso se

documentará el problema, se propondrá una solución, sí es posible, y se derivará

al responsable de asistencia técnica del departamento.

Registro de incidencias: Completar el registro de las incidencias iniciado por el cau de

primer nivel, para facilitar la gestión y seguimiento de las mismas.


Coordinación con CAU – primer nivel:

Mantener reuniones periódicas del seguimiento de las incidencias con el cau de

primer nivel con el fin de detectar puntos de mejora.

Informar de los nuevos servicios on-line y/o mejoras que vaya implantando el

departamento, proporcionando documentación y/o formación sí es necesario.

Informar de problemas puntuales en los sistemas propios del departamento para

poder atender debidamente a los usuarios.

Coordinación con equipo de asistencia técnica del departamento:

Mantener reuniones periódicas del seguimiento de las incidencias con el equipo

de asistencia técnica, con el fin de explicar las propuestas a desarrollar para la

resolución de errores y puntos de mejora, así como coordinar la implantación y

puesta en producción de las mismas.

Tipología de los usuarios a los que hay que atender

Empresas instaladoras o mantenedoras

Organismos de control Autorizados

Ente Vasco de Energía

Cámaras de Comercio

Empresas y Consorcios de empresas solicitantes de ayudas

Ciudadanía, que es usuaria final de las tramitaciones telemáticas

Relación de servicios de teletramitación que hay que atender:

ASCENSORES

AE 0 Aportación de documentación a ascensores con instalación en funcionamiento

AE 0H Aportación de documentación a grúas torre con instalación en funcionamiento

AE 0I Aportación de documentación a grúas autopropulsadas con inscripción

AE A Instalación y Puesta en servicio de Ascensores

AE D Modificaciones importantes de ascensores

AE E Sustitución de Ascensor por Nuevo Aparato


GRUAS

AE H Instalación y puesta en Servicio de Grúas Torre

AE I Inscripción de Grúas Móviles Autopropulsadas

AE XA Baja de Instalación de Aparatos Elevadores

AE XH Baja de Instalación de Grúas Torre

AE XI Baja de Instalación de Grúas Móviles Autopropulsadas

AYUDAS – INTERNACIONALIZACION

AF G Global lehian

AF GP Global lehian - Procedimiento Padre

TURISMO - AGROTURISMO

AG 0 Anexar Documentacion

AG A Consulta Previa

AG B Inicio Actividad

AG C Modificaciones Sustanciales

AG D Modificaciones No Sustanciales

AG G Baja

AG J Dispensas

TURISMO - ALBERGUES

AL 0 Aportación de documentación a albergues

AL A Consulta previa

AL B Inicio actividad

AL C Modificaciones sustanciales

AL D Modificaciones no sustanciales

AL G Baja

AL J Dispensas

PRODUCTOS QUIMICOS

AQ 0 Aportación de Documentación a Almacenamiento de Productos Químicos


AQ A Nuevas Instalaciones de Almacenamiento de Productos Químicos que requieren Proyecto de Instalación

AQ B Modificación de Instalaciones de Almacenamiento de Productos Químicos que requieren Proyecto de Instalación

AQ E Nuevas Instalaciones de almacenamiento de productos químicos que no requieran proyecto de instalación

AQ F Modificación Instalaciones Productos Químicos s/ Proyecto

AQ X Baja de Instalaciones de almacenamiento de productos químicos

TURISMO – APARTAMENTOS TURISTICOS

AS 0 Anexar Documentacion

AS A Consulta Previa

AS B Inicio Actividad

AS C Modificaciones Sustanciales

AS D Modificaciones no sustanciales

AS G Baja

AS J Dispensas

ALTA TENSION

AT 1 Anexar Documentacion Liberalizadas

AT A Centros y subestaciones nuevos liberalizados

AT C Inspección Periódica

AT U Comunicación Baja Instalación Liberalizadas

TURISMO – AGENCIAS DE VIAJE

AV 0 Anexar Documentacion

AV A Consulta Previa

AV B Inicio De Actividad

AV C Modificaciones Sustanciales

AV D Modificaciones No Sustanciales

AV G Baja

BAJA TENSIÓN


BT 0 Anexar Documentacion

BT A Puesta En Servicio De Instalaciones C/Proyecto

BT J Nvas. Instalaciones c/boletín

COMBUSTIBLES LIQUIDOS

CL A Nvas.Instalaciones C/Proyecto

CL J Nvas. Instalaciones s/proyecto

TURISMO - CAMPINGS

CP 0 Anexar Documentacion

CP A Consulta previa

CP B Inicio Actividad

CP C Modificaciones Sustanciales

CP D Modificaciones No Sustanciales

CP G Baja

CP J Dispensas

CP K Solicitud Evaluación Impacto Ambiental

CP L Control Cumplimiento Requisitos Impacto Ambiental

TURISMO – CASAS RURALES

CR 0 Aportar Documentacion

CR A Consulta Previa

CR B Inicio Actividad

CR C Modificaciones Sustanciales

CR D Modificaciones No Sustanciales

CR G Baja

CR J Dispensas

CERTIFICADOS DE EFICIENCIA ENERGETICA

EE A Registro de Certificados de Eficiencia Energética

EQUIPOS A PRESION


EP 0 Aportación de documentación a equipos a presión con instalación en funcionamiento

EP 1 Aportación de documentación a instalaciones de equipos a presión

EP A Regularizar equipos a presión sin placa

EP B Puesta en Servicio e Instalación de Equipos a Presión con Proyecto

EP C Modificación de Instalaciones de Equipos a Presión con Proyecto

EP E Puesta en Servicio e Instalación de Equipos a Presión sin Proyecto

EP F Modificación de Instalaciones de Equipos a Presión sin Proyecto

EP X Baja Instalación Equipos a Presión

TURISMO - HOTELES

HT 0 Anexar Documentacion

HT A Consulta previa

HT B Inicio actividad

HT C Modificaciones sustanciales

HT D Modificaciones no sustanciales

HT G Baja

HT J Dispensas

INSTALACIONES FRIGORIFICAS

IF 0 Aportación de documentación para Instalaciones Frigoríficas

IF A Puesta en servicio de Instalaciones Frigoríficas con proyecto

IF B Modificación de Instalaciones Frigoríficas con proyecto

IF F Puesta en servicio de Instalaciones Frigoríficas sin proyecto

IF G Modificación de Instalaciones Frigoríficas sin proyecto

IF X Baja de Instalaciones Frigoríficas

INSTALACIONES DE GAS

IG 0G Aportación de documentación a Almacenamientos de Gas

IG 0R Aportación de documentación a Receptoras de Gas

IG A Nuevos Depósitos de GLP con proyecto


IG B Modificación de Depósitos de GLP con proyecto

IG H Nuevas instalaciones Receptoras de Gas con proyecto

IG I Modificación de instalaciones Receptoras de Gas con proyecto

IG N Nuevos Almacenamientos en Botellas

IG P Modificación de Almacenamientos en Botellas

IG T Modificación de Depósitos de GLP sin proyecto

IG U Nuevos Depósitos de GLP sin proyecto

IG XG Baja de Almacenamientos de Gas

IG XR Baja de Receptoras de Gas

INSTALACIONES RADIACTIVAS

IR 3 Aportación de documentación de instalaciones radiactivas de 2ª y 3ª categoría

INSTALACIONES TERMICAS

IT 0 Aportación de documentación para Instalaciones Térmicas

IT A Puesta en servicio de Instalaciones Térmicas con proyecto

IT B Modificación de Instalaciones Térmicas con proyecto

IT D Puesta en servicio de Instalaciones Térmicas sin Proyecto

IT X Baja de Instalaciones Térmicas

AYUDAS - COMERCIO

OT C Oficinas técnicas de comercio

AYUDAS - TURISMO

PT I MET. Ayudas para la modernización de las empresas turísticas

PT IP MET. Procedimiento Padre

PT T Programa de apoyo a proyectos territoriales turísticos. Programa PTT

PT TP PTT. Procedimiento Padre

AUTORIZACIONES TELEMATICAS

SE I Acreditación para la Tramitación Telemática

SE J Revocación o Modificación de la Acreditación para la Tramitación Telemática


TURISMO – QUEJAS, DENUNCIAS Y RECLAMACIONES

TU Q Quejas, reclamaciones y denuncias en el sector turístico

TECNOLOGIA E INNOVACION

RG AA Registro de agentes de la RVCTI

Descripción del funcionamiento de los servicios telemáticos del departamento

“TRAMITACIÓN TELEMÁTICA DEL ÁREA DE ORDENACIÓN DEL DEPARTAMENTO”

Esta aplicación que permite la generación y envió de solicitudes al departamento vía telemática, actualmente se encuentra en proceso de migración para integrarse dentro del sistema NB29 que permite una total integración con PLATEA (la plataforma tecnológica de la administración).

Las tramitaciones que se tramitan actualmente a través de este sistema son las correspondientes a las secciones de baja tensión, alta tensión y combustibles líquidos y las funcionalidades telemáticas que permite son las siguientes:

Elaboración de solicitudes

Envío de solicitudes a la administración

Recepción y contestación de requerimientos

Intercambio de información con las empresas suministradoras de electricidad y colegios profesionales

Interconexión con herramientas del sector profesional: SIBOL y TREBOL, para ayudar en la elaboración de la documentación que debe adjuntarse con las solicitudes.

“SGI- SISTEMA DE GESTIÓN DEL DEPARTAMENTO”

A continuación se describe un resumen con las principales motivaciones, objetivos y

características de la aplicación NB29 como “gestor horizontal” de todos los expedientes del

departamento de Desarrollo Económico y Competitividad.

Las principales MOTIVACIONES de la NB29 se pueden resumir en:

Integrar las Direcciones y Servicios del Departamento en un sistema único, para conseguir

agilizar la gestión y obtener cuadros de mando.

Migración de las aplicaciones actuales hacia entornos Web, para conseguir materializar la

tramitación telemática y el expediente electrónico.

Constituir la base del nuevo sistema a partir de los resultados del proyecto de la

infraestructura de la e-Administración, para aprovechar el momento propicio y los

esfuerzos realizados en este ámbito.

Promover el cambio hacia nuevos modelos de gestión en el Gobierno y en Euskadi, para

impulsar el e-Gobierno y la Sociedad de la información.


Los OBJETIVOS de la NB29 se pueden resumir en:

Presentar al usuario sus necesidades concretas sin que éste tenga que buscarlas:

Implantando una nueva filosofía de trabajo con escritorios personalizados, buzones de

tareas y bandejas de expedientes.

Ofrecer al usuario la opción de realizar el trámite a través del canal que más le convenga:

Integrando la tramitación telemática y presencial permitiendo expedientes mixtos

(tramitación telemática y presencial en un mismo expediente).

Interactuar entre diferentes Departamentos, Organismos y Administraciones: Dotando al

sistema de capacidad de interoperabilidad mediante el uso de servicios de validación y

terceros (SVT).

Facilitar la reutilización del sistema: El nuevo sistema va a tener capacidad de

incorporación de nuevos servicios y va a ser construido bajo la filosofía de orientación a

servicios (SOA).

Los CARACTERISTICAS principales de la NB29 se pueden resumir en:

Orientación a cliente. El sistema ha sido diseñado teniendo en cuenta las necesidades de

sus usuarios:

Cliente interno (funcionariado) y Cliente externo (empresas, profesionales, ciudadanos).

Framework de Tramitación. El sistema incluye un motor de tramitación universal con

capacidad para tramitar todos los expedientes del Departamento (estos expedientes

corresponden a diferentes familias del MBT).

Integración BackOffice y FrontOffice. El sistema proporciona una única herramienta que

permite la relación entre la gestión interna y la interacción de terceros.

Sistema preparado para su evolución. El sistema proporciona una cartera de servicios que

el núcleo deja disponibles para su utilización y que permite la incorporación de nuevos

servicios a medida que sean requeridos por los usuarios.

El nuevo sistema se divide en dos partes fundamentales, integradas pero independientes:

NÚCLEO DEL SISTEMA: Es la base del sistema, e incluye todos los servicios de interés

común que necesiten el resto de aplicaciones que se integren en el sistema: motor de

tramitación, etc.

APLICACIONES DE LAS DIFERENTES DIRECCIONES Y OFICINAS DEL DEPARTAMENTO: Son los

diferentes aplicativos (“negocios/secciones”) que forman parte del sistema de información

del departamento y que usan todos los servicios del núcleo para realizar sus tareas de

tramitación: baja tensión, registro industrial, turismo, programas de ayudas, etc.


El núcleo debe resolver la problemática actualmente existente en el departamento:

El departamento a lo largo del tiempo ha sufrido escisiones e incorporaciones de nuevos “departamentos” a su organización.

Ejemplo: Este departamento antiguamente contenía las áreas de “Industria, Agricultura y Pesca”

Por todo esto debe contemplar desde su inicio que:

o cada área del departamento debe acceder solo a sus datos

o en caso de que un departamento se desanexione, debe poder “llevarse” sus datos y la aplicación para poder seguir usándola sí le interesa.

o En caso de que se incorpore un nuevo departamento debería poder integrarse en el sistema.

o La capa de presentación que se oferta junto con los servicios debe ser opcional, ya que es posible en algunos casos sea aunque sea interesante y necesario usar los servicios la sección/backoffice que se incorpore tenga necesidades concretas que necesitan resolver con su propia capa de presentación.

Núcleo del Sistema:

Permitirá la homogeneización del trabajo.

Ofrecerá unos servicios e interfaces gráficas altamente operativos.

Infraestructura y servicios tanto para el BackOffice como para el FrontOffice.

Núcleo del Sistema:

Permitirá la homogeneización del trabajo.

Ofrecerá unos servicios e interfaces gráficas altamente operativos.

Infraestructura y servicios tanto para el BackOffice como para el FrontOffice.


A continuación se muestran unos gráficos en donde se resumen los principales servicios y módulos que comprende el núcleo:

Separación total por Departamentos.

Capa de presentación. (OPCIONAL).

Escritorio Personalizable.

Buzón de tareas y avisos.

Gestor de expedientes: Repositorio y visor del Expdte. Expdte. Electrónico: Trámites y tareas del

expediente, Documentos papel y electrónico, Terceros, tasas, utilidades. Bandeja de expedientes.

Cumplimiento de la resolución de PLATEA, integración y uso de la infraestructura de e-Admón.

Monitor del Sistema para el control y auditoría del sistema informático.

Ventanilla. Gestión de entradas integradas en el Back-Office.

Gestión de ingresos y pagos. (Integración con SIPCA).

Gestor de informes. Cuadros de mando. Explotación de datos. Integración con ofimática.

Comunicaciones internas.

Gestor de tablas maestras y catálogos.

Gestión de Entradas y Salidas de información con otros organismos.

Utilidades comunes a aplicaciones: Gestión de inspecciones, de exámenes, de instalaciones, etc.

Servicios para el Front-Office: Portal profesional, motor de pasos, infraestructura para que cada

aplicación ofrezca sus servicios, servicios de la e-Administración, gestor de autorizaciones,

escritorios según perfiles de organismos, Interoperabilidad (Implementación de Entradas/Salidas con

otros organismos).

Separación total por Departamentos.

Capa de presentación. (OPCIONAL).

Escritorio Personalizable.

Buzón de tareas y avisos.

Gestor de expedientes: Repositorio y visor del Expdte. Expdte. Electrónico: Trámites y tareas del

expediente, Documentos papel y electrónico, Terceros, tasas, utilidades. Bandeja de expedientes.

Cumplimiento de la resolución de PLATEA, integración y uso de la infraestructura de e-Admón.

Monitor del Sistema para el control y auditoría del sistema informático.

Ventanilla. Gestión de entradas integradas en el Back-Office.

Gestión de ingresos y pagos. (Integración con SIPCA).

Gestor de informes. Cuadros de mando. Explotación de datos. Integración con ofimática.

Comunicaciones internas.

Gestor de tablas maestras y catálogos.

Gestión de Entradas y Salidas de información con otros organismos.

Utilidades comunes a aplicaciones: Gestión de inspecciones, de exámenes, de instalaciones, etc.

Servicios para el Front-Office: Portal profesional, motor de pasos, infraestructura para que cada

aplicación ofrezca sus servicios, servicios de la e-Administración, gestor de autorizaciones,

escritorios según perfiles de organismos, Interoperabilidad (Implementación de Entradas/Salidas con

otros organismos).

Turismo

Turismo

Con

sum

o

Con

sum

o

Indu

stria

Indu

stria

Com

ercio

Com

ercio


*** Explicación resumen del FRONT OFFICE ***

Núcleo FrontOffice de Tramitación

El modelo conceptual del cliente externo o FrontOffice de tramitación de la NB29 tendrá una clara orientación hacia el usuario del Departamento. Se basa en tres pilares fundamentales:

o Visión del ciudadano: Mis gestiones Permite al ciudadano interactuar con la Administración en materias como:

Recibir notificaciones pendientes y emitir acuse de recibo telemático Aportar documentación y subsanar documentación requerida Realizar pagos a la Administración Realizar nuevas gestiones: Cambio de domicilio de notificación,

Solicitud de aplazamiento de un pago, etc. o Web del profesional

Permitiendo la segmentación por perfiles profesionales (baja tensión, gas, aparatos elevadores, etc.) ofrecerán información sobre normativa, noticias, eventos, etc., proporcionando una visión integrada de la tramitación y ofreciendo información específica de cada negocio.

Además, facilitarán la presentación de solicitudes telemáticas, permitiendo la colaboración de agentes externos y estableciendo flujos de tramitación previos a la propia presentación de la solicitud ante el organismo responsable de su tramitación.

o Interoperabilidad con organismos externos

Este módulo permitirá el intercambio de información con entidades externas al Departamento como pueden ser las empresas suministradoras, etc. En principio se ofrecerán mecanismos estándar de intercambio de información basados en tecnología de Web Services y en formatos XML de definición de datos.

Objetivo del FrontOffice

El Departamento de Desarrollo Económico y Competitividad tiene como objetivo promover una administración electrónica moderna y atractiva aumentando el número de servicios públicos en línea, siguiendo con el camino abierto por la infraestructura de e-administración del Gobierno Vasco.

En esta línea se plantea el desarrollo de una web donde cada usuario acceda a la información que necesita de forma rápida, segura y eficaz, facilitando el intercambio interactivo de información entre los interlocutores de forma fiable y sencilla.

Más allá de la mera información de contenidos, este proyecto pretende dar la posibilidad al ciudadano de realizar la tramitación de sus expedientes de forma on-line a través de internet, permitiendo la creación de solicitudes, presentación de documentación, acceso a notificaciones, etc. En definitiva la TeleTramitación.

Para alcanzar el objetivo marcado se utilizarán las tecnologías de transmisiones seguras de firma electrónica, la plataforma tecnológica y los servicios creados en la infraestructura de PLATEA y se desarrollarán nuevos servicios que atiendan a los requisitos encontrados.


Identificación Usuarios

A nivel de Departamento se identifican una serie de usuarios con necesidades claramente diferenciadas:

Ciudadano

Visitante ocasional. Generalmente busca información y en algunos casos teletramita. Actualmente escasa disponibilidad de certificados electrónicos. En ocasiones tienen intermediarios como gestorías.

Empresas

Contacto habitual con el Departamento, busca temas de promoción y en sectores concretos información de ordenación sobre la empresa.

Disponen de sistemas de información potentes y están Interesados en tramitación automática y masiva de solicitudes y aportaciones de documentos, pagos electrónicos,.etc.

Posibilidad de aumentar la disponibilidad de certificados digitales por la obligatoriedad de uso que marcan las haciendas.

Actualmente realizan tramitaciones telemáticas, algunas sin necesidad de firma electrónica.

En ocasiones tienen intermediarios como gestorías.

Profesionales

Junto con las empresas es el objetivo fundamental del departamento, están dedicados a la realización de instalaciones industriales y su mantenimiento, son los usuarios por excelencia del Departamento.

Posibilidad de dotar desde el Departamento de certificados digitales. En ocasiones tienen intermediarios como gestorías o agrupaciones/asociaciones.

Colaboradores en y finalistas de la tramitación

Son organismos o empresas como: OCA‟s, colegios profesionales, empresas suministradoras, etc. Por tanto, tienen contacto habitual con el Departamento.

Forman parte de la tramitación de una solicitud o son destinatarios de información. Son colectivos concretos. Interés por teletramitar. Posibilidad de dotar desde el Departamento de certificados digitales.


4 Duración del contrato

El período máximo de duración del contrato será desde la adjudicación hasta el 31 de Diciembre de 2017, con posibilidad de prórroga máxima durante los dos siguientes años. Para dicha prórroga se aplicarán las mismas condiciones y prestaciones económicas establecidas para el período inicial de duración del contrato.

La prórroga del contrato se producirá de manera expresa y por escrito, con preaviso de dos meses por parte del adjudicatario, salvo que por EJIE se notifique al adjudicatario su decisión de no prorrogarlo con una antelación mínima de 30 días naturales a la fecha de finalización. Como se ha señalado anteriormente, la prórroga es por un periodo máximo, siendo facultad de EJIE ejecutar la misma por un periodo inferior.

En todo caso, debe señalarse que la adjudicación del contrato no supone en modo alguno el derecho del contratista adjudicatario de cobrar el importe total de adjudicación, ya que se trata de un presupuesto con facturación variable en base al resultado de los servicios efectivamente prestados por el contratista, aplicando a los mismos el precio de la adjudicación.

Al tratarse de un proyecto encomendado por Gobierno Vasco a EJIE, si se producen circunstancias no previstas inicialmente que lo justifiquen, EJIE podrá, durante el periodo de duración del contrato y si existen circunstancias que lo justifiquen, proceder a la terminación anticipada del contrato, siempre y cuando se notifique la misma al adjudicatario con una antelación mínima de 30 días. El licitador que resulte adjudicatario con la presentación al proceso de licitación, acepta de manera expresa dicha posibilidad, renunciando expresamente con ello a cualquier reclamación de carácter económico o de cualquier otra índole que pudieran derivarse de esta situación.


5 Presupuesto y valor estimado

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

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

El presupuesto máximo para el período de prestación inicial del servicio (desde la adjudicación hasta el 31 de Diciembre de 2017, sin incluir la posible prórroga del mismo) será de 140.000,00 € (IVA no incluido) cuya ejecución y pago mensual será totalmente variable en función de los servicios realizados por el adjudicatario y aprobados por EJIE durante el período.

El valor estimado máximo del contrato es de 280.000,00€ (IVA no incluido).


6 Metodología Aplicable y Entorno Tecnológico.

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

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

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

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

Ingeniería del Software (ISW)

Gestión del Proyecto (GPR)

Gestión de Riesgos del Proyecto (GRP)

Gestión de la configuración (GCO)

Mantenimiento del Sistema de Información (MSI)

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

Catálogo de Requisitos de Usuario (CRU) (proceso diferenciado dentro del Análisis del Sistema de

Información, ASI)

Análisis del sistema (ASI)

Diseño del sistema (DSI)

Construcción del sistema (CSI)

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

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

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

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

Catálogo de Requisitos de Usuario detallado en el documento CRU, que incluye:

La descripción del sistema

Los requisitos de usuario

Los casos de uso

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

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

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






Análisis del Sistema de Información, ASI, recogido en documento ERS, que incluye :

La especificación de requisitos del sistema

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

Las clases del sistema

El prototipo de interfaz

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

Diseño del sistema. Lo realizará en su totalidad el adjudicatario y en sus dependencias. Debe

incluir:

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

Especificar el detalle del Plan de Pruebas del sistema por cada uno de los niveles de prueba:

unitarias, de integración, de sistema, de implantación y de aceptación, según las directrices

establecidas en PROBAMET

Construcción del sistema.

Lo realizará en su totalidad el adjudicatario en sus dependencias, teniendo en cuenta las

directrices de EJIE en lo que se refiere a los módulos estándar, las normas de funcionamiento

y albergue de las aplicaciones en Internet/Intranet, el Manual de Identidad Corporativa del

Gobierno Vasco y las directrices de la Dirección de Atención a la Ciudadanía en lo que

respecta a estética, diseño y funcionalidades de las páginas Web.

Incluirá la ejecución del Plan de Pruebas, para verificar el cumplimiento de los requisitos

establecidos en el mismo, abarcando pruebas unitarias, de integración y del sistema,

siguiendo el modelo y las actividades descritas en la metodología PROBAMET

Los entregables de esta fase incluyen la Especificación de Construcción del Sistema (ECS) y

el sistema construido.

Asimismo, deberán respetarse las convenciones adoptadas para un desarrollo de

aplicaciones homogéneas recogidas en el Libro de Estilo del Departamento de Desarrollo

Económico y Competitividad.

El diseño del sistema tendrá en cuenta el nivel de accesibilidad AA (WAI-AA), para aquellos

módulos que sean accesibles desde Internet.

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

castellano.

La aplicación, las páginas, los textos, los mensajes de error/aviso y/o cualquier otro

componente (tool-tip, textos en imagen,….) dirigidos al usuario final deberán estar al menos

en ambos idiomas: euskera y castellano.

Implantación en desarrollo. La empresa adjudicataria realizará los siguientes puntos

La entrega de la aplicación en el sistema de corporativo de control de versiones Subversion,

tanto de la entrega inicial como de las sucesivas

Llevará a cabo la instalación de la aplicación en el entorno de desarrollo de EJIE, habiendo

realizado previamente las pruebas necesarias durante la fase de construcción

Ejecución de las Pruebas del sistema, acorde con lo establecido en la metodología

PROBAMET y el Modelo SQA, evaluando los resultados

Implantación en entorno de test o preexplotación. La empresa adjudicataria efectuará los

siguientes puntos

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

implantación en el entorno de test o preexplotación

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

realizarán en las dependencias de E.J.I.E en sus distintos niveles de prueba, incluidas las

Pruebas de Aceptación, acorde con lo establecido en la metodología PROBAMET y el Modelo

SQA, evaluando los resultados

Pruebas de prestaciones:


Conforme a lo establecido en el Modelo SQA, realización de pruebas de rendimiento y carga,

que incluyen la verificación de los niveles de respuesta de la aplicación ante las previsiones

de carga del sistema, así mismo se verificará el comportamiento global del sistema en cuanto

a consumo de memoria y CPU de sus componentes, así como según se considere de

capacidad, stress, escalabilidad

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

Fuentes de la aplicación.

BBDD: scripts y carga inicial de datos.

Sistema implantado en entorno pruebas de EJIE

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

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

procesos ITIL de EJIE.

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

castellano.

Formación a los usuarios y administradores del sistema.

Sistema implantado en entorno de producción.

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

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

6.2 Metodología de pruebas

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

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

PROBAMET describe las siguientes fases:

Planificación y Seguimiento de las Pruebas – PPB

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

Ejecución de las Pruebas – EPB

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

Planificación de las Pruebas. Incluye:

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

Planificación (cronograma) de actividades

Identificación de factores de riesgo

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

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

http://www.euskadi.net/informatika





Seguimiento de las Pruebas. Incluye:

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

Informes de seguimiento de las pruebas realizadas

Análisis y Diseño de las Pruebas:

Especificación de los casos de prueba

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

Trazabilidad)

Ejecución de las Pruebas. Incluye:

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

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

Análisis estático de código.

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

Pruebas de Integración: con el objetivo de probar los interfaces entre módulos e ir

incrementando la prueba de los módulos y sistemas.

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

Funcionales y Pruebas del Sistema No Funcionales

Pruebas de Aceptación: pruebas del usuario.

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

6.3 Modelo de aseguramiento de la calidad (SQA)

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

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

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

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

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

al NAC asignado

El proceso para la realización de las actividades de aseguramiento de calidad definidas, alineadas

con la metodología de desarrollo ARINbide-Predictivo y cumpliendo implícitamente la metodología

de pruebas PROBAMET

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

permitidos.

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

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

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

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

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





6.3.1. Plan SQA y actividades de aseguramiento de la calidad

Al inicio del proyecto se elaborará el Plan de Aseguramiento de la Calidad (PSQA), estableciendo el detalle de las actividades de calidad a realizar, sus esfuerzos y fechas de compromiso según el Plan de Entregas obtenido en ARINbide-Predictivo y en función del NAC calculado.

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

Verificación documental: Revisión de la documentación entregable de ARINbide-Predictivo y

PROBAMET, realizada para asegurar que el formato y contenido de la documentación del

proyecto cumple con las metodologías y los estándares de calidad de EJIE. Incluye para todos los

entregables:

Checklists de Verificación de ARINbide-Predictivo

Checklists de Verificación de PROBAMET

Auditorías Fin de Fase SQA: Para la realización de estas auditorías, se seguirán los

correspondientes formularios de “Checklist de Auditorías SQA”, y de dispondrá de la información y

documentación recopilada en cada fase. Los resultados y conclusiones se incluyen en el Informe

de aseguramiento de la calidad ISQA. Se contemplan las siguientes:

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

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

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

Pruebas de Integración.

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

Auditoría CSI-III: Después de la realización de las Pruebas No Funcionales de Sistema:

Pruebas de Prestaciones, Seguridad, Accesibilidad, Usabilidad y Pruebas de Fallo y

Recuperación del Sistema.

Auditoría Final SQA: Se realizará al finalizar todas las actividades previstas en el proyecto para la

fase de Implantación (IAS) de ARINbide-Predictivo, y las pruebas de Aceptación de usuario, en

base al Plan SQA del proyecto. Sigue la misma operativa que las Auditorías de Fin de Fase y

obtiene de forma incremental el mismo informe pero dando la visión global del grado de calidad del

proyecto y las conclusiones derivadas.

Recogida y Análisis de Indicadores (Cuadro de mando): Como resultado de las distintas

actividades del modelo, se actualizan automáticamente los indicadores de calidad, ayudando

también en la toma de acciones correctivas. Existe un mapa de indicadores que la aplicación a

implantar deberá cumplir, en base al NAC asignado. La no superación de los límites establecidos

podría suponer que el sistema no sea instalado en el entorno de producción

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

6.4 Herramientas del ciclo de vida de las aplicaciones

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

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

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


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

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

6.5 Entorno Tecnológico

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

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

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

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

Sistemas de infraestructura de tramitación, PLATEA-Tramitación. Permiten ofrecer al

administrado una visión homogénea de los procesos de tramitación gestionados por cualquier

departamento de Gobierno Vasco, facilitar al empleado público las herramientas básicas y únicas

de gestión de tareas de tramitación, definir y establecer los flujos de tramitación adscritos al

modelo básico de tramitación, y aportar las soluciones técnicas necesarias que garantizan el

cumplimiento de las normativas y procedimientos legales vigentes en materia de tramitación.

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

Herramientas de gestión de contenidos, portales, ejes de catalogación y buscador:

PLATEA-Internet. Gestionan la creación, publicación y mantenimiento de contenidos en los

portales de internet administrados por Gobierno Vasco, y su catalogación en ejes homogéneos

que faciliten su búsqueda. Facilita igualmente los mecanismos para la integración de las

aplicaciones en la propia infraestructura de portales.

Como plataforma de integración entre sistemas:

La infraestructura de integración. Simplifica y estandariza los modelos de intercambio de datos

y de procesos entre aplicativos, proporcionando para ello las herramientas y sistemas necesarios

para su implementación en base a una plataforma tecnológica unificada, normalizada y

compartida. Ofrece soluciones corporativas normadas que ofrecen utilidades y gestionan el

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


intercambio síncrono de información (exposición de servicios), y el intercambio asíncrono

(suscripción a eventos).

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

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

Dokusi. Sistema Integral de Gestión Documental cuyo principal objetivo es la implantación de

todas las funciones de gestión documental necesarias en los procesos de producción

administrativa. Expone su uso a las aplicaciones departamentales mediante su capa de servicios -

framework de servicios documentales – FSD, proporcionando además otras utilidades para la

carga masiva de documentación, e interfaces gráficas.

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

Pasarela de pagos: Sistema que provee los servicios necesarios para gestionar peticiones de

pago generadas por la administración para el ciudadano, incluida la aplicación internet de pago

electrónico on-line u off-line. En el documento PCT-Anexo Pasarela de Pagos se detalla

información de referencia acerca del sistema.

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

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

XLNetS. Gestiona los procesos de autenticación y autorización de accesos a usuarios (y sistemas)

para aplicativos y recursos, desarrollados bajo distintas tecnologías.

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

NORA. Sistema horizontal de gestión de datos de localización –dirección postal-, que proporciona

información actualizada y normalizada hasta nivel de portal. Ofrece diversas alternativas

tecnológicas de uso, y como principal valor añadido aporta el tratamiento de Altas Provisionales,

solución que permite a las aplicaciones asegurar la normalización de los datos de su negocio, y a

su vez favorecer la actualización continua de la información. Incluye además datos y servicios de

información geográfica (visor y geolocalizador). En el documento PCT-Anexo NORA se detalla

información de referencia acerca del sistema.

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:

FOP, iText o JasperReports para tecnología J2EE.

Reporting Services (Microsoft)

Business Intelligence:

Oracle Business Intelligence

Bitam

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

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

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


Sistemas de Información Geográfica:

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

Servicio de envío de mensajes SMS:

SMS Corporativo, basado en plataforma Latinia

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

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

Servidor web:

Apache Web Server 2 sobre Linux Red Hat Enterprise.

Bases de datos:

Oracle 10g sobre HP-UX

SQL Server 2005

Seguridad:

XLNets y PKI Izenpe

Infraestructura para la Gestión de contenidos y portales (PLATEA-Internet):

Interwoven TeamSite 6.7

Open Deploy 6.1

Autonomy

Infraestructura para la gestión documental (Dokusi):

Basado en Documentum

Gestión de versionado de aplicaciones:

Subversion

Documentación y trabajo en grupo:

SharePoint Portal Server

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

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

El nuevo sistema, y según sus necesidades, podrá utilizar otros módulos y servicios específicos para el Departamento de Desarrollo Económico y competitividad, cuyo entorno tecnológico se describe a continuación:

El SGI (Sis tema de Gest ión de Industr ia) contempla una arquitectura común para dar soporte a la migración de las aplicaciones existentes en la actualidad en el Departamento de Desarrollo Económico y Competitividad y a los posibles desarrollos que se lleven a cabo en un futuro, basándose en los requisitos planteados en el punto anterior.

La explicación técnica detallada de esta arquitectura, se explica de forma general en este capítulo:

La evolución del mercado y de la tecnología lleva al desarrollo de un único punto de servicios comunes para dar soporte a „n‟ consumidores. Dando como resultado una Arquitectura Orientada a Servicios (SOA).

SOA promueve el desacoplamiento de los componentes de una infraestructura multiplataforma en transacciones elementales o servicios elementales reutilizables por todos los consumidores.

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


Servicio: Se trata de una función sin estado, auto-contenida, que acepta unas llamadas y devuelve unas respuestas mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo. Los servicios no dependen del estado de otras funciones o procesos ni implican el establecimiento de sesiones

Pretenden favorecer la interoperabilidad entre los procesos de negocio organizativos e inter-organizativos..

Interoperabilidad: La capacidad que tienen los sistemas TIC y los procesos de negocio que los soportan, de intercambiar datos y permitir compartir información y conocimiento. Es necesaria una interoperabilidad a tres niveles: Organizativo, Semántico y Técnico

Las ventajas que aportan las Arquitecturas SOA frente a otro tipo de arquitecturas son:

La abstracción de las aplicaciones y sistemas en servicios a través de sus interfaces normalizadas favorece la generalización de su uso y, al requerir un mínimo conocimiento del sistema o aplicación subyacente, facilita los proyectos de desarrollo.

Se fomenta la reutilización efectiva y práctica. El consumo de servicios no es sino una manera de reutilizar el mismo código.

Cada uno de los componentes se independiza del resto, permitiendo su evolución técnica y funcional, siempre que se respete la interfaz de los servicios original.

La utilización de estándares abiertos permite una interoperabilidad cuasi universal con independencia de las plataformas tecnológicas implicadas.

Se facilitan las pruebas unitarias sobre los sistemas especializados y desacoplados.

Se mejora la escalabilidad gracias a procesos distribuidos sobre balanceo de carga.

Se facilita la composición de nuevos servicios sobre servicios ya existentes.

La implementación ideal de una Arquitectura SOA requiere tener en consideración algunos inconvenientes técnicos inherentes al modelo:

Los tiempos de llamado nos son despreciables, gracias a la comunicación de la red, tamaño de mensajes, etc. Esto necesariamente implica la utilización de mensajería confiable.

La respuesta de los servicios es afectada directamente por aspectos externos como problemas en la red, configuración, etc. Estos deben ser tenidos en cuenta en el diseño, desarrollándose los mecanismos de contingencia que eviten la parálisis de las aplicaciones y servicios que dependen de él.

Debe manejar comunicaciones no confiables, mensajes impredecibles, reintentos, mensajes fuera de secuencia, etc.

Obviamente, un servicio debe de controlar internamente su propia transaccionalidad, pero muchas veces se requiere mantener la transaccionalidad interservicios, lo cual exigiría el control de la misma desde la propia lógica del consumidor.

Por ello un diseño exitoso de una arquitectura basada en servicios debe de estar basado en una plataforma de mensajería confiable, que aísle de la implementación funcional muchos de los problemas anteriormente mencionados. Algunos de las responsabilidades de un mecanismo así, incluyen:

Entrega garantizada de mensajes.

Enrutamiento de peticiones a un servicio disponible.

Seguridad del contenido de los mensajes.

Calidad de servicio.


Escenarios fuera de línea.

Control de transaccionalidad interservicios.

Control de la seguridad de acceso.

Ligado a esta nueva arquitectura llega un nuevo modelo de desarrollo orientado a servicios (SODA), el cual deberá de aplicarse en los nuevos análisis y diseños proporcionando:

Reutilización de servicios: Se encapsulan los servicios con sentido funcional, en vez de las tradicionales llamadas a métodos orientados al sistema. Estos servicios han de exponerse en un único catálogo de servicios de forma que queden accesibles al resto de las aplicaciones fomentando de esta manera la reutilización.

Independencia de la plataforma: Siempre se ejecutan como si se tratara de una llamada remota. La tecnología y localización de la aplicación proveedora del servicio se oculta detrás de la interfaz del servicio. Permitiendo la migración de plataforma o tecnología de las aplicaciones que ofrecen o consumen el servicio sin que para ellos se vea afectada la definición del servicio.

Flexibilidad: La aplicación consumidora y la aplicación proveedora pueden cambiar. Mientras no se modifique la definición de los elementos esenciales (obligatorios) del interfaz, la comunicación entre ellas no se verá afectada. Permite responder a las nuevas demandas de servicios rápidamente. Esto se traduce en alta disponibilidad y escalabilidad.

Seguridad: Permite definir autenticación y autorización necesaria de los consumidores de servicios.

Estándares: Conectividad a través de estándares comunes extensibles: XML, SOAP, WSDL, JMS, WS- Security, WS-Routing, etc.

La arquitectura base, sobre la que se deben desarrollar las aplicaciones del SGI (Sistema General de Industria) se basa en los patrones de diseños propuestos por Sun Developer Network para el desarrollo de aplicaciones J2EE.


En el siguiente gráfico se esboza la arquitectura en capas orientada a servicios definida, la cual pretende recoger todos los requisitos de desarrollo presentes y futuros que se puedan plantear en el Departamento de Desarrollo Económico y Competitividad.


La arquitectura general del SGI está compuesta de:

Aplicaciones de presentación (capa de entrega): Aplicaciones desarrolladas sobre GEREMUA.

Aplicaciones de integración (capa de servicios): Orquestadores de servicios de negocio. Autogestionan la transaccionalidad entre los distintos servicios que ofrecen los sistemas de negocio. Se presentan como servicios de granularidad gruesa.

Aplicaciones de negocio (capa de negocio): Representan los sistemas que componen la arquitectura. Cada sistema tiene su propio modelo de datos y son los encargados de gestionar estos datos.

Aplicación única de Entidades de transferencia: Todas las entidades de negocio detectadas se agrupan en una única aplicación.

Aplicación de utilidades (componentes de la arquitectura): Aplicación encargada de agrupar a todas las utilidades comunes que se hayan podido detectar dentro de la arquitectura.


Entorno Tecnológico

Servidor web:

Apache Web Server 2.5 sobre Linux Red Hat EE 5 64bits

Servidor de aplicaciones:

BEA Weblogic Server 11g sobre Linux Red Hat EE 5 64bits

Base de datos:

Oracle 10 sobre Sun Solaris 8

Seguridad:

XLNets y Certificados de Izenpe

Herramientas:

Framework J2EE: Geremua

IDE (PC compatible con W7):

Eclipse Helios

Ant

Gestión de dependencias: Maven

Versionado de código/trabajo en equipo:

Subversion

Informes:

JReport

Tramitación electrónica:

Sistemas, procesos e interfaces del Lote4 de eAdministración

Pruebas:

JUnit

LoadRunner

Documentación y diagramación

Enterprise Architect

SharePoint Portal Server

JavaDoc


7 Configuración del Servicio

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

7.1.1. Asignación de recursos a fases del proyecto

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

Descripción Perfil Gest. Proyecto

Análisis Diseño Construcción Implantación Total Horas

Horas % Horas % Horas % Horas % Horas %

Jefe Proyecto

Analista Funcional

Analista Técnico

Analista-Program.

Programador

Diseñador

TOTAL

Este desglose de horas se considerará como orientativo y será tenido en consideración en el

momento de valorar el grado de aproximación a la planificación del proyecto según la estimación del

licitador, permitiendo, de esta forma, valorar la idoneidad del dimensionamiento del equipo de

trabajo propuesto y su adecuación a la consecución de los objetivos. No obstante este desglose de

horas no se considera vinculante.

Se deberán ofertar los perfiles indicados en la tabla y no otros.

Para cada uno de los perfiles, deberá detallarse el número de horas y % de dedicación de cada uno

de los miembros del equipo propuesto en función de la categoría asignada

7.1.2. Equipo de Trabajo

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando.

El licitador se compromete, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en la oferta, y durante el periodo fijado en cada actividad específica. Los recursos asignados a la ejecución del contrato deberán estar asignados desde el inicio del mismo. En el caso de modificación o sustitución de recursos, deberá comunicarlo previamente a EJIE, con la antelación mínima necesaria en función de la criticidad del servicio, y en cualquier caso no mayor 15 días naturales, y EJIE aprobará o rechazará dicha modificación o sustitución. En todo caso el sustituto o sustitutos tendrán un perfil igual o superior al ofertado, o recurso a sustituir.


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

7.1.2.1. Constitución inicial del equipo de trabajo

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

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el establecido en la oferta y:

Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo

que suscita el cambio, se procederá a:

La presentación por el adjudicatario de sustituto/s con un perfil de cualificación técnica

igual o superior al de la persona que se pretende sustituir.

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

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

reserva el derecho no solo a la aprobación del sustituto/s sino incluso a la revisión de la

adjudicación y en su caso la rescisión del pedido/contrato, si este hecho fuera elemento

determinante en la mencionada adjudicación.

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

La valoración de la calidad de los servicios objeto del presente pliego corresponde a la Dirección del Proyecto de EJIE, siendo potestad suya solicitar el cambio de cualquiera de los componentes del equipo de trabajo, con un preaviso de quince días, por otro de igual categoría o superior, si existen razones justificadas que lo aconsejen.

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

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

Presentación de sustituto/s con un perfil de cualificación técnica igual o superior al de la persona

que se pretende sustituir.

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

Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las sustituciones de personal, deberán subsanarse mediante periodos de solapamiento sin coste adicional, durante el tiempo necesario. Si a criterio de la Dirección del Proyecto de EJIE, esto no fuera posible, las dos primeras semanas de trabajo del sustituto/s no serán facturables corriendo a cargo del adjudicatario.

7.1.2.3. Horario y lugar de realización de los trabajos.

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

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


Los componentes del grupo de trabajo deberán estar en una única ubicación y desarrollarán su

labor con hardware y software propiedad del adjudicatario. Se deberá garantizar una presencia

rápida en EJIE, ante cualquier eventualidad que pudiera surgir.

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

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

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

Con carácter general los componentes del grupo de trabajo deberán desarrollarán su labor con

hardware y software propiedad del adjudicatario, salvo para labores de instalación, implantación, y

puesta en marcha, que se realizará mediante los puestos asignados por la Dirección del Proyecto

de EJIE

Si por circunstancias excepcionales y cuando la realización efectiva de los trabajos no se ajuste a

la planificación o así se requiera por las necesidades del servicio, el adjudicatario deberá

comprometerse a una plena disponibilidad incluso fuera del horario habitual (salvo acuerdo previo

por la Dirección del Proyecto de EJIE), sin que la realización del trabajo tenga una consideración

especial a efectos de cómputo de horas o tarifa aplicable a las mismas

7.2 Transferencia Tecnológica.

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


8 Mecanismos de Seguimiento, Control y Supervisión

La gestión del proyecto se realizará según las normas procedimentales y de calidad de la Gestión de Proyectos de EJIE y del Gobierno Vasco.

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

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

8.1 Mecanismos de Seguimiento y Control.

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

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

Reuniones de seguimiento: a partir del plan de entregas requerido se celebrarán reuniones

periódicas o coincidiendo con los puntos de decisión, destinadas a revisar el grado de

cumplimiento de las tareas planificadas, le entrega de productos, las reasignaciones de personal,

la validación de las programaciones de actividades a realizar, etc.

Reuniones de control económico: de control económico del proyecto para llevar a cabo el plan de

pagos establecido.

Informes de situación y progreso: con los que la empresa adjudicataria comunicará a la Dirección

del Proyecto de EJIE, del estado puntual de los trabajos, de los objetivos alcanzados, de las

incidencias ocurridas, etc.

Certificaciones parciales: si procede.

Hojas de control de tareas: si procede.

Documentos de gestión de proyectos: a solicitud del responsable de EJIE, la empresa

adjudicataria cumplimentará los documentos de gestión de proyectos, según un modelo definido:

actas de reuniones, registro de inspección y ensayo, informes de progreso, control de

configuración (módulos-componentes instalados), etc.

Elaboración de informes mensuales de seguimiento con las incidencias y peticiones atendidas.

8.2 Supervisión del proyecto

Tanto la dirección como la supervisión del Proyecto serán llevadas a cabo por el personal de EJIE, S.A. asignado al proyecto. Los productos del trabajo deberán ser aprobados tanto por el Responsable del Proyecto por parte del adjudicatario, como por la Dirección del Proyecto de EJIE, si los encuentran conformes, emitirán su informe favorable, empezándose a computar desde ese momento el período de garantía que todo trabajo de realización externa debe aportar en previsión de defectos no detectados en las pruebas realizadas.

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


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

La facturación de los servicios tendrá periodicidad mensual y será totalmente variable. El importe de facturación se calculará en función del informe del período donde se detallaran las horas de dedicación y las peticiones e incidencias atendidas y resueltas, y deberá ser validado y aceptado por la Dirección del Proyecto de Ejie.

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.

Dadas las especiales condiciones de la actual situación económica y financiera, EJIE, S.A. como se ha señalado, podrá, durante el periodo de duración inicial del contrato, si existen circunstancias que lo justifiquen, proceder a la terminación anticipada del contrato, siempre y cuando se notifique la misma al adjudicatario con un antelación mínima de 30 días a la fecha prevista para dicha terminación, y viniendo en todo caso obligado a abonar el importe de la adjudicación hasta dicha fecha de terminación.

Igualmente, y por las mismas razones, EJIE, S.A. podrá modificar el contrato adjudicado y suscrito con el licitador que resulte adjudicatario, reduciendo su contenido hasta un máximo del 20 % inicial, lo cual deberá ser notificado con una antelación mínima de 30 días a la fecha a partir de la que se producirá dicha reducción. En el supuesto de que por EJIE, S.A. se haga uso de dicha facultad, el importe del presupuesto base adjudicado, se reducirá en la misma proporción.

La simple presentación de los licitadores al presente procedimiento, supone la aceptación de ambas facultades de EJIE, S.A., y la renuncia a efectuar reclamaciones por el ejercicio de las mismas.


10 Criterios de Adjudicación.

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

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

Característica Objeto de valoración Puntos

Proposición Económica. 55

Proposición Solución Técnica: 45

Propuesta de solución y puesta en marcha para la ejecución del servicio 40

Procedimientos de gestión, control y seguimiento, y aseguramiento de la calidad 5

Valoración de la Proposición Económica (55%):

Se calculará sobre el valor de las tarifas de los distintos perfiles solicitados y ofertados en la planificación y composición del equipo, y utilizando también la misma fórmula de valoración anterior.

Total puntos proposición económica. x Precio tarifa CALCULADA más ventajosa (la de precio más bajo)

Tarifa CALCULADA oferta evaluada

La ponderación de cada una de las tarifas “XX” se realizará según la siguiente relación, donde los valores de las tarifas se sustituirán por las tarifas ofertadas para dichos perfiles en cada caso:

Tarifa

Factor ponderación

Aportación a tarifa TOTAL CALCULADA

Jefe Proyecto XX € 15% YY €

Consultor Funcional/Técnico XX € 20% YY €

Analista programador XX € 40% YY €

Programador XX € 25% YY €

TOTALES 100% *ZZ €

* Nota 1: Será la tarifa simbolizada en cuadro anterior como ZZ la que se tomará como referencia para la valoración de este apartado

Se establecen las siguientes tarifas máximas para cada uno de los perfiles así como la tarifa ponderada máxima resultante:

Tarifa MÁXIMA

Factor ponderación

Aportación a tarifa MÁXIMA TOTAL CALCULADA

Jefe Proyecto 53,34 € 15% 8,00 €

Consultor Funcional/Técnico 49,29 € 20% 9,86 €

Analista programador 42,90 € 40% 17,16 €

Programador 37,67 € 25% 9,42 €

TOTALES 100% 44,44 €


Solución Técnica (45%)

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

Dado que se trata de la contratación de un servicio, se valorará la propuesta de solución y puesta en marcha del mismo, así como los procedimientos de gestión, control y seguimiento del proyecto.

a) Propuesta de solución y puesta en marcha para la ejecución del servicio (40%):

Se valorará en este apartado: la descripción de la propuesta de solución y puesta en marcha del servicio:

Organización del servicio

Equipo técnico propuesto (dimensionamiento, composición, distribución de perfiles,

actividades y tareas a realizar por cada uno de sus miembros)

Esquema propuesto para la identificación, registro, diagnostico de incidencias y su

resolución

Metodologías y herramientas a utilizar

Excelente = 40; Buena = 30; Media = 20; Deficiente = 10; No cumple = 0

- Consideraremos la oferta como “Excelente” cuando contemple todos los requisitos del

servicio establecidos en el pliego de bases técnicas, desarrollando cada uno de ellos de

manera clara y entendible, y cuando dicho desarrollo sea considerado por nosotros como

adecuado para el proyecto a desarrollar.

- Consideraremos la oferta como “Buena” cuando contemple todos los requisitos del

servicio establecidos en el pliego de bases técnicas, desarrollando todos o casi todos los

requisitos, y siempre que los no desarrollados o poco desarrollados no tengan

consideración de críticos en el proyecto.

- Consideramos la oferta como “Media” cuando contemple todos los requisitos del servicio

establecidos en el pliego de bases técnicas, pero el desarrollo de los mismos sea pobre o

inexistente en algún caso.

- Consideramos la oferta como “Deficiente” cuando no contemple todos los requisitos del

servicio establecidos en el pliego de bases técnicas y el desarrollo de dichos requisitos sea

pobre o inexistente en algún caso.

- Consideramos la oferta cono “no cumple” cuando le falten requisitos importantes del

servicio establecidos en el pliego de bases técnicas y su desarrollo sea deficiente o

erróneo para el proyecto a desarrollar.

b) Procedimientos de gestión, control y seguimiento, y aseguramiento de la calidad (5%):

Se valorará en este apartado: la descripción de las medidas dispuestas por el licitador para asegurar la correcta gestión del proyecto, los mecanismos de control y seguimiento a aplicar, los procesos de aseguramiento de la calidad, así como aquellas medidas que se prevé emplear para vigilar y garantizar el adecuado cumplimiento del contrato.


Modelo de gestión, seguimiento y control: Comités, funciones, composición, periodicidad,

herramientas a utilizar, informes e indicadores propuestos, gestión de riesgos y

aseguramiento de la calidad (Modelo SQA)

Excelente = 5; Buena = 3,75; Media = 2,5; Deficiente = 1,25; No cumple = 0

- Consideraremos la oferta como “Excelente” cuando haya descrito coherente y

exhaustivamente tanto el modelo de gestión como las actividades orientadas al control y

seguimiento acorde a las particularidades del proyecto.

- Consideraremos la oferta como “Buena” cuando haya descrito coherentemente un

modelo de gestión acorde a las particularidades del proyecto, y siempre y cuando los

puntos no desarrollados o poco desarrollados no tengan consideración critica para el

proyecto.

- Consideraremos la oferta como “Media” cuando haya descrito coherentemente un

modelo de gestión acorde a las particularidades del proyecto, pero el desarrollo de los

mismos sea pobre o inexistente en algún caso.

- Consideraremos la oferta como “Deficiente” cuando no haya descrito suficientemente un

modelo de gestión acorde a las particularidades del proyecto, y el desarrollo de los

mismos sea pobre o inexistente en algún caso.

- Consideramos la oferta cono “no cumple” cuando el modelo de gestión descrito no se

ajuste a las particularidades del proyecto.

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

Conforme al artículo 150.4 del TRLCSP, para ser admitidos a la valoración global, se exigirá que en los criterios no cuantificables por fórmulas los licitadores alcancen un umbral mínimo de puntuación, de forma que no serán tenidas en cuenta las ofertas cuya puntuación (suma de la puntuación obtenida en Solución Técnica) no sea igual o superior a los 20 puntos, quedando automáticamente excluidas del resto del proceso selectivo.


11 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 teniendo en consideración la posibilidad de finalización anticipada por causas justificadas, motivadamente y con el preaviso establecido en el presente pliego.

Por incumplimiento del Acuerdo de Nivel de Servicio, según lo especificado en el apartado de acuerdo de nivel de servicios, en los apartados especificados.

Para ello, en el primero de los supuestos, EJIE comunicará al proveedor su intención con una antelación de un mes a la fecha de inicio de devolución del control.


12 Estructura y Formato de la Propuesta

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

12.1 Estructura normalizada y contenido de las propuestas.

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

Documento de Propuesta Solución Técnica, incluyendo:

Índice.

Presentación y Características Generales:

Identificación del pliego al que responde la propuesta.

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

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.

Descripción del alcance global de la solución

Equipo de trabajo:

Organización del equipo de trabajo.

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

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

responsabilidades, así como su tiempo total de dedicación en el proyecto.

Plan de trabajo

A nivel esquemático se incluirá el sistema propuesto para la identificación, registro, diagnostico y

resolución de incidencias.

Aplicación de metodologías y herramientas a utilizar

Procedimientos de gestión, control y seguimiento, y aseguramiento de la calidad

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

correcta gestión del proyecto, los mecanismo de control y seguimiento a aplicar, los procesos de

aseguramiento de calidad, así como aquellas otras medidas que se prevé emplear para vigilar y

garantizar el adecuado cumplimiento del contrato.

Modelo de gestión

Seguimiento y control

Procesos de seguimiento y control

Informes

Indicadores

Aseguramiento de la calidad (Modelo SQA)

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

pliego de condiciones técnicas - … · pliego de condiciones técnicas 3/46 contenido...

Documents