Pliego de Bases Técnicas - IVAP eus · Pliego de condiciones técnicas – Mantenimiento ATRIO...

Pliego de condiciones técnicas – Mantenimiento ATRIO 2014 1/41

Pliego de condiciones técnicas:

Sistema ATRIO: Mantenimiento 2014

Fecha: Julio de 2014 Referencia: 030/2014

EJIE S.A.

Mediterráneo, 14

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

Tel. 945 01 73 00*

Fax. 945 01 73 01

www.ejie.es

Este documento es propiedad de EJIE, S.A. y 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.

http://www.ejie.es/


Contenido

Capítulo/sección Página

1 Introducción y Necesidad de Contratación 4

2 Objeto del contrato 4

2.1 Objeto y Alcance del Servicio 4

2.2 Descripción del Servicio 4

2.3 Requisitos del servicio: Mantenimiento evolutivo - Gestión de contratos

menores 6

2.3.1. Documentación singular 6

2.3.2. Documentación genérica 7

2.3.3. Actualización del flujo de tareas 7

2.4 Requisitos servicio: Publicidad en contratos menores 11

2.4.1. Situación actual de la publicidad de los contratos en Revascon 11

2.4.2. Situación futura 12

2.4.3. Datos a remitir a Revascon 13

2.5 Requisitos del servicio: Ajustes de entrada en producción 13

2.5.1. Menú general de la aplicación 14

2.5.2. Actuaciones Preparatorias 15

2.5.3. Adjudicación 16

2.5.4. Documentación 17

2.5.5. Gestión 17

2.5.6. Operativa general 18

3 Plan de transición 19

4 Metodología Aplicable y Entorno Tecnológico. 20

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

4.2 Metodología de pruebas 23

4.3 Modelo de aseguramiento de la calidad (SQA) 24

4.3.1. Nivel de Aseguramiento de la Calidad 25

4.3.2. Plan SQA y actividades de aseguramiento de la calidad 25

4.4 Herramientas del ciclo de vida de las aplicaciones 26


4.5 Entorno Tecnológico. 27

5 Descripción de entregables. 30

5.1 Normativa para la puesta en producción 31

6 Planificación y Organización 32

6.1 Plan de Proyecto 32

6.1.1. Plan de Entregas e Hitos de Control 32

6.1.2. Diagrama de Gantt 33

6.2 Organización del Equipo de Trabajo 33

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

6.2.2. Equipo de Trabajo 34

6.3 Transferencia Tecnológica. 36

7 Presupuesto y oferta económica 36

8 Mecanismos de seguimiento y control 37

9 Plazo de ejecución, prórroga del contrato y Plan de pagos 38

10 Criterios de valoración 38

10.1 Propuesta económica 39

10.2 Planteamiento de la solución, plan de proyecto. 40

11 Estructura y Formato de la Propuesta 41

12 Estructura normalizada y contenido de las propuestas. 41


1 Introducción y Necesidad de Contratación

El Sistema ATRIO es el instrumento que sustenta el proceso completo de tramitación de un

expediente de contratación electrónica: preparación del expediente, licitación, adjudicación y

ejecución; publicando sus anuncios en el Perfil del contratante y en el DOUE.

Este sistema se ha puesto en producción recientemente y será necesario ampliarlo en función de

las necesidades que se detecten en el ejercicio de la tramitación de los expedientes de contratación

por parte de los distintos poderes adjudicadores que se incorporen en el uso de este nuevo

sistema.

Además se ha comenzado a utilizar esta aplicación para la gestión de contratos menores, para lo

cual se hace necesaria una adaptación de las actuales funcionalidades con el fin de contemplar

adecuadamente la publicidad y gestión interna de los mismos.

2 Objeto del contrato

2.1 Objeto y Alcance del Servicio

El objeto del servicio es dar continuidad a la aplicación ATRIO, que recientemente se ha puesto en producción

con una funcionalidad muy limitada pero que contempla la tramitación completa de un expediente de

contratación, trabajando en tres áreas de actuación: mantenimiento básico, mantenimiento evolutivo y la

creación de una oficina técnica para el soporte integral tanto a poderes adjudicadores de Gobierno Vasco y

dependientes como a otras entidades, en el despliegue del nuevo sistema.

2.2 Descripción del Servicio

A continuación repasamos las distintas áreas de actuación objeto del servicio:

1.-El Mantenimiento básico: Incluye

Mantenimiento correctivo: de cuantas incidencias se detecten que estén fuera del actual periodo de

garantía del sistema. Está orientado a la reparación de defectos existentes en un sistema software.

Estos defectos pueden manifestarse de distintas formas:

o Cuando el programa falla o termina inesperadamente. o Un programa produce un resultado que no es acorde con los requisitos.


Se contemplan dos tipos básicos de mantenimiento correctivo:

o Reparaciones de emergencia: ejecutadas en cortos periodos de tiempo y generalmente sobre un

único programa. o Reparaciones planificadas: arreglan defectos que no requieren una atención inmediata y re-

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

Mantenimiento adaptativo permitirá a la aplicación ser más eficaz y eficiente ajustándose a los

criterios tecnológicos establecidos por Ejie.

Son las modificaciones que afectan a los entornos tecnológicos 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 Cambios en el entorno de los datos o su procesamiento

o Cambios en la plataforma o arquitectura tecnológica o Modificación de procedimientos existentes que no implican nuevas funcionalidades (p.ej. cambios

en las herramientas de control de versiones, traspasos entre entornos, etc.) o Exportaciones e importaciones de datos dedicados a la integración con otras aplicaciones del

entorno, para mantenimiento de integridad de la información o Integración con otros aplicativos de plataforma de tecnológica (p.ej.: integración con elementos

horizontales de seguridad, monitorización, etc.) y de negocio. Se harán las adaptaciones que se consideren necesarias derivadas de cualquier cambio o mejora en los servicios de otras aplicaciones consumidos por el sistema ATRIO siendo estas en la actualidad: XLNets, Perfil de contratante, Licitación electrónica y Revascon.

o La parametrización de aplicaciones

o Cambios normativos

2.- Mantenimiento evolutivo del Sistema ATRIO en las siguientes líneas de actuación:

Gestión de contratos menores

Publicidad en contratos menores

Ajustes de entrada en producción

En la realización de los mantenimientos evolutivos y básicos, dado que las necesidades concretas no pueden

determinarse con total precisión “ex ante”, las peticiones de actuación del contratista y su priorización, serán

realizadas por el responsable del proyecto en Ejie en función del presupuesto disponible.


3.- Oficina Técnica que de un soporte integral al Sistema ATRIO así como a las distintas integraciones que

deben realizarse con otros sistemas o aplicaciones horizontales de Gobierno Vasco. Estas actividades deberán

ser realizadas preferentemente mediante la herramienta de gestión de peticiones de servicio (Mantis o su

posible evolución futura), 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

Soporte al entorno productivo del sistema durante el periodo de validez del contrato,

conformando un soporte de segundo nivel o soporte software, con respecto a la gestión de incidencias,

peticiones y consultas, provenientes de distintos colectivos de usuarios:

o Usuarios tramitadores de Gobierno Vasco y de otras administraciones públicas

o Responsables de la contratación electrónica (Dirección de patrimonio y contratación del

Departamento de Hacienda y Finanzas).

Realización y actualización de manuales de usuario tanto en castellano como en euskera,

así cómo el material formativo que se incluyan en el repositorio de información de Contratación

Pública en Euskadi acorde a cada versión que se suba al entorno de producción.

Dentro de esta categoría de tareas a realizar se encuadrarán las correspondientes a formación a formadores

que fueran necesarias para la correcta prestación de los servicios asociados.

2.3 Requisitos del servicio: Mantenimiento evolutivo - Gestión de contratos menores

El tratamiento de un contrato menor es el que marca estrictamente el procedimiento. Aunque el tramitador

podrá solicitar tantas ofertas cómo considere necesario, a esta solicitud no se podrá dar publicidad ni ser en

competencia (si esto fuera así ya no se tratará de un menor sino de otro procedimiento).

En definitiva el criterio que marca el tipo de procedimiento no es el importe sino el mecanismo de contratación

que se utilice. El importe condiciona los procedimientos de contratación que se pueden utilizar pero los

determina.

En solución a la normativa aplicable y a los requisitos de usuario recopilados sobre este particular (Contratos

menores) se solicita la solución a los siguientes requisitos.

2.3.1. Documentación singular

La documentación formal asociada a la tramitación de contratos menores será:

o Actuaciones preparatorias


Aún cuando podrá incorporarse cualquier tipo de documento que se considere pertinente a través de la pestaña “Documentación”, el documento que se considera más relevante dentro de esta fase

de la tramitación es la:

Memoria: A fin de facilitar la incorporación del mismo, se habilitará una pestaña dentro de

“Contratos menores -> Actuaciones preparatorias” denominada memoria para incorporar el

documento. Es opción permitirá firmar el documento. No obstante ni la incoporación de la

memoria al expediente, ni su firma serán obligatorias, quedando su utilización a la

discrecionalidad del tramitador/a.

Esta opción también se habilitará en el procedimiento general

o Adjudicación

Documento de aceptación: Se refiere al documento de aprobación del gasto o

aceptación de las ofertas recibidas por parte del mercado. Se denomina así porque los distintos poderes adjudicadores lo denominan de distintas maneras (documento de resolución, acuerdo de la junta de compras, etc…). Se incorporará la opción de firmar el mismo con el certificado de funcionario. La opción

de firma, estará siempre asociado a la “subida” o modificación del documento, no será una opción general de menú.

Presupuesto: En esta pestaña se pueden incorporar las ofertas recibidas por parte del

mercado. Se podrá por tanto subir más de un documento. Se habilitará también la opción de firmar cada uno de los mismos.

Facturas: Se permitirá la introducción de más de una factura.

De momento esta mejora se va a incorporar únicamente en los contratos menores aunque no es necesidad exclusiva de estos.

2.3.2. Documentación genérica

La pestaña “Documentación” independiente de las fases actuaciones preparatorias y adjudicación, permite la incorporación de cualquier documento que el tramitador considere oportuno incorporar al expediente.

Desde esta pestaña se podrá acceder también a los documentos incorporados y descritos en el apartado anterior (memoria, ofertas, documento de aceptación, facturas). Para mejorar la operativa se solicita que la pestaña de documentación se presente al mismo nivel que las pestañas de actuaciones preparatorias y adjudicación.

2.3.3. Actualización del flujo de tareas

Editable: el contrato menor será editable en cualquier momento, aún incluso cuando se haya enviado la información a Revascon.

Acciones directas: Hacer que los flujos “Nuevo > Rellenar datos > Adjudicación” y “Editar > Modificar datos > Adjudicación” se puedan hacer de forma directa sin que haya que ir al menú de

Adjudicación.


Copia: Desde la opción: Contratos Menores > Buscar Contratos Menores que se pueda crear un contrato como copia de otro. Esto facilitará la carga de datos/creación de contratos similares, por

ejemplo, cuando en un expediente los adjudicatarios son múltiples y se deben realizar varios contratos, uno por adjudicatario.

Duración del contrato: los datos computables serán obligatorios, mientras que el campo de texto libre no lo será en Atrio. No obstante, como este dato sí es obligatorio para Perfil, será necesario montarlo desde los valores computables cuando el dato esté vacío. Además se cambiará el literal como “Observaciones sobre la duración del contrato”.

Actuaciones preparatorias: Se incluirá en menú la opción de memoria (con opción de firma, no

obligatoria).

Adjudicación: En Documento de Aceptación, poner explicación con Alt (Resolución de

adjudicación, acuerdo de Junta de Gobierno, etc).

Adjudicación > Buscar Contrato Menor > Editar:

o Automatización del proceso/ simplificación: Con el fin de que el proceso del usuario sea

cómodo (o “normal” tratándose de una acción de introducir datos muy sencilla y,

generalmente, realizada en una sola sesión de trabajo), se estima necesaria la


consolidación automática en Revascon, que se pueda recoger el código de contrato y un botón que pueda recoger el justificante de consolidación. Son necesarias modificaciones

en Atrio, Perfil y Revascón, aplicación que además necesitará generar un nuevo servicio Web.

Adjudicación > Adjudicatario: se incorporará la consulta en Perfil de Adjudicatarios como primer desarrollo, para intentar evitar la contaminación de la base de datos y tener que depurar menos. En un desarrollo posterior, se accederá a consultar los adjudicatarios en ROC e Intentia.

Adjudicación > Documento de Aceptación: En la ventana de adjuntar el documento, habilitar un

botón de firmar documento.


Adjudicación > Factura: En la ventana de adjuntar el documento, habilitar un botón de firmar documento.

Adjudicación: Teniendo en cuenta los dos últimos puntos, se eliminan opciones del menú, que quedará de esta forma:


Adjudicación > Factura: Que se pueda adjuntar más de una factura, ya que hay prestaciones que se desarrollan a lo largo del tiempo y se pagan con cierta periodicidad.

2.4 Requisitos servicio: Publicidad en contratos menores

Se describen a continuación los requisitos definidos en este ámbito.

2.4.1. Situación actual de la publicidad de los contratos en Revascon

1. Desde el perfil Los usuarios que publican sus contratos menores o no en el Perfil de contratante, cuando se produce la formalización se precargan los datos en el Revascon automáticamente pendientes de consolidación. Una vez consolidados, están habilitados en Revascon para todas las funciones (TVCP, remisión Bruselas,

publicidad).

2. Remisión desde ATRIO: Diariamente desde ATRIO se remiten todos los contratos menores del día a Revascon, quedando en estado “no consolidado”

3. Publicación: Tras la consolidación el contrato menor ya es visible en el portal Web del Revascon cómo el resto de contratos. Es entonces cuando se deben generar los informes predeterminados para la OCE, TVCP, Madrid y Bruselas. Tras la consolidación, los usuarios pueden entrar en la aplicación Revascon para obtener el informe que acompañará a la factura a la OCE. Estos contratos menores consolidados en el Revascon aparecen también en el Perfil de adjudicatarios, y los adjudicatarios se incorporan a la base de datos de adjudicatarios, cómo se ha comentado en el

apartado 1.


2.4.2. Situación futura

Las tareas a realizar culminarán en que los contratos menores se publicarán en sólo en Revascon de las siguientes maneras:

1. Publicación pasando por Perfil (a descartar) Los contratos que se den de alta en ATRIO operarán desde ATRIO, no desde el Perfil a los efectos de

remitir la información al Revascon. Es decir, aunque a día de hoy el Poder adjudicador tiene la posibilidad de publicar en el Perfil y seguir la dinámica operativa de traslado de contratos de Perfil a Revascon esta opción se va a eliminar.

Los contratos menores no se publicarán en el perfil, puesto que este es para dar publicidad a las licitaciones y no es este el procedimiento “contrato menor”. Si se quiere dar publicidad estaremos ante un procedimiento negociado o abierto de pequeño importe y no incluye publicidad, ni precisa de bases

técnicas etc… 2. Remisión desde ATRIO directamente a Revascon:

a. Requerimientos a cumplir por el proceso: i. Que el traslado a Revascon desde ATRIO sea automático. ii. Que la consolidación sea automática a partir de la adjudicación de los contratos

menores.

iii. Que el informe de estar el contrato en Revascon y su número se pueda obtener desde ATRIO. Para lo cual se habilitará una nueva pestaña en la secuencia de contrato menor, a continuación de la pestaña documentación (esta opción se incorporará también para los mayores).

b. Publicidad: Dar la opción al poder adjudicador/usuario de elegir entre las siguientes opciones:

i. Que la publicación sea automática (a partir de la consolidación), cómo ahora: Cada vez que se consolida un contrato, se publica.

ii. Que la publicación sea programada (trimestral) 1. Que trimestralmente se publiquen los contratos (como aparecen actualmente

en el Revascon) 2. o (alternativa) que trimestralmente se genere y se publique un informe (foto

fija) descargable. Lo generará el Revascon a partir de la información que se

envíe. Esto implicaría que la información está disponible únicamente en dicho informe, la información asociada a dichos contratos no se puede explotar por las consultas y por tanto no se podría tener una visión completa de por ejemplo: (volumen de contratación total de poderes adjudicadores, volumen de contratación completa de una determinada empresa). Habría una opción en Revascon de informes trimestrales de contratos menores.

Lista acumulable. 3. Oferta ambas al poder adjudicador. Puesto que la construcción del informe apenas tiene coste añadido y esta doble prestación es muy sencilla de implementar.

Con lo cual las opciones de publicidad presentadas a cada poder adjudicador serían, de forma

abreviada: 1. Automática 2. Trimestral foto fija 3. Trimestral información explotable 4. Trimestral foto fija e información explotable En el alta no será obligatorio posicionarse, se podrá configurar. Por defecto la remisión será

automática.


2.4.3. Datos a remitir a Revascon

En la remisión de los contratos menores a Revascon se contempla la siguiente información:

Campos: La información que desde ATRIO se remita a Revascon sobre contratos menores será similar

a la que desde Perfil se está enviando a Revascon para cualquier otro tipo de contrato, puesto que son

los datos que se utilizan a efectos estadísiticos y de transparencia; en este sentido el tratamiento para

la remisión a Revascon es similar. Se identificará aquella obligatoria (*):

CIF/NIF*

Razón social*

País*

Código postal*

Código NUT’s* -> del lugar de la prestación del servicio.

Provincia -> No es obligatorio que lo introduzcan para los extranjeros. Para los NO extranjeros

se obtiene del código postal, por tanto en los nacionales se pasa siempre aunque el usuario no

lo haya cumplimentado.

Precio sin IVA *

Precio con IVA *

Fecha de comienzo de ejecución

Plazo*:

Plazo de ejecución (combo)

Fecha de ejecución

Duración del contrato (texto libre)

Al respecto lo que prevalece y es obligatorio es el combo, aunque se mantiene el campo de texto libre pero se sustituye la etiqueta actual con el siguiente literal: “Observaciones al plazo”.El campo observaciones irá detrás del campo plazo.

Fecha de adjudicación

Documentación: No se traspasa ninguna documentación.

Condiciones:

o Desde la opción de Actuaciones preparatorias en ningún caso se puede realizar la acción “envío a Revascon”

o Desde la opción de adjudicación: Una vez se haya cumplimentado la adjudicación se podrá hacer el “envío a Revascon”.

2.5 Requisitos del servicio: Ajustes de entrada en producción

La entrada en producción de cualquier herramienta requiere un proceso de ajuste de la herramienta fabricada y el modo de trabajar de los distintos usuarios. A continuación se detallan los ajustes detectados hasta la fecha. No obstante, cómo la experiencia ha demostrado que esta adaptación se realiza a lo largo de varios

meses, se contratará además una bolsa de horas para atender las demanda a medio plazo (próximos meses).


2.5.1. Menú general de la aplicación

Separar según procedimientos y acciones

Así como el primer grupo de acciones que se presentan en el menú de la aplicación son fases del proceso de contratación, las otras 3 acciones no tienen nada que ver. Se decide rediseñar el menú general con el objeto de diferenciar las acciones del procedimiento y el resto. Una alternativa podría ser incluir un espacio significativo entre la opción “Formalización” y la opción “Documentación”. Además, existirá una opción de menú especial para contratos menores, que integrará todas las

funcionalidades para este tipo de contratos. Estar opción, de igual forma, irá diferenciada para que no parezca ser una de las fases del proceso de contratación. La forma de diferenciación será similar a la tomada para el caso anterior, añadiendo además un cambio de color (el naranja usado en Revascón). El diseño sería similar al siguiente:

Contratos menores: Tal y como se ha comentado, dispondrán de opción específica. De todos modos, no se

quitarán los accesos a contratos menores desde Actuaciones Preparatorias y Adjudicación actualmente

activas.


2.5.2. Actuaciones Preparatorias

Memoria: Dentro de actuaciones preparatorias, se presentará una nueva opción, “Memoria” que

permitirá incorporar cualquier documento explicativo de la necesidad de contratación. Ofertará las

opciones de adjuntar y firmar, no siendo obligatorio.

Objeto del Contrato

Duración del contrato: los datos computables serán obligatorios, mientras que el campo

de texto libre no lo será en Atrio. No obstante, como este dato es obligatorio para Perfil,

será necesario montarlo desde los valores computables cuando esté vacío. Además se

cambiará el literal como “Observaciones sobre la duración del contrato”.

CPV: Tendrá un desplegable con todos los generales además de la actual funcionalidad de

búsqueda.

Editar - Resumen: La pestaña pasará a denominarse “Envío” y será accesible desde cualquier estado

del expediente. En la misma se presentará un resumen de los datos y las opciones de envío

correspondientes al estado y tipo de expediente.

Los datos del resumen presentado se ofertarán para su descarga en PDF, esta opción está ubicada tanto al

principio de la página cómo la final, para evitar el scroll al usuario.


Así mismo en la pantalla de resumen se deberá habilitar, de la misma forma que actualmente se refleja las remisiones de DOUE, Perfil y Licitación, se deberá habilitar la opción “Revascon” (esta opción permitirá

descargarse el informe de consolidación de cualquier contrato tramitado desde ATRIO aunque haya pasado también por el Perfil).

2.5.3. Adjudicación

Estado de la tramitación

En el menú de adjudicación deberá aparecer la columna estado que define el estado de la tramitación del expediente, de la misma forma que aparece en actuaciones preparatorias.

Factura: La factura no va a Perfil nunca y se podrán adjuntar varias facturas y firmar cada una de ellas (no siendo esto obligatorio).

Más acciones La pestaña “Más acciones” se va a redefinir para hacerla más práctica desde cualquiera de las tramitaciones, entretanto para los contratos menores únicamente ofertará la acción “Remisión a Revascon”. Cómo se describirá en el apartado siguiente “contratos menores”, la secuencia de tramitación a Revascon se hará de la siguiente forma:

o Automatización del proceso/ simplificación: Con el fin de que el proceso del usuario sea

cómodo (o “normal” tratándose de una acción de introducir datos muy sencilla y, generalmente, realizada en una sola sesión de trabajo), se estima necesaria la consolidación automática en Revascon, que se pueda recoger el o los códigos de contrato y un botón que pueda recoger el justificante de consolidación. Son necesarias modificaciones en Atrio, Perfil y Revascón, aplicación que además necesitará generar un nuevo

servicio Web.


2.5.4. Documentación

En la opción de anexar documentación, cambiar la opción ‘Detalles’ por un literal más descriptivo (‘Editar’ o

‘Acceder’, por ejemplo).

2.5.5. Gestión

Perfil “impulsor”: La unidad administrativa que tiene la necesidad e impulsa en primera instancia la

tramitación del expediente, pueda tener acceso a la información de dichos expedientes de la misma

manera que el perfil auditor: “ver y no tocar”, a fin de que acceda directamente al estado de

tramitación del expediente de su interés (“cómo está lo mío”). Este nuevo perfil de usuario será objeto

de una reflexión más profunda para definir correctamente su alcance.

Gestión > Departamentos > Nuevo, Gestión > Departamentos > Editar: Hacer mantenible la

información de precarga de contactos técnico y administrativo y de lugar de presentación de

solicitudes.


2.5.6. Operativa general

Unificar con el comportamiento del Perfil: por ejemplo en Perfil se graba con pestañas y con acción

explícita, en ATRIO no y a veces despista a los usuarios pensando que tienen que hacer alguna acción.

(Ejm. En EJIE le dieron a publicar pensando que era la única manera de grabar la información que

acababan de meter).

Orquestación y simplificación: Siendo ATRIO la herramienta que sustenta toda la tramitación (ciclo

de vida) de los expedientes de contratación, se solicita mayor integración con las aplicaciones gestoras

(Perfil, Licitación) con el objetivo de simplificar las tareas al tramitador y consolidar ATRIO cómo

herramienta de gestión única durante el proceso. De manera que sea transparente para el usuario lo


que pasa detrás o qué herramienta está haciendo la tarea. Se debiera ofertar acceso a Licitación a lo

largo de toda la tramitación del expediente, o para consultarlo. De esa forma, desde el excipiente en

ATRIO, el tramitador tendría un acceso (por ahora solo al expediente, en el futuro lejano al trámite

concreto que quiere tramitar: Alta de Mesa, Gestión de Sobres, apertura, Actas, Adjudicación, etc.).

Para este requisito, se solicita una propuesta para realizar el análisis y diseño de alternativas y

además una estimación inicial para su desarrollo. El desarrollo se ejecutará en función de las actuales

capacidades de las aplicaciones afectadas y la estimación que se ajuste a presupuesto del presente

pliego.

Informe: En la pestaña Resumen en Generar Informe en el pdf que se genera no aparecen los datos

del nombre en el campo Contacto Técnico y Contacto Administrativo. -> Se va a incluir el dato en el

informe.

Importes: El importe del presupuesto sin IVA de ese mismo informe, aparece sin puntos ni comas

(P.e.: 39170) -> Formatear todos los campos importes.

Importe con y sin IVA: Ahora son obligatorios los dos (para posibilitar la consolidación automática en Revascon). Además se solicitará que se cumplimente el dato “Tipo de IVA”.

Lugar de apertura de plicas: Si se carga esta información además se tendría que pasar al perfil /

licitación. A día de hoy no tenemos claro que se pueda hacer, pero por si acaso se contemplará en la

siguiente contratación.

Presupuesto: A veces ponen un valor pero luego el importe real (el que se paga) puede ser distinto.

Cambio en literales: Con el resultado de la reflexión completa de todos los literales de la aplicación.

Modificación de datos: Tras la firma de la factura, se dejará abierta la posibilidad de realizar

modificaciones y por tanto de envío a Revascón. Se ha solicitado para poder corregir errores

especialmente en el importe o el plazo.

Búsqueda de adjudicatarios: se incorporará la consulta en Perfil de Adjudicatarios como primer

desarrollo, para intentar evitar la contaminación de la base de datos y tener que depurar menos. Se

valorará cargar de inmediato en la BD de adjudicatarios toda la base del ROC y, semestralmente,

actualizarla con las nuevas altas. En un desarrollo posterior, se accederá a consultar los adjudicatarios

en ROC e Intentia.

Mesa de contratación: No será un dato obligatorio. Esta información no es obligatoria en el paso a

Revascon.

Pero no se quiere eliminar este campo por distintos motivos, ya que puede ser un dato de transparencia o interno de gestión. No obstante es un dato que será precargado, muchos

tendrán este dato informado. Pero algunos usuarios han indicado que no es correcto solicitar mesa de contratación. Por tanto el tratamiento de este campo será:

1. No es obligatorio

2. No se precarga en contratos menores -> Sí se precarga en “mayores”

3. Se podrá informar por aquellos usuarios que así lo quieran.

3 Plan de transición

La oferta deberá presentar claramente tanto el plan de transición de entrada de servicio como de salida al finalizar el contrato.


Al finalizar el periodo del presente contrato, el adjudicatario estará obligado, por un periodo anterior a la finalización o posterior a prestar apoyo, y realizar la transferencia del conocimiento, documentación, etc. al siguiente adjudicatario del contrato en caso de que éste sea distinto al adjudicatario del presente pliego.

4 Metodología Aplicable y Entorno Tecnológico.

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

La organización del trabajo y ejecución del proyecto estará basada en la metodología de planificación y

desarrollo de sistemas de información ARINbide v1.1., y la metodología de pruebas PROBAMET v2.0.

ARINbide v1.1 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 define los siguientes procesos:

Ingeniería del Software (ISW)

Gestión del Proyecto (GPR)

Gestión de Riesgos del Proyecto (GRP)

Gestión de la configuración (GCO)

Mantenimiento del Sistema de Información (MSI)

El proceso principal de ingeniería del software (ISW) describe y normaliza la secuencia de fases y actividades a

realizar en el proyecto de desarrollo de un sistema de información, así como los entregables a obtener en cada

una de ellas. En este ámbito, ARINbide v1.1 contempla el desarrollo de las siguientes fases metodológicas:

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

Información, ASI)

Análisis del sistema (ASI)

Diseño del sistema (DSI)

Construcción del sistema (CSI)

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

El ciclo de vida descrito en la metodología de desarrollo ARINbide se alinea y complementa a lo largo del

tiempo con la metodología de pruebas corporativa Probamet, centrándose ésta última en la especificación de

todas las actividades relacionadas con la planificación, definición y ejecución de los diferentes tipos de


pruebas. Existe una correspondencia entre las fases de ejecución de ARINbide y las fases de ejecución de

Probamet.

Información detallada sobre las fases y entregables de la metodología ARINbide, se encuentra en la página

web de Ejie.: http://www.ejie.net/metodologia_desarrollo.htm

En las distintas fases del proyecto, teniendo en cuenta la mencionadas metodologías la empresa adjudicataria

deberá contemplar, entre otros, los siguientes elementos:

Catálogo de Requisitos de Usuario. Debe incluir:

La definición del sistema

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

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

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

Análisis de las aplicaciones, ASI (ERS)

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

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

Usuario.

Diseño del sistema. Lo realizará en su totalidad el adjudicatario 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

http://www.ejie.net/metodologia_desarrollo.htm


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

y el sistema construido.

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

Manual de instalación / Explotación.

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

castellano.

Formación a los usuarios y administradores del sistema.

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.

Además se ha trabajado recientemente en configurar la herramienta Anthillpro para utilizar en

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

4.2 Metodología de pruebas

De forma alineada y paralela a ARINbide, la metodología de pruebas PROBAMET, define las fases y actividades

referentes al proceso de pruebas de un producto software. El adjudicatario del presente contrato deberá

contemplar la realización de dichas actividades, de forma paralela a las actividades de ARINbide.

Información detallada sobre las fases y entregables de la metodología PROBAMET, se encuentra a disposición

del licitador en http://www.ejie.net/aseguramiento_calidad.htm

PROBAMET describe las siguientes fases:

Planificación y Seguimiento de las Pruebas – PPB

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

Ejecución de las Pruebas – EPB

http://www.ejie.euskadi.net/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/anexos_pbt.html

http://www.ejie.euskadi.net/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/anexos_pbt.html

http://www.euskadi.net/informatika

http://www.ejie.net/aseguramiento_calidad.htm


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

Planificación de las Pruebas. Incluye:

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

Planificación (cronograma) de actividades

Identificación de factores de riesgo

Seguimiento de las Pruebas. Incluye:

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

Informes de seguimiento de las pruebas realizadas

Análisis y Diseño de las Pruebas:

Especificación de los casos de prueba

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

Trazabilidad)

Ejecución de las Pruebas. Incluye:

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

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

Análisis estático de código.

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

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

incrementando la prueba de los módulos y sistemas.

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

Funcionales y Pruebas del Sistema No Funcionales

Pruebas de Aceptación: pruebas del usuario.

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

4.3 Modelo de aseguramiento de la calidad (SQA)

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

productos.

Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el

adjudicatario deberá contemplar y proveer la documentación que sea requerida en cumplimiento de la

metodología ARINbide.


Por otro lado, con el objetivo de asegurar la calidad en el proceso de elaboración y la calidad de los

productos software y documentales obtenidos, será de referencia obligatoria el Modelo de Aseguramiento de

la Calidad (Modelo SQA) definido por 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 y cumpliendo implícitamente la metodología de

pruebas PROBAMET

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

permitidos.

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

Información detallada sobre los roles contemplados, las actividades y entregables del Modelo SQA, así como

de las herramientas y tecnologías a utilizar, se encuentra a disposición del licitador en


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

contratación.

4.3.1. Nivel de Aseguramiento de la Calidad

El NAC asignado para este proyecto es: BAJO

4.3.2. Plan SQA y actividades de aseguramiento de la calidad

Al inicio del proyecto se elaborará el Plan SQA del mismo, estableciendo el detalle de las actividades de

calidad a realizar, sus esfuerzos y fechas de compromiso según el Plan de Entregas obtenido en ARINbide y en

función del NAC calculado.

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

Verificación documental: Revisión de la documentación entregable de ARINBIDE y PROBAMET,

realizada para asegurar que el formato y contenido de la documentación del proyecto cumple con

las metodologías y los estándares de calidad de EJIE. Incluye para todos los entregables:

Checklists de Verificación de ARINbide

Checklists de Verificación de PROBAMET

http://www.ejie.net/anexos_PBT.htm

http://www.ejie.net/anexos_PBT.htm



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

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

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

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

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

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

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

Pruebas de Integración.

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

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

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

Recuperación del Sistema.

Ejecución selectiva de pruebas: Si se considera necesario, se contempla la ejecución selectiva de

un conjunto de pruebas adicionales con el objetivo de reforzar el proceso de calidad,

independientemente de las pruebas que se definan en el Plan de Pruebas de PROBAMET.

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

fase de Implantación (IAS) de ARINbide, y las pruebas de Aceptación de usuario, en base al Plan

SQA del proyecto. Sigue la misma operativa que las Auditorías de Fin de Fase y obtiene de forma

incremental el mismo informe pero dando la visión global del grado de calidad del proyecto y las

conclusiones derivadas.

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

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

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

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

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

Dada la no existencia de una Oficina Técnica de Calidad de proyecto, paralela a la ejecución del presente

proyecto, y por tanto, la asunción de dicho rol por el adjudicatario del proyecto (además de las tareas del rol

propio de Desarrollo y Pruebas), el adjudicatario deberá contemplar la ejecución de las tareas mencionadas en

el presente apartado.

4.4 Herramientas del ciclo de vida de las aplicaciones

Como soporte e instrumento necesario en la ejecución de todas las fases del proyecto, existe un conjunto de

Herramientas homologadas por 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.

4.5 Entorno Tecnológico.

El entorno tecnológico será el definido en los estándares del Gobierno Vasco y la Dirección de Patrimonio y

Contratación del Departamento de Economía y Hacienda y que se consideren necesarios para la ejecución de

este proyecto conforme a sus características específicas.

Existen un conjunto de utilidades y sistemas horizontales de uso corporativo que dan solución tecnológica a

distintos ámbitos funcionales de uso común, que se citan a continuación, y que el proyecto objeto de

contratación deberá contemplar según sus necesidades.

Para las áreas funcionales de tramitación de expedientes del sistema final se deberán seguir las directrices

marcadas por el modelo básico de tramitación (MBT) del Gobierno Vasco, es decir, identificar la familia a la

cual pertenece el procedimiento a mecanizar, recoger los datos mínimos definidos como invariantes de

información, modelar los trámites establecidos como invariantes de tramitación, e informar al sistema de

visión de ciudadano (Mis Gestiones). Además, con objeto de simplificar y homogeneizar los puntos de acceso y

las interfaces gráficas de usuario, y de asegurar una correcta interpretación de las normas legales vigentes, el

nuevo producto deberá hacer uso del conjunto de módulos y sistemas comunes que constituyen el núcleo de

elementos corporativos horizontales de base de plataforma tecnológica de e-Administración, PLATEA,

desarrollando y completando por lo tanto todo aquello que dichos sistemas requieran:

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

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

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

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

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

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

Para la publicación de contenidos y aplicaciones en Internet, deberá seguirse la normativa corporativa así

como las herramientas de soporte al modelo de presencia en Internet:

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

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

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


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

aplicaciones en la propia infraestructura de portales.

Como plataforma de integración entre sistemas:

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

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

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

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

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

(suscripción a eventos).

Como referencia obligada respecto a los ámbitos mencionados, deberá considerarse el documento PLATEA –

Plataforma Tecnológica para la e-Administración.

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

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

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

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

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

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

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

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

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

Para los desarrollos basados en entorno tecnológico JAVA, el nuevo sistema a implantar utilizará el conjunto

de Utilidades de Desarrollo de Aplicaciones (UDA) homologadas para el entorno de desarrollo Weblogic 11:

UDA: Conjunto de herramientas, tecnologías, componentes y normativas funcionales y técnicas

que permiten acelerar y normalizan el proceso de construcción de aplicaciones JEE en el ámbito

de Gobierno Vasco – Ejie. En la dirección http://code.google.com/p/uda/ se detalla más

información acerca del sistema.

Debido a la diversidad de aplicaciones y las distintas necesidades, pueden surgir nuevos patrones de

comportamiento para los que no exista un componente disponible en UDA en el momento del desarrollo de la

aplicación. En estos casos, el adjudicatario puede desarrollar su propio componente para cubrir la

funcionalidad necesaria bajo la supervisión del grupo de Consultoría de Áreas del Conocimiento, y una vez

desarrollado el componente (junto con su documentación) deberá ponerla a disposición de este grupo para ser

incorporado en la lista de componentes de UDA

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


Otros productos y soluciones corporativas existentes son los siguientes:

Gestión de procesos batch:

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

CONTROL-M: Planificación de procesos batch

Generación de informes:

Jreport. Existe un middleware corporativo (T43) para uso por las aplicaciones departamentales,

con tecnología J2EE.

Reporting Services (Microsoft)

Business Intelligence:

Oracle Business Intelligence

Bitam

Sistemas de Información Geográfica:

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

Servicio de envío de mensajes SMS:

SMS Corporativo, basado en plataforma Latinia

Además de los sistemas horizontales especificados, el nuevo sistema, según sus necesidades, deberá utilizar

los módulos y servicios establecidos por el Plan de Informática y Telecomunicaciones del G.V. y especificados

en el documento de guía de estándares tecnológicos.

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

Servidor web:

Apache Web Server 2 sobre Linux Red Hat Enterprise.

Bases de datos:

Oracle 10g sobre HP-UX

SQL Server 2005

Seguridad:


XLNets y PKI Izenpe

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

Interwoven TeamSite 6.7

Open Deploy 6.1

Autonomy

Infraestructura para la gestión documental (dokusi):

Documentum

Gestión de versionado de aplicaciones:

Subversion

Documentación y trabajo en grupo:

SharePoint Portal Server

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

Servidor de aplicaciones:

Oracle Weblogic Server 11g (10.3.5) sobre Linux Red Hat Enterprise

Herramientas para desarrollo:

Utilidades de Desarrollo de Aplicaciones (UDA)

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

En todos los casos, y según corresponda al entorno tecnológico a utilizar, se utilizarán igualmente las

Herramientas del ciclo de vida de las aplicaciones

Existe asimismo un conjunto de librerías software soportadas, recogidas en los manuales de albergue de

aplicaciones, que deberán contemplarse según corresponda, en el proceso de diseño técnico y construcción del

sistema (FOP, POI, JasperReports, LinearBarCode, JfreeChart, IAIK, …)

5 Descripción de entregables.

Los productos a entregar, tanto productos software como documentación, serán aquellos que define la

metodología de desarrollo ARINBIDE, en referencia a las fases definidas dentro del alcance del proyecto.

Igualmente, dentro del alcance definido del proyecto, la Metodología de Pruebas, así como el modelo de

Aseguramiento de la Calidad de Sistemas Software, detallan los entregables a proporcionar en el ámbito de la

calidad.

http://www.ejie.net/metodologia_desarrollo.htm




Con independencia de lo descrito y requerido a nivel metodológico (metodología de desarrollo ARINbide

v1.1, y Metodología de Pruebas PROBAMET v2.0), a continuación se añaden tareas y entregables a

realizar/suministrar por el adjudicatario:

Implantación en el Entorno de Desarrollo de Ejie.

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

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

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

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

La aplicación, las páginas, los textos, tablas de códigos, los mensajes de error/aviso y/o

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

estar en ambos idiomas: euskera y castellano

Entrega de fuentes de todos los componentes, ficheros de configuración, elementos gráficos

utilizados,…..y cualquier otro elemento que se considere necesario para el normal y adecuado

mantenimiento/evolución del sistema, en soporte magnético (DVD).

Confección y entrega de la documentación (funcional, técnica, de explotación y de usuario)

correspondiente a cada una de las fases del proyecto tanto en formato papel, como en formato

electrónico.

Todos los entregables deberán proporcionarse utilizando las herramientas homologadas en Ejie para el ciclo de

vida de las aplicaciones, o en su caso proporcionando formatos compatibles.

5.1 Normativa para la puesta en producción

Ejie cuenta con actividades formalizadas para la gestión e implantación de los sistemas de información

generados en los distintos entornos, establecidas en base a los procesos de Gestión de Cambios y Gestión de

Despliegues.

A partir de estos procesos se garantiza que los sistemas que serán instalados en la infraestructura de Ejie

cumplen con los estándares y normativas técnicas de la organización, que no impactarán en el correcto

funcionamiento del resto de productos y que se conocen los procedimientos y particularidades relacionadas

con su operación y soporte.


Para ello, es necesario que durante el ciclo de vida del proyecto, el equipo de trabajo genere una serie de

entregables, que serán validados a través del proceso de Gestión de Cambios:

Documentos de requisitos de proyecto para procesos: contendrá requisitos relacionados con

las necesidades infraestructura y el soporte futuro de los procesos que pueden afectar al diseño

técnico o funcional de sistema de información a generar

Documento de albergue: recogerá el diseño de la solución desde el punto de vista técnico,

incluyendo aspectos de monitorización, crecimiento, estacionalidad si fuera necesario

Documentos de aprovisionamiento de entorno: fichas utilizadas para el aprovisionamiento

de un entorno estándar sobre el que luego desarrollar o implantar el nuevo sistema

Manual de implantación: deberá recoger los aspectos técnicos y configuraciones necesarias

que deben ser realizadas para implantar la aplicación en un entorno tecnológico de Ejie.

Manual de soporte: contendrá el conocimiento necesario para que Ejie pueda proporcionar

soporte técnico al sistema implantado, de forma autónoma y a través de sus procesos de

soporte. Incluirá datos referentes a errores conocidos, procedimientos de resolución,

proveedores de soporte, contactos, garantías, modelos de cambio y cualquier aspecto relevante

para el soporte del sistema

Manual de operación: refleja la información necesaria para el arranque, parada, y

mantenimiento técnico del nuevo sistema, incluyendo aspectos de monitorización, capacidad y

personal de contacto en caso de fallo.

Para cada uno de estos documentos Ejie dispone de plantillas estándar que el proveedor deberá utilizar y

entregar según los procedimientos establecidos.

Asimismo, en la cumplimentación de las plantillas se podrá solicitar el asesoramiento de los distintos

Responsables de Proceso y Coordinadores de Infraestructura, para asegurar que la solución construida e

implantada cumple con la normativa de Ejie y es posible operarla y soportarla con garantías.

6 Planificación y Organización

6.1 Plan de Proyecto

6.1.1. Plan de Entregas e Hitos de Control

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


Fases y tareas del proyecto,

Entregas resultantes de cada fase,

Hitos de control y/o verificación, junto con sus correspondientes fechas orientativas de

finalización.

Así mismo, el licitador podrá establecer propuestas de entregas y/o certificaciones parciales acordes con el

planteamiento del proyecto establecido, siempre que:

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

contrato.

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

Proyecto.

6.1.2. Diagrama de Gantt

El licitador deberá presentar un Diagrama de Gantt o Cronograma de las Fases y Tareas propuestas para la

ejecución de las realizaciones objeto del servicio a contratar

6.2 Organización del Equipo de Trabajo

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

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

resultantes del presente servicio a contratar, así como

Las funciones de los mismos, y

La relación nominal de los participantes.

6.2.1. Asignación de recursos a fases del proyecto

- El licitador deberá incluir en la 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 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

TOTAL

- El licitador deberá incluir en la propuesta técnica, un desglose de horas y % de dedicación total por perfil y

requisito del proyecto (según lo establecido en el apartado 2.3 del presente pliego).

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

valorar el grado de aproximación a la planificación del proyecto según la estimación del licitador, permitiendo,

de esta forma, valorar la idoneidad del dimensionamiento del equipo de trabajo propuesto y su adecuación a

la consecución de los objetivos. No obstante este desglose de horas no se considera vinculante, al no tratarse

de una contratación de horas de desarrollo, sino un proyecto “llave en mano” según el importe total ofertado.

.

6.2.2. Equipo de Trabajo

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de

especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que

se vayan desarrollando.

Constitución inicial del equipo de trabajo

El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar

formado por componentes relacionados en la oferta adjudicataria y consecuentemente valorados.

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el Documento de

Propuesta Técnica objeto de la misma y:

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

motivo que suscita el cambio, se procederá a:

o La presentación por el adjudicatario de candidato o candidatos con un

perfil de cualificación técnica igual o superior al de la persona que se

pretende sustituir.


o Aceptación 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 las

modificaciones de los recursos, 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.

Modificaciones en la composición del equipo de trabajo

La valoración final de la calidad de los servicios objeto del presente pliego a contratar 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 o superior 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 sustituto o sustitutos con un perfil de cualificación técnica igual o superior al de la

persona que se pretende sustituir.

Aceptación de los perfiles propuestos 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.

Horario y lugar de prestación de los servicios 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 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:

Ejie determinará horario de prestación de los servicios.

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 precio aplicable a las mismas.

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

6.3 Transferencia Tecnológica.

Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo momento, a

facilitar a las personas designadas por la Dirección del proyecto de 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.

7 Presupuesto y oferta económica

En los precios ofertados se entenderán ya incluidas las posibles dietas y gastos de desplazamiento.

El presupuesto máximo del contrato es de 95.000 € sin IVA. El presupuesto máximo del presente contrato es

la suma de dos conceptos:


- Por una parte, el denominado importe o presupuesto evolutivo, incluye el desarrollo e implantación de

los requisitos del servicio descritos en el apartado 2.3 del presente pliego.

- Y por otra parte, el denominado presupuesto básico que incluye el resto de servicios objeto del

presente contrato, y que es una cantidad variable en función de la demanda concreta de los servicios

relacionados.

Por tanto el presupuesto total del contrato: 95.000 € (IVA no incluido), se distribuye en:

- Presupuesto básico: En este concepto se incluye el mantenimiento básico, la oficina técnica y la

bolsa de horas solicitada de mantenimiento evolutivo para los ajustes de la entrada a producción. El

presupuesto máximo por este concepto de 55.000 € (IVA no incluido).

- Presupuesto evolutivo: En este concepto se incluye el mantenimiento evolutivo siendo el

presupuesto máximo por este concepto de 40.000 € (IVA no incluido).

El valor estimado es de 95.000 € (IVA no incluido).

8 Mecanismos de seguimiento y control

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

de Ejie.

El control y seguimiento de la calidad de servicio, será realizado por 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.

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

desarrollada.

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.

Supervisión del proyecto, tanto la dirección como la supervisión del Proyecto serán llevadas a cabo por el

personal de Supervisión del proyecto de EJIE asignado al proyecto.

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, cualquier otro documento complementario, en orden a la comprobación de cuantos datos

haya ofrecido la empresa licitadora, tanto respecto a sí misma como con respecto al personal propuesto.


Asimismo, la designación de técnicos realizada por la empresa adjudicataria podrá ser modificada a simple a

petición de Ejie, en caso de que ésta advierta un incumplimiento de las condiciones que motivaron la

adjudicación. En este caso, la empresa adjudicataria quedará obligada a proponer otras personas con categoría y

circunstancias personales y profesionales idénticas o similares a las inicialmente propuestas, sin que dicha

circunstancia altere, en ningún caso, el precio ofertado.

9 Plazo de ejecución, prórroga del contrato y Plan de pagos

Plazo:

El plazo de ejecución de las prestaciones contratadas se iniciará en el ejercicio 2014, siendo la vigencia

de un año a partir de la formalización de contrato.

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 una parte del mismo (Mantenimiento

básico y parte del presupuesto evolutivo) será el resultado de los servicios efectivamente prestados por el

contratista, aplicando a los mismos el precio de la adjudicación.

Igualmente, debe señalarse que dada la actual situación económica y financiera en general, EJIE, S.A. 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 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, y ello sin perjuicio de las consecuencias económicas derivadas de la misma.

Plan de Pagos.

El precio de los trabajos se determinará a través de unidades de tiempo/hora, realizando los pagos de forma

mensual con el cálculo de los trabajos del mes en curso a través del precio/hora.

10 Criterios de valoración

En el proceso de selección de ofertas, se valorarán los siguientes puntos:

Característica / Objeto de valoración Puntos

Propuesta económica 55

Proposición económica del Mantenimiento evolutivo - requisitos 30

Proposición económica del Mantenimiento básico y oficina técnica 25

Planteamiento de la solución, plan de proyecto 45

Calidad técnica 15

Fases del servicio 10


Valor añadido 5

Plan de transición 10

Control y seguimiento del servicio 5

10.1 Propuesta económica

La proposición económica se valorará tomando como base dos partidas bien diferenciadas:

Proposición económica del Mantenimiento evolutivo

Proposición económica del Presupuesto básico

Dicha valoración obedecerá a las siguientes reglas:

Proposición económica del Mantenimiento evolutivo

Se valorará bajo la siguiente fórmula:

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

Precio de la oferta evaluada

Proposición económica del Mantenimiento básico y oficina técnica

Se calculará sobre el valor ponderado de las tarifas de los distintos perfiles ofertados en la

planificación y composición del equipo de trabajo, y utilizando la siguiente fórmula de

valoración.

Total puntos prop. econ. evol/adapt. 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 € 10% YY €

Analista funcional XX € 30% YY €

Analista programador senior XX € 30% YY €

Programador Senior XX € 20% YY €

Programador XX € 10% YY €

TOTALES 100% **ZZ €

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


Ofertas con valores anormales o desproporcionados: En el caso en que la tarifa por

perfil ofertada sea inferior al 30% del valor medio de las tarifas ofertadas para dicho

perfil no se tendrá en cuenta en para el cálculo de la tarifa media ponderada de dicha

oferta.

10.2 Planteamiento de la solución, plan de proyecto.

Para la valoración del planteamiento de la solución, plan de proyecto se valorarán los siguientes

criterios:

Calidad técnica (hasta 15 puntos). Se valorará el contenido y alcance de la descripción

técnica de la oferta, grado de detalle y concreción de la propuesta (hasta 5 puntos). Se

valorará especialmente el entendimiento de los requisitos a implementar por el

proyecto y de las áreas funcionales del mismo (hasta 5 puntos)

Fases del servicio (hasta 10 puntos). Se valorará el grado de detalle y concreción de la

planificación propuesta y esfuerzo estimado para las distintas actividades y requisitos

solicitados en el servicio (5 puntos) así como la organización e interlocución, y

distribución de los esfuerzos y equipos de trabajo (5 puntos).

Valor añadido (hasta 5 puntos). En este punto se valorarán aquellas actuaciones tanto

funcionales como técnicas que el proveedor plantee en su oferta y se considere

beneficiosas para los trabajos a contratar, y que no suponen un incremento en el

precio ni una variante.

Plan de transición (hasta 10 puntos). Se valorará la descripción de las actividades

orientadas a capacitar tanto a EJIE como a siguientes adjudicatarios para dar la

correcta continuidad al servicio.

Control y seguimiento del servicio (hasta 5 puntos), que incluye la gestión de riesgos,

cumplimiento de estándares y aseguramiento de niveles de calidad.

Para resultar adjudicatario del servicio el licitador deberá haber obtenido como mínimo

una valoración de 15 puntos entre los criterios de Calidad técnica y Fases del servicio.


11 Estructura y Formato de la Propuesta

De acuerdo con las posibilidades ofrecidas por el Real Decreto Legislativo 3/2011, de 14 de noviembre, por el

que se aprueba el texto refundido de la Ley de Contratos del Sector Público y por la Ley 11/2007, de 22 de junio,

de acceso electrónico de los ciudadanos a los Servicios Públicos, la oferta de las Empresas licitadoras al

procedimiento abierto y la forma de adjudicación de concurso para la contratación de los servicios de Soporte al

área temática de Contratación Pública en Euskadi, sólo podrá efectuarse por procedimientos electrónicos.

Las ofertas deberán presentarse en el sitio Web www.contratación.euskadi.net a través de la cual podrán

acceder a la aplicación de licitación electrónica.

12 Estructura normalizada y contenido de las propuestas.

La estructura de la Oferta Económica y Técnica a presentar a través del sistema de Licitación

Electrónica se deberá adecuar a este esquema:

- Sobre A: Capacidad y Solvencia.

- Sobre B: Propuesta Económica.

o Según Anexo I del pliego de condiciones particulares

- Sobre C: Propuesta Técnica.

o Planteamiento de la solución, plan de proyecto.

Pliego de Bases Técnicas - IVAP eus · Pliego de condiciones técnicas – Mantenimiento ATRIO...

Documents

Transcript of Pliego de Bases Técnicas - IVAP eus · Pliego de condiciones técnicas – Mantenimiento ATRIO...