r

U?

lHñmRLSL?ª.CVVNT-%'é

l GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA

CONTRATACIÓN DE DESARROLLO MEDIANTE EL SISTEMA DE

TRAMITAC?ÓN ELECTRÓNICA AL-SIGM DEL MÓDULO DE

ARCHIVO DEL TRIBUNAL DE CUENTAS.

k W? ?))- @3aIW. >

y QJJ '7

ldel3

rl

!,/?

ÑWlm'-S.ll. Mí,€:U».Nt.N;í

»GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

1 ANTECEDENTES 3

2 0BJETO DEL CONTRATO 4

3 ENTORNOYREQUIS?TOSTECNOLÓG?COS s

3.1 ARQUlTECTuRA 5

3.2 REUTILIZAClóN DE CóDlG0 6

3.3 CALIDADDELSOFTWARE 6

3.4 RENDIM?ENTO 6

3.5 ESCALABIL?DAD 7

3.6 MONlTORlZAClóN 7

3.7 PARAMETRIZACIÓN 7

3.8 REGISTRO DE SLICESOS (IOGS) 7

3.9 GESTlóN DE ERRORES 8

3.10 ENTORNOS 9

4 DESARROLLO DE 105 TRABAJOS g

5 DESCRIPCIÓN FUNCIONAL DEL SISTEMA io

6 FASE DE PRUEBAS E IMPLANTACIÓN 12

7 FORMACIÓN 13

4'hG Cc%-r

?á'f( Ql ,J

2del3

i

l,/?

fRljUÍ:L%L )K CL'r-'€T-'Iéá

r IGERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junío de 2017

1 ANTECEDENTES

El Archivo General del Tribunal de Cuentas ha venido desarrollando e implantando a lo

Iargo de los últimos años un conjunto de herramientas informáticas destinadas a

recoger la información del Archivo y a gestionar diversas actuaciones de custodia,

control, selección, servicio, descripción y acceso. Se trata de una serie de bases de

datos y de aplicaciones que en la actualidad recogen información de más de 750.000

cajas de documentos, a las que se ha de sumar la información de las más de 300.000

cajas eliminadas hasta la fecha y de los más de 600.000 ficheros electrónicos que han

sido remitidos al Archivo junto con la documentación en papel.

Este conjunto de bases de datos desarrollado inicialmente en Microsoft Access y

convertidas a SQL Server, está compuesto por las bases de datos de Transferencias,

njuiciamiento, Revisión de ficheros y obtención de copias de seguridad de los

mos en formato estándar, CADA, Ingreso de documentación justificativa,

<'?2';;'a-' - Pj4tamos de documentacion, Certificados a los ciudadanos, y otras bases de datose §estión.

Archivo General ha conseguido pasar de un funcionamiento manual a una situación

en la que buena parte del trabajo y de la información puede realizarse de forma

automatizada. Por ello el Archivo está hoy en condiciones de evolucionar hacia nuevos

desarrollos y alternativas que puedan ayudar en la mejora del trabajo y que además,

puedan abrir perspectivas para el futuro de la administración electrónica mediante un

sistema unificado de tratamiento archivístico, adaptado a las normas actuales de

descripción, especialmente ISAD(G) e ISAAR (CPF), que incluya no sólo los aspectos

de información sobre los documentos, sino los aspectos de gestión y ciclo de vida de

los mismos: ingresos, transferencias, selección y eliminación, descripción y

clasificación, servicio, consulta y préstamo, y que resuelva problemas como son la

obsolescencia de los equipos y sistemas, la facilidad de borrado, la problemática de la

encriptación o de la firma electrónica con el paso del tiempo, etc.

3del3

ll 1

í i

!,/m

filjfül%%L Ñ»V.«:17-'«T,Vó

»GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de juni0 de 2017

2 0BJETO DEL CONTRATO

Los trabajos objeto del contrato consisten en el la instalación y personalización del

módulo de Archivo sobre la versión de la herramienta AL-SIGM impiantada en el

Tribunal de Cuentas. Esta plataforma integra toda la documentación de un expediente,

a través de los tradicionales subsistemas de Registro, Gestión de Expedientes y

Archivo.

Para garantizar el ciclo completo de gestión de los expedientes administrativos, es

imprescindible la gestión documental de los mismos a lo largo de su tramitación, en su

fase de archivo y como documentación histórica en determinados supuestos.

Teniendo en cuenta el impacto que supondrá la inclusión en la plataforma de

tramitación de expedientes AL-SIGM de los casi dos millones de registros que

gestiona el Archivo General del Tribunal, se contempla una segunda fase del contrato

,,'GWº que tendrá como objetivo efectuar tareas de administración y ajuste del rendimientoC:'=,:%la vez en producción el Módulo de Archivo.

ª%i?-l

L, Á))nbos tipos de tareas (implantacion y personalizacion / a3uste del rendimiento yG%h? '5antenimiento) se realizarán en dos fases claramente diferenciadas:XX Fase l: Comprende el tiempo desde el inicio del proyecto hasta la puesta en

producción del Módulo de Archivo, incluyendo la migración completa de datos

al nuevo sistema. Se estima una duración de cuatro meses para esta fase.

* Fase Il: Tiene una duración de tres meses a partir de la finalización de la Fase

l y durante la misma el licitante mantendrá programadores expertos en el

Módulo de Archivo y el Módulo de Tramitación de AL-SIGM para abordar

tareas de mantenimiento y ajuste del rendimiento general de la Plataforma

durante un mínimo de 528 horas.

La empresa adjudicataria se comprometerá al cumplimiento de todas las condiciones

especificadas en el presente pliego, aun cuando no las haya señalado explícitamenteen su oferta.

4del3

r í l

i,í?

ÑXIWUN,'u. ñ»V. LlaW.'<rA%

lGERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

3 ENTORNO Y REQUISITOS TECNOI ÓGICOS

La plataforma de desarrollo estará basada en la plataforma de AL-SIGM implantada

Tribunal de Cuentas (TCu en adelante):

AL-SIGM 3.0.1

CentOS release 6.5 (Final)

PostgreSQL 8.4.20

Apache-tomcat-7.0. 16

Java version "1.6.0 45"

Git version 1.7.1

Apache Maven 2.2.1

Spring / Struts / Hibernate

IDE Eclipse versión Kepler o posterior

Gestor documental Invesicres

OpenOffice 3.3 como servidor de combinación y generación de documentos.

*

*

*

*

*

ªl adjudicatario será responsable de implantar un entorno alineado con el entorno dedesarrollo y ejecución de la plataforma AL SIGM anteriormente detallado. EI TCu se

ocupará de proporcionar las máquinas virtuales necesarias para el proyecto. No se

contempla el suministro de licencias de software ya que toda la plataforma de AL-

SIGM en el Tribunal funciona sobre productos de código libre.

3.1 Arquitectura

En caso de que la oferta incluya una propuesta de arquitectura distinta de la

implantada actualmente a fin de mejorar el rendimiento y/o la flexibilidad para

adaptarse a futuras ampliaciones de AL-SIGM (cantidad de trámites, usuarios o

documentos a gestionar), se deberá incluir, en su caso, el coste de los sistemas

operativos y gestores de base de datos como parte del precio final.

5del3

7?;

(l .,/-?

fi€lW('-.%Al. l)r. €Uk'.Nr.Vt

ll

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

EI TCu dispone de una infraestructura virtual basada en VMWare 5 para los entornos

de desarrollo, pruebas y producción, por lo que no se considerarán ofertas que

incluyan la adquisición de máquinas físicas

La arquitectura de la plataforma se basará en clientes ligeros para evitar tareas de

proceso pesadas en los ordenadores de sobremesa. El cliente debe ser un navegador

web y ser compatible con Explorer 11 y superiores y con las últimas versiones de

Chrome y Firefox.

3.2 Reutilización de código

El adjudicatario será el encargado de realizar las modificaciones necesarias en el

software AL SIGM de acuerdo a las políticas y metodologías que establece el

desarrollo del producto. Deberá primar la simplicidad y flexibilidad en el diseño. En

general cualquier servicio o módulo disponible que cumpla los requisitos será utilizado,

rimando la extensión del código y su contribución a la comunidad en lugar de la

alización de desarrollos a medida.

llDf: W >

tlls desarrollos que se entreguen deberán someterse a la aplicación de control de

'calidad del software SONAR desplegada en el Tribunal de Cuentas:

Calidad del sofbúíare

* En caso de un nuevo desarrollo, como sucederá con el servicio web del registro

electrónico, se exigirá a la aplicación un nivel de calificación global de B.

* En caso de tratarse de adaptaciones sobre un código ya desarrollado como son

las mejoras sobre el módulo de registro electrónico de SIGM v3.0.l , se exigirá

no empeorar la calificación de partida.

3.4 Rendimiento

Los tiempos de respuesta desde el punto de vista del usuario final deben ser inferiores

a un segundo en todas las operaciones individuales, quedando excluidas tareas

masivas como la generación de informes.

6del3

r

J?

TKDlUN.%L g»V.€:«,:k'-'«TA'G

á

l«

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

3.5 Escalabilidad

El adjudicatario deberá plantear escenarios de incremento de capacidad según los

parámetros más relevantes (número de usuarios concurrentes, número de

transacciones, volumen de datos: número de documentos, etc), de forma que sirva de

base para redimensionar la infraestructura en caso de incremento de dichos

parámetros.

3.6 Monitorización

Deberá formar parte de la implementación de la plataforma una consola de

monitorización a fin de detectar incidencias en el funcionamiento y alertar de las

mismas a los administradores por correo electrónico (se establecerán niveles de alerta

en función de la severidad).

Las incidencias a detectar serán tanto críticas (fallo en el servicio) como de

:'- .: degradacion del rendimiento (tiempos máx. min. y medio de respuesta) y se

.)ª'j,mplementaran mediante herramientas de fuentes abiertas. En caso de que la soluciónª º ' - i qropuesta requiera el uso de software comercial sin coste o mediante SQL Reports

Todos los parámetros de configuración de las aplicaciones y componentes, fuentes de

datos, propiedades de despliegue (dependientes del entorno), etc. serán externos al

código de la aplicación y deberán documentarse adecuadamente en un Manual de

Configuración del Sistema, indicando al menos para cada parámetro: localización,

procedimiento de modificación, posibles valores aceptados y comportamiento

esperado para cada uno de ellos.

Parametrización

Las propiedades de configuración podrán leerse de diferentes fuentes (ficheros,

BBDD, JNDI, URL, etc.)

3.8 Registro de sucesos (/ogs)

El sistema de registro será parametrizable en cuanto a formato del log, destino del log

(fichero, BD, syslog, otros), política de rotación, tamaño, archivado y severidad amostrar.

7del3

?l/

J?

lXl»U.%%l. I»»'. CVV-'«E.%'é

ll

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

Deberá incluir al menos la fecha, y hora del log, usuario, nivel de severidad y mensaje.

Se protegerán los registros de actividad conservando datos de quienes acceden a qué,

la fecha y hora, y si el acceso fue exitoso o no, en el caso de acceso autorizado se

guardará información que permita identificar el registro accedido. Los registros de

actividad no podrán ser modificados ni eliminados por personal no autorizado,

determinándose el periodo de retención de los mismos de al menos dos años.

El acceso estará limitado por horario, fechas y lugar desde donde se accede. El

número de intentos permitidos será limitado, bloqueando la oportunidad de acceso una

vez efectuados un cierto ríúmero de fallos consecutivos. El sistema informará al

usuario de sus obligaciones inmediatamente después de obtener el acceso y del

último acceso efectuado con su identidad. Se prevendrán ataques que puedan revelar

información del sistema dando la mínima imprescindible (los diálogos de acceso

proporcionarán solamente la información indispensable). Se registrarán los accesos

4==,con éxito, y los fallidos.

mostraran contraseñas sin cifrar. Permitirá identificar las transacciones que

?? aliza el usuario a través de todos los componentes e interfaces para identificar*1

'ácilmente el componente que detecta y/o genera el fallo.

Se utilizará para un framework reconocido de logs y trazas para implementar esta

funcionalidad. En caso de proponer una implementación propietaria, el TCu se reserva

el derecho de rechazarla, en cuyo caso el adjudicatario estará obligado a proponer y

utilizar un framework reconocido.

Se registrarán en el log de las aplicaciones y/o sistemas el arranque y parada de las

mismas indicando claramente si el arranque y/o parada ha ocurrido satisfactoriamente

o no. Toda excepción capturada se escribirá en el log de la aplicación.

3.9 Gestión de errores

Se realizará una gestión de errores adecuada, minimizando la cantidad de información

que se proporciona al usuario. La gestión de errores debe aplicarse tanto en los

accesos a contenidos estáticos como dinámicos, tras la ejecución de código.

8del3

(?

J-?

'f»lla(IN.ll. I»F. CIT-Y T-Vé

? li

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

El procedimiento desarrollado dispondrá de un catálogo de errores que indique para

cada código de error las causas del mismo y las posibles soluciones. El catálogo

contendrá, además del código de error, la información de despliegue del sistema, por

ejemplo en caso de no poder conectar con un determinado servicio, el mensaje de

error contendrá las propiedades de despliegue del mismo (servidor, puerto, etc).

No debe existir ningún tipo de información confidencial en los datos proporcionados al

usuario, tal como campos ocultos en documentos HTML o claves de la aplicación, en

los documentos enviados a los clientes Web. Si en algún caso es necesario enviar

algún campo sensible hacia el cliente Web, este campo debería estar cifrado, expirar

tras cierto tiempo y no ser reutilizable.

3.10 Entornos

Se contemplan tres entornos: desarrollo, preproducción y producción, completamente

independientes. El adjudicatario deberá diseñar, documentar e implantar los

}l(f*aí Í

iº ' , procedimientos para desplegar un entorno a partir de otro Dichos procedimientos

?" cn?úljl

&

1 a,l'

ilAI?"

*

n automatizados.

'%. DESARROLLO DE LOS TRABAJOS

El adjudicatario deberá realizar el trabajo de forma presencial en la sede del TCu, sita

en la calle Ortega y Gasset nº 100, en colaboración con los programadores de AL-

SIGM de la Subdirección TIC a fin de asegurar la transferencia del conocimiento.

El horario laboral para el desarrollo del proyecto se ajustará al del Tribunal: de 8:00 a

15:30, salvo los martes que se extiende hasta las 18:30.

El adjudicatario deberá aportar los ordenadores y licencias de soffware necesarios

para el trabajo de su personal. Estos ordenadores se conectarán a la red del Tribunal,

cumpliendo con las políticas de seguridad correspondientes para el acceso seguro a

los servidores corporativos. Debido a la confidencialidad de la información no se

podrán hacer copias a equipos distintos de los que autorice el TCu de las bases de

datos, de los documentos ni del código fuente de las aplicaciones.

9del3

r Í »GERENCIA

lJ?

ÑWUI(!N,ILur.(JF.'í,tV

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

5 DESCRIPCIÓN FUNCIONAL DEL SISTEMA

El adjudicatario debe Ilevar a cabo las fases de diseño, desarrollo, pruebas,

documentación, puesta en producción y soporte post-implantación del sistema dearchivo.

El alcance de los trabajos a realizar es el siguiente:

1 ) Implantación del Módulo de Archivo de AL-SIGM en el Tribunal de Cuentas.

Este módulo permitirá la gestión de los expedientes tramitados desde AL-SIGM (en

formato electrónico y/o en papel) y el resto de los expedientes en papel o

procedentes de otras plataformas. En esta fase, el módulo permitirá la grabación

de las Unidades Documentales que figuran en el depósito físico, así como las que

sean transferidas en papel.

j - --.','IjLa implantacion incluira la puesta en marcha del sistema de descripcionArchivística y su consulta y del resto de funcionalidades del Módulo de Archivo de

AL-SIGM 3.0. 1 , tales como la gestión de transferencias, préstamos y consultas.

Como resultado, quedará implantado en los diferentes depósitos del Archivo

General del TCu (Ortega y Gasset, Padre Damián, y Centro de Almacenamiento de

Documentación Administrativa en las Rozas) y en las unidades del TCu querealizan transferencias de documentos al Archivo.

2) Precarga de los Cuadros de Clasificación y migración de todas las bases dedatos del Archivo actual del Tribunal al nuevo módulo de Archivo de la

plataforma AL-SIGM.

La información descriptiva a migrar procede de once bases de datos

correspondientes a distintas funciones del TCu y estará compuesta por

aproximadamente 1 .600.000 unidades documentales.

lOdel3

r

rl !J?

lXlal!%lÁ. Dr. «:kªr.NT.('é

l«

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

Este trabajo se realizará a cuenta y riesgo del adjudicatario, no considerándose

ofertas que limiten el alcance o duración del mismo y deberá incluir los siguientes

aspectos:

* Depuración de los datos en origen: integridad referencial, duplicados,

completitud, normalización y cualquier otro aspecto requerido para la

inclusión en las bases de datos de AL-SIGM.

@ Verificación del almacenamiento, referenciación y descripción de los

documentos digitales en su almacenamiento actual y en el nuevo, teniendo

en cuenta que, previsiblemente, se trasladen desde sistemas Windows asistemas CentOS.

* Verificación y transformación, en su caso, de los formatos digitales a

formatos estándar para su archivado.

Planificación y ejecución de la migración de datos y ficheros mediante fases

para facilitar el control de calidad por el personal de la Subdirección de

Archivo General del Tribunal.

*

?.(5,í7,'e' -aa» ,? A';v ? >a: [-Í?7s t.ri-?"ítaHÍ*

T' I

<,3) Mantenimiento y ajuste del rendimiento de la plataforma AL-SIGM posterior a

la puesta en producción de las nuevas funcionalidades.

Planificación de pruebas de calidad para garantizar el éxito de la migración

y pruebas de rendimiento para comprobar que la experiencia de usuario essatisfactoria.

*

Esta tarea comprende los cambios en la arquitectura de la plataforma para mejorar

Ios tiempos de respuesta y escalabilidad. Estas tareas incluyen los diversos tipos

de mantenimiento requeridos en cualquiera de los módulos de la plataforma en su

conjunto para asegurar un correcto funcionamiento integrado:

a. Mantenimiento correctivo: agrupa las acciones a realizar en el software

(programas, base de datos, documentación, etc.) ante un funcionamiento

incorrecto, deficiente o incompleto, sin modificación de funcionalidad y otras

acciones que no son fácilmente predecibles y que requieren rapidez en la

lldel3

r i »GERENCIA

)l

?

WWlm(IN.%l. I)1. CUV-'«TAí'é

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

ejecución (inmediatez, lo que dificulta su planificación) o presentan corto

alcance (esfuerzo máximo de 2 jornadas).

b. Mantenimiento adaptativo: actividades motivadas por el cambio del

entorno técnico y/o funcional en el que el sistema software debe operar.

c. Mantenimiento perfectivo: cualquier inserción, eliminación, modificación,

extensión y/o mejora realizadas sobre un sistema después de su entrega,

para mejorar su funcionamiento y/o sostenimiento.

d. Mantenimiento preventivo: actividades realizadas con el propósito de

prevenir problemas latentes antes de que éstos ocurran y me3orar la calidad

del software mantenido, sin modificación de funcionalidad.

El adjudicatario deberá asumir la prestación de los servicios adicionales precisos para

hacer posible el pleno uso de las utilidades y aplicaciones de la plataforma y para la

,extensión, ampliación y mejora que se realice sobre la misma para satisfacer las

i%(,,esidades evolutivas del órgano contratante(/»7S %?'D ?'s -al

é flÑ-'f4jt"'' Wr';í}4[I -ª?iúú ?.ºri r-rr%134jj'V, - FASE DE PRI IrBAr EIMPLANTACIÓN

Una vez que el adjudicatario considere concluido, total o parcialmente, el desarrollo, la

aplicación resultante se instalará en el entorno de pre-producción para realizar las

pruebas unitarias, de integración, funcionales y de rendimiento para comprobar que los

tiempos de respuesta en condiciones de uso normales no penalizan la experiencia de

usuario.

También se realizará un test de estrés para conocer hasta qué punto es escalable la

solución frente a picos de demanda interna o externa. Los medios necesarios para

realizar estas pruebas serán por cuenta del adjudicatario.

Salvo que resulte técnicamente imposible por las características de la prueba, éstas se

automatizarán siempre mediante la herramienta de integración continua del proyecto u

otra especializada (p. ej. JMeter) que deberá quedar al final del proyecto a disposición

12del3

?k l,/?

TXlaL'-.%lL IJr. CíªW.Nl.Né

i»

GERENCIA

SUBDIRECCIÓN DE TECNOLOGÍAS DE LAINFORMACIÓN Y LAS COMUNICACIONES

19 de junio de 2017

del Tribunal, sin coste añadido, con las configuraciones necesarias para repetir las

pruebas siempre que se considere oportuno.

Sólo cuando el Tribunal considere que las pruebas han sido realizadas a su plena

satisfacción, se iniciará la fase de implantación de la aplicación.

7 FORMACIÓN

Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete

a facilitar la información y documentación que el Tribunal considere necesaria para

disponer de un pleno conocimiento del desarrollo de los trabajos, así como de los

eventuales problemas que puedan plantearse y de las tecnologías, métodos y

herramientas utilizados para resolverlos.

Durante la fase de pruebas el adjudicatario impartirá formación a los empleados del

Tribunal para el uso del nuevo sistema de tramitación, considerándose necesario 8

horas de formación en dos sesiones de cuatro horas.

DILIGENCIA para hacer constar que este Pliegode Prescripciones Técnicas ha sido aprobado confecha de hoy por el Presidente del Tribunal deCuentas.

,.,, Madrid, 19 de junio de 2017

El Asesor Jurídico,

'Il?

'?:r?"' ?Fdo.: José Luis Lorenz Falomir

13del3