Embed Size (px)
Citation preview
r Í l
l,)?
l»llll€!S.%l. €h»:«:€!W-'IA:í
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUNICACIONES
0 de iulio de 2C)17
PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA
CONTRATACIÓN DEL DESARROLLO DEL NUEVO REGISTRO
PRESENCIAL Y ELECTRÓNICO DEL TRIBUNAL DE CUENTAS
lde20
r,l
j?
TWlWllNAl. I»»'. Ckl-Nr.Vé
»GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUNICAC?ONES
10 de iulio de 20 17
1 ANTECEDENTES 4
1.1 SlTUAClóN ACTUAL DEL REGISTRO PRESENCIAL 4
1.2 SITUAClóN ACTUAL DEL REGISTRO TELEMÁTICO 5
1.3 0TROS REGISTROS INTERNOS 6
2 0BJETO DEL CONTRATO 7
3 ENTORNOYREQUISITOSTECNOLÓGICOS 8
3.1 Ríurii?izxcióx DE CóDlG0 9
3.2 CALIDADDELSOFTWARE 9
3.3 VERSIONES DE PRODUCTOS DE TERCEROS. 9
3.4 D?SPONIB?L?DADDELS?STEMA. 9
3.5 ESCALAB?LIDAD 10
3.6 MONITOR?ZACIÓN 10
3.7 PARAMETRIZAC?ÓN 10
3.8 REGISTRO DE SUCESOS (to«:;s} 10
3.9 GESTlóN DE ERRORES 11
3.10 ENTORNOS 12
4 DESARROLLO DE 105 TRABAjOS 12
f?'ó,{,íM'í
,,=,{: ?:7 ffl'.'0'k':'4 DESCRIPCION FUNCIONAL DEL SISTEMA
.1 MARCO NORMATIVO
.4 Dosicxuvípiocióxübíosúpux'n:socsccisrso
2 DISPONIBILIDAD Y RESTAURACIÓN DEL SISTEMA
3 lNTEGRACIóNCONELDIRECTORIOCOMúNDEUNIDADESORGANICASYOFIClNAS
13
13
13
13
14
5.5 INTERFAZ DE usuúí<io (GUI) 14
5.6 DlGITALlZAClóN DE DOCUMENTOS 15
5.7 IMPRESORA DE ETIQUETAS 16
5.8 DlSTRlBUClóN DE úpcmrís ENTRE DEPARTAMENTOS 16
5.9 ALMACENAMIENTO DE LA DOCUMENTAClóN 16
5.10 Usuúsios 16
5.11 CORRECClóN DE ERRORES MATERIALES DE usuqsio 17
5.12 MEJORASALRELACIONARREGISTROS. 17
5.13 BúSQUEDAS E INFORMES 17
5.14 FIRMA ELECTRóNICA 17
2 de 20
l
!,l?
1XÍ?IN-IÑ. Ñ»k'.€l1.'«r-%'é
r »GERENCIA
SUBDIRECC?ÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUNICACIONES
O de iulio de 2017
5.15 Tí:túrúMlENTO MASIVO 18
5.16 ANALISIS DE RENDIMIENTO 18
5.17 S?NGLESIGNONYD?RECTORIOLDAP 18
5.18 MIGRACIÓN DE DATOS 18
5.19 REQUIS?TOS FUNCIONALES ESPECíFICOS DEL REGISTRO ELECTRóNIC0 19
5,20 INTERCONEXlóN CON SIR 19
6 FASE DE PRUEBAS EIMPLANTACIÓN íg
l'A('!!)
3 de 20
l
J?
íWl?ª..V.ll. I»l:L1ªt?r(t'é
r »GERENCIA
SUBDIRECC?ÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUNICACIONES
O de iulio de 20i7
1 ANTECEDENTES
EI Registro General del Tribunal de Cuentas constituye el punto único de entrada y
salida de solicitudes, escritos o comunicaciones relativos a los procedimientos y
asuntos que sean competencia del Tribunal. El diseño informático del Registro General
consta de dos módulos independientes basado en el software comercial EMBLA: una
para la gestión del registro presencial y otra para la gestión del registro electrónico.
A pesar de tratarse de dos módulos diferenciados, el registro presencial o físico y el
electrónico forman un libro único en el que se registran, de forma secuencial y
' .- tanlgl4n soporte papel, como electroníco--í- 'l,4.;.úB4.
41',: ?.iít?.l?=.l h
s!fü*«
gk? 4Óí»are en el que se basa el Registro General, implantado hace más de una
'écada, adolece actualmente de problemas de escalado y mantenibilidad y presenta
incompatibilidades con el sistema de tramitación electrónica del Tribunal y con los
equipos multifunción para digitalización de documentos. Por estos motivos, la
Comisión de Estrategia TIC ha decidido su sustitución por el módulo de Registro que
forma parte de la Plataforma Integral de Gestión Electrónica AL SIGM del Tribunal.
1.1 Situaciónactualdelregistropresencial
El registro presencial dispone de dos oficinas activas de registro (Ortega y Gasset y
Padre Damián). En cada una de ellas, el interesado presenta la documentación
pertinente para el inicio de un procedimiento. El funcionario sella esta documentación,
haciendo los cotejos oportunos y graba en la aplicación de registro presencial los4 de 20
l
j?
fi'll»ll.N.ll. I»: C€1.NT.%5
«GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUNICACIONES
O de iulio de 20Í7
datos del registro. Al finalizar el registro, la aplicación imprime una etiqueta
autoadhesiva con la fecha y hora del apunte, así como la identificación del registro que
ha generado la aplicación:
Número de registro secuencial en el libro único
Número de registro secuencial de la oficina
En la actualidad no se digitaliza la documentación que se recibe en papel, procediendo
a la distribución física de la misma al Departamento o Unidad destinataria.
El número de usuarios de las oficinas de registro presencial es de cinco, actuando con
?Ü' d'ñ'd.iA(intos roles en función de su tarea (operador y administrador).'D .,-az -a';ry '«$Q@->lí=?.
t» .y'xv=Aí==m*ss* ?..7d%'i-'j'íA íA'Q) '!" 4fectos de estimar el volumen de trabajo, en 2016 se han producido 16.000
tradas presenciales, equivalentes a unos 480.000 folios, y 39.975 entradas
telemáticas.
1.2 Situaciónactualdelregistrotelemático
El servicio de registro telemático es un servicio web alojado en un servidor con acceso
a la red SARA, que recibe como entrada una petición xml con los datos de la solicitud,
Ios datos de los anexos y la firma de la petición.
Una vez recibida la petición, el registro telemático valida el certificado que la
acompaña Ilamando al servicio web ValidarCertificado que, a su vez, conecta con
@Firma.
5 de 20
r Í
L/?
lXfü(IS,Il. fü; €:k:k.'«Tk%
«GERENCIA
SUBD?RECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUNICAC?ONES
O de iulio de 2C)17
Si la validación del certificado es correcta, entonces se realiza el apunte en el libro del
registro general y se devuelve una respuesta que contiene un documento en formato
xsig.
A este servicio web de servicio electrónico acceden las distintas aplicaciones que
necesitan realizar apuntes de registro:
* Aplicación tramitador de formularios
* Rendición de cuentas de entidades locales
Remisión de información de la IGAE
., ' . %, * Remisión de información de la Seguridad Social
Remisión telemática de contratos
Remisión de la contabilidad de Partidos Políticos
* Otras a desarrollar en 2018 y siguientes.
Dado el número de aplicaciones implicadas en el cambio del registro telemático, la
sustitución que se desarrolle mediante el módulo de AL-SIGM debe ser transparente
para dichas aplicaciones, de forma que baste con modificar su configuración para que
apunten a la dirección del nuevo servicio web de registro que se implante como
resultado de este proyecto.
1.3 0tros registros internos
Por otro lado, casi todos los Departamentos y Unidades del Tribunal de Cuentas
disponen de Registros internos donde se toma nota de entrada y salida de
6 de 20
l
!,l-?
IXIWlÍ.%%l. )»; €:k:W.'«TA:é
lGERENCIA
SUBD?RECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUN?CACIONES
O de iulio de 2Cll7
documentación. Muchos de estos documentos son los mismos que ya efectuaron su
entrada por el registro presencial.
Estos registros se gestionan manualmente, mediante desarrollos en Access o
mediante aplicaciones comerciales como Knosys, sin que se haya estandarizado el
formato ni la nomenclatura de la signatura registral. Forma parte de este proyecto la
integración de estos registros internos como oficinas de registro que forman parte de
un registro único centralizado del Tribunal.
número de usuarios de estas aplicaciones es de aproximadamente unos sesenta.,,?El ni
i ',* '!F'h' BJETO DEL CONTRATO'm(
Jí
' trabajos objeto del contrato consisten en el apoyo durante cuatro meses aldesarrollo del nuevo registro presencial y electrónico del Tribunal de Cuentas, basados
en el módulo de registro de la herramienta AL-SIGM v3.0.l., ya desplegada en el
Tribunal de Cuentas.
En el caso del registro electrónico, se respetará el interfaz WDSL que actualmente
ofrece el servicio web de registro telemático para las aplicaciones que realizan apuntes
de registro, de forma que resulte transparente la sustitución del módulo de registro
telemático.
7 de 20
l
)]
?
WWI!Ilj;'Lll. u»: €'CW.'gTA%
r »GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUN?CACIONES
O de iulio de 2017
3 ENTORNO Y REQUISITOS TECNOLÓGICOS
El entorno de desarrollo y ejecución estará basado en la plataforma de AL-SIGM
implantada Tribunal de Cuentas (TCu en adelante):
* CentOS release 6.5 (Final)
* PostgreSQL 8.4.20
Apache-Tomcat 7.0. 16
* Java 1.6.0 45
* Gitl.7.l
* Apache Maven 2.2.1
* AL-SIGM 3.0.1
Spring / Struts / Hibernate4S;?,% 'IDE Eclipse versión Kepler o posterior
Íg.f- . * Gestor documental Invesicres
'- - ? 1'* OpenOffice33comoservidordecombinacionygeneraciondedocumentos-k
entorno de ejecución del servicio web de registro telemático tiene los siguientes
componentes:
* Windows 2012 R2
* apache-tomcat-7.0. 16
* Versión de java 1 .6
* BBDD Oracle
El adjudicatario será responsable de implantar un entorno alineado con el entorno de
desarrollo y ejecución de la plataforma AL SIGM anteriormente detallado. EI TCu se
ocupará de proporcionar las máquinas necesarias para el proyecto. No se contemplael suministro de licencias de software ya que toda la plataforma de AL-SIGM en el
Tribunal funciona sobre productos de código libre.
8 de 20
rl
«
L/?
WWjBllNAl. uK«:kl'.'«TA:ü
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMÁCIÓN Y LASCOMUNICAC?ONES
O de iulio de 2m 7
3.1 Reutilización de código
El adjudicatario será el encargado de realizar las modificaciones necesarias en elsoftware 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, primando la extensión del código y su contribución a la comunidad en lugarde la realización de desarrollos a medida.
3.2 Calidad del software
Los desarrollos que se entreguen deberán someterse a la aplicación de control de
calidad del software SONAR desplegada en el Tribunal de Cuentas:
*
?<.1,é?' L,(»ªy-=r,'!,!'!.?7 cn** í4ñé-l'h
u?'a'!k%
En caso de un nuevo desarrollo, como sucederá con el servicio web del registro
electrónico, la aplicación debe conseguir 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, no sedeberá empeorar la calificación de partida.
Versiones de productos de terceros
Se deberán revisar las versiones de librerías y productos de terceros que utilice el
módulo de registro presencial y telemático de SIGM, actualizando las versiones a la
más alta posible con el objetivo de facilitar el mantenimiento y la seguridad del
sistema. Se prestará especial atención a las versiones de java, servidor de
aplicaciones y servidor de base de datos.
3.4 Disponibilidad del sistema
El registro debe proporcionar un servicio 24x7x365, por lo que se debe diseñar un
sistema que evite pérdidas de servicio ante incidencias o trabajos de mantenimiento.
Los fallos de los componentes deben ser transparentes, evitando la pérdida de lasesión de usuario.
9 de 20
í 'l l
Ll?
lXlfül.%%l. b{. «:€lXr.u
GERENCIA
SUBDIRECC?ÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUN?CACIONES
O de iulio de 2C)l
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
Se planteará 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
degradación del rendimiento (tiempos máx. min. y medio de respuesta) y semediante herramientas de fuentes abiertas sin coste o mediante SQL
g'.$,2!
, fuentes dey-.-.-7S.atos, 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.
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.
l0de20
r
Um
lXlmt!SAl.l)»:Cl:».Ví.%:é
l«
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUN?CACIONES
lO de iulio 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é,
Ia 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 nú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
,proporcionaran solamente la informacion indispensable) Se registraran los accesos' - bcqn éxito, y los fallidos.
No: se mostraran contraseñas sin cifrar Permitira identificar las transacciones que" ? ª , r%füiza el usuario a través de todos los componentes e interíaces para identificar
fÁ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.
llde20
77,
?l
??
ÑXlal'-N.%l. Ñ»:{'Il-'fiS!é
l»
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUNICACIONES
O de iulio de 20í7
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
para desplegar un entorno a partir de otro. Dichos procedimientos,ª procedimientos
, , ? fürán automatizados.
ºÁ DESARROLLO DE LOS TRABAJOS
El adjudicatario deberá realizar el trabajo íntegramente de forma presencial en la sededel TCu, en colaboración con los programadores de 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 software necesariospara el trabajo de su personal. Previa autorización, estos ordenadores se conectarán ala 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.
12de20
02: eP € l
:u9!sez!len)üe ep SOiOiueS SOI ep u9!üez!!}n el uí7íqaíel
yyspuaydu.ioü anb ouis 'oiío):»sii(1 1a ua sopeuaüeu.i1e seuiüilo A seh;lez;ueñro s;»pep;í.írise1 ap so6ipgü so1 ap e6»es eun íezileu ap pepi1iqisod e1 e ípíe)íuíí1 as ou ugiüai6aí4uíe1 'seuiüil? K seüiuy6í? sapepiu(1 ap ui,uio3 oiíolüsyi(1 1a uoü asyey6a)uí í,íaqs(1
seui:»il@ A seüiuy6a@ sapepiu4 ap unu»o) oiao)üaai@ ?a uo:» uoiüea6e)u1 (ªg
ªpepiyn6as ap
seido:» se1 ap opailiü ap soaisiueüsu,i uoü ie)uoü ouioü Bse usuoduioü e? anb so)uaí.ua1a
so1 sopo) íinpui eíaqap u«,i:»eüi1de e? ap sopiug)uoü so1 ap pepíyn6as ap eído:» el
ªslo4sy:leü ap OSE!O ua o4si6ía2¿ ap uoíüeüí1de e1 ap uopaínelsaí
1, (dmpeq) pepiin6ss sp eidoü sp o)uaiu4paüoyd un asieqo>d A asííuílsp í,.íaqa(1
'SeOiuC%)}
SeuO!Oue/IJelu! O SE'pueplOul 'Se4SE'Sep ep OSeO ue Opi/UeS le Jeueluefü aqa(l 'lX
opiuas un opuai:»sylo 'oue 1e seip gg6 so1 s1qiuodsip relsa ap eí.1 o4s;6u ap oíüíuañ B .. -
eu»e)sis Hap u«;»i:»eyííe)saa A pepH1iqiuodsi@ í':'?'Zª9
os;1«:lri,3rolsaBppos;p3»ri(ou»uu;e»qHaprqnpoaíp(ap'q50zl0>l,a) *':,.?..?.SE")ilql,Id Seu0peJ:ISluiLup0
se1 í»p unaio3 ohileí)siuiuipy o:luaiuíipa:aoí,,1 1ap 'aiqn)üo ap 5 ap 'g50zl66 Aal*
(0(0zly o)aíüa(1 1eaH) pepi1iqaiadoia)u1 sp leuoiüeH euuanbs3*
(010zl6 olarsa(3 1ea2,1) pepiyn6sB ap 1euoíüeH eí.uanbsl*
:ueueuus se11a ap snb seüiuüí2) seuiyou K soluaiuiipsüoyd
iSeAel sa)uain6is se1 ua opeüipui o1 ii1duínü eíaqsp o4si6aH 1sp oluaii.ueuopurí4 B
0/ki)EfüJOu 0)JBJ la9
'uq;seriuHluos e solssndxa so1
uqyss o)unjuoü ns ua o4s;6u ap eaia)sis 1a ?ii1duunü sqap anb ss1e>aua6 so)ísínbay so1
VW31SIS 13CI ?VNOI:)Nnj N«;»lüdl8üS3Cl 9
Z íoZ ap ÓÍínrH4-ó t
S3NOl)V:)INnWO:)
SV1 Á N(;)I)VWaOjNI V13Cl SV!0010N:)Il 3G N0m?alClgnS
Vl)N3a30
&l'JH41:)%nli'NílllDll
?
í"
»lj
rl
»
L/-?
TRl»(tN,%j. Dr. «1!F.'€T.%'é
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMuNICACIONES
O de julio de 201
Servicios de consumo y provisión de información
Servicios de gestión de usuarios
Servicios de gestión de alertas.
Sin perjuicio de lo indicado en el requisito anterior, deben migrarse y conservarse los
códigos y los organismos existentes en la estructura organizativa actual.
*
*
5.4 Doble numeración de los apuntes de registro
Todo asiento de registro tendrá una numeración secuencial por libro y una numeración
secuencial por oficina. Este requisito es especialmente importante, pues en la
actualidad el sello del registro se genera con las dos numeraciones y los usuarios de
registro están habituados a utilizar ambas numeraciones y son igualmente válidas.
?b5 Interfaz de usuario (GUI)
????) Sé', mejorará el interfaz de usuario (GUI) del SIGM, modernizando su aspecto eª inc1uyendo combos dinamicos segun escribe el usuario y funcion de autoguardado de
. ... - ' :1qg formularios.
La aplicación debe funcionar correctamente con las últimas versiones de los
principales navegadores (Explorer, Chrome y Firefox), sin necesidad de activar la vista
de compatibilidad.
Debe eliminarse completamente de la aplicación cualquier dependencia con applets de
Java y/o complementos ActiveX ya que está previsto que dejen de funcionar en los
navegadores web. De forma no exhaustiva, deberán eliminarse los applets de subida
de documentos a servidor, escaneado, generación del sello en la impresora de
etiquetas y firma de documentos.
La interfaz de usuario debe ser configurable para mostrar y ocultar botones en función
del usuario y los roles que tenga asignados.
Se aplicarán mecanismos de filtrado de la entrada del usuario que permitan mitigar
ataques como XSS, inyección SQL, desplazamiento por directorios, referencias
14 de 20
rl
»
l,/?
«WlW€RLu.I»KC€ªV.'fiXk
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUNICAC?ONES
10 de iulio de 2C)í7
directas a ficheros, ejecución de comandos del sistema operativo o HTTP Response
Splitting.
5.6 Digitalización de documentos
El adjudicatario deberá implementar los interfaces necesarios para la incorporación de
documentos en papel mediante la integración con procesos de digitalización que
incluyan reconocimiento óptico de caracteres para la indexación y búsqueda de texto,
a ser posible mediante la utilización de software de fuentes abiertas.
El sistema de digitalización debe integrarse con los dispositivos Kyocera 30lOi de
escaneado y copia del TCu para ofrecer a los usuarios una experiencia de uso rápidae intuitiva.
Son de obligado cumplimiento las Normas Técnicas de Interoperabilidad' relativas al?." . " 'documento electrónico publicadas por el Ministerio de Hacienda y Función Pública, así
como sus guias de aplicaciones asociadas y, de manera especial, las siguientes
Norma Técnica de Interoperabilidad de Digitalización de Documentos.
Norma Técnica de Interoperabilidad de Procedimientos de copiado auténtico yconversión entre documentos electrónicos.
En caso de que la solución propuesta requiera el uso de software comercial, será
responsabilidad del adjudicatario asumir los gastos de adquisición y mantenimientodurante un año.
1
http://administracionelectronica.gob.es/pae Home/pae Estrategias/pae Interoperabilidad Inicio/pae Normas tecnicas de interoperabilidad.html
15de20
rl
»
!,J?
lWIW(I.N,Il. N'.CUr-'«YS%
GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMACIÓN Y LASCOMUN?CACIONES
O de iulio de 2C)17
5.7 Impresora de eUquetas
La aplicación de registro debe integrase perfectamente con la impresora de etiquetasmarca C?TIZEN modelo CLP-621 . La impresión debe realizarse de acuerdo al formato
actual de impresión de las etiquetas que emplea el TCu.
5.8 Distribución de apuntes entre departamentos
La distribución de apuntes de Registro entre distintos Departamentos y Unidades del
TCu debe dejar constancia del momento en que se efectuó mediante la generación de
un apunte de salida en la oficina del departamento origen y un apunte de entrada en la
oficina del departamento destino. Los apuntes estarán relacionados entre sí, serán
consultables por los Departamentos interesados y estarán identificados por sus
números de registro (secuencial por libro y secuencial por oficina) pertinentes.
%iempre que la operativa de tramitación lo permita, se evitará la duplicación de
documentos, manteniendo enlaces a una copia maestra en caso de que deban formar
parte de múltiples expedientes y/o vistas de los mismos.
Se deberá proveer un sistema automático que ante llenado de los volúmenes del
repositorio documental avise al administrador mediante correo electrónico de tal hecho
y, si es posible, cree de forma automática un nuevo volumen.
5.10 Usuarios
La aplicación debe ser configurable para definir distintos roles de usuario, en principiorol de grabador y administrador. Así mismo, si se considera oportuno, se podráconfigurar para cada usuario solo acceda a los asientos de su unidad.
Se deberán emplear mecanismos de gestión de sesiones empleando identificadoresde sesión no predecibles (es decir, suficientemente aleatorios), de suficiente longitud
1F3í de 20
l
1,1?
WKlalUN.ll. ñN:€%l.'«r.%*
r »GERENCIA
SUBDIRECCIÓN DE TECNOLOGÍAS DELA INFORMAC?ÓN Y LASCOMUNICAC?ONES
O de iulio de 2m 7
para que no puedan ser adivinados mediante técnicas de fuerza bruta, y que
caduquen tras cierto tiempo.
5.11 Corrección de errores materiales de usuario
El módulo de registro actual de SIGM no permite la corrección de errores materiales
producidos durante la grabación de los documentos y apuntes de Registro. La solución
a desarrollar debe permitir estas acciones siempre que las realice un perfil especial de
superadministrador y que deje constancia de la operación efectuada mediante un
registro de auditoría detallado e inalterable.
5.12 Mejoras al relacionar registros
La aplicación SIGM permite relacionar apuntes registrales ípero con un límite de cinco
registros; esta limitación deberá eliminarse o ampliarse a una cifra mayor.
,=#'»=-.Al, relacionar apuntes registrales es necesario que se permita buscar registros por un
j7'5' ,-ª =» te:Qto concordante en el campo asunto en lugar de hacerlo únicamente por el número1- á» registro.
-" ? ' ,.5gs resultados de las búsquedas deben aparecer ordenados por fechas y por libros
para facilitar el seguimiento de los documentos entre Unidades y Departamentos.
5.13 Búsquedas e informes
El sistema facilitará la búsqueda de apunte en función de diversos campos; se
permitirán consultas simples y avanzadas y se dispondrá de informes y listados
parametrizables filtrados por origen, destino, fechas, relaciones diarias, etc.
5.14 Firma Electrónica
La aplicación incluirá la funcionalidad de firma electrónica y portafirmas mediante
certificados aceptados por el servicio @Firma.
17 de 20
rl
l
J?
WWla(INILI)»:CtíF.VY,(%
GERENCIA
SUBD?RECCIÓN DE TECNOLOGíAS DELA INFORMACIÓN Y LASCOMUN?CACIONES
O de iulio de 20í7
Los servicios de firma se deberán realizar en cliente, con jdks actuales, y debiendo
estar operativa, al menos, en versiones actuales de los navegadores Explorer y en
Chrome.
5.15 Tratamiento Masivo
Se deberá permitir generar apuntes de registro masivos de forma rápida y sencilla
para el usuario.
Un ejemplo de apuntes de registros masivos lo constituye una notificación para todos
los ayuntamientos y entidades locales que son alrededor de catorce mil. El sistema
deberá ser capaz de generar automáticamente todos los apuntes de Registro y sus
respectivas etiquetas.
5.16 Análisis de rendimiento
'S,e generarán informes analíticos de los procesos con los top-N expedientes más,é'===:[i9yl -:?, ri' usados los que tengan mas instancias, mayor duracion, mayor tíempo de uso real
del tiempo de ejecución), distribución de ejecución en tareas: % respecto a
s de ejecución, cuellos de botella y todos aquellos que se identifiquen en el
5.17 Single Sign On y Directorio LDAP
La aplicación de Registro se integrará con el Directorio Activo del TCu para la
identificación de usuarios mediante Single Sign On y la definición de grupos yusuarios.
En caso de que la herramienta necesite replicar grupos y usuarios de Directorio Activo
para su gestión interna, será responsabilidad del adjudicatario programar tareas desincronización automáticas.
5.18 Migracióndedatos
El adjudicatario deberá realizar la migración de los apuntes de registro anteriores a la
entrada en funcionamiento de la nueva aplicación de registro. EI TCu proporcionará la
18de20
r
U?
íXlal.'-N.%l. »V.C€IXY.(é
ll
GERENCIA
SUBDIRECCIÓN DE TECNOLOGíAS DELA INFORMAC?ÓN Y LASCOMUNICACIONES
. . .....00?qeju,lio,de20%7
equivalencia entre los campos de base datos de la aplicación actual EMBLA y los del
módulo de Registro de SIGM a fin de facilitar esta tarea en lo posible.
5.19 Requisitos funcionales específicos del registro electrónico
Como ya se ha indicado, será necesario realizar el desarrollo de un componente para
Ia interconexión de las aplicaciones que realizan apuntes de registro electrónico con el
servicio web del registro electrónico de SIGM, respetando el interfaz existente en la
actualidad a fin de evitar modificaciones en las aplicaciones. El desarrollo de este
componente debe:
a. Admitir solicitudes firmadas electrónicamente y validar los certificados en@Firma.
b. Garantizar la transaccionalidad de las operaciones.
c. Cumplir el nivel de servicio de operaciones por segundo que se establezca,mediante las pertinentes pruebas de rendimiento.
aa 1; r,' %???í?;"%A
{t(7,%}-X
s'.Sl'..4
' ? ' Lo? documentos incorporados a la aplicacion de registro telematico en la version 3 0 1'? ?- ? . ,d'e,','SIGM son almacenados dentro de la base de datos; tal como se ha mencionado
X?.. ?..Án:eriormente, se deberá modificar este comportamiento para que sean almacenados
':zí',?,,,,???,,;ejen repositorio documental a fin de no penalizar el rendimiento de la base de datos.
5.20 Interconexión con SIR
Se espera abordar en un futuro la interconexión con SIR de toda la aplicación de
registro general del TCu, por lo que se deberá tener en cuenta este hecho en las
decisiones de diseño. La conexión con SIR en sí misma no forma parte de este
proyecto.
6 FASEDEPRllrBlrElMPLANTAClÓN
Una vez que el adjudicatario considere concluido total o parcialmente una
funcionalidad, la aplicación resultante se instalará en el entorno de pre-producción
para que el adjudicatario realice las pruebas unitarias, de integración, funcionales y de
rendimiento y comprobar que los tiempos de respuesta en condiciones normales no
penalizan la experiencia de usuario.
19de20
4l
í
('ylX' Um
%:!N%*L:,í%í X»KR'tl 'al.%:h
í. ' »GERENCIA
SUBD?RECCIÓN DE TECNOLOGíAS DE LAINFORMAClóN Y LASCOMUNICACIONES
10 de julio de 2017
También se realizarán test de estrés para conocer hasta qué punto es escalable la
solución frente a picos de demanda interna o externa..
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
del TCu, sin coste añadido, con las configuraciones necesarias para repetir las
pruebas siempre que se considere oportuno.
Sólo se iniciará la fase de implantación de la aplicación cuando el TCu considere que
Ias pruebas han sido realizadas a su plena satisfacción.
Madrid, a 10 de julio de 2017
EL SUBDIRECTOR DE TECNOLOGÍAS
DE LA INFORMACIÓN Y LAS COMUNICACIONES
//
/
(i'Fdo. Juan AJndrés Hermoso Franco
20 de 20
