DIRECCIÓN ARCHIVO DE BOGOTÁ ASPECTOS GENERALES DE LA INVITACIÓN A COTIZAR SISTEMA DE INFORMACIÓN.

Transcripción

1 DIRECCIÓN ARCHIVO DE BOGOTÁ ASPECTOS GENERALES DE LA INVITACIÓN A COTIZAR SISTEMA DE INFORMACIÓN. BOGOTÁ D.C., 2013

2 1. ASPECTOS GENERALES. 1.2 Objeto. El proyecto tiene como objetivo principal la adquisición, instalación y puesta en funcionamiento del software necesario para la administración de la documentación histórica física y digital del Archivo de Bogotá que permita el acceso a la información por parte del ciudadano 1.3. Alcance del objeto. El anterior objeto comprende La adquisición de software (sistema de Información) especializado en la gestión de archivos históricos que permita la gestión de manera integral de todas las funcionalidades utilizadas en los archivos históricos que permita el acceso a la información por parte del ciudadano. La parametrización del sistema de información para su adaptación a la estructura de los fondos documentales de carácter histórico y colecciones del Archivo de Bogotá. Realizar un estudio completo que permita obtener como resultado el estado actual de los diferentes modelos entidad-relación que soporta la arquitectura de las bases de datos actuales del Archivo de Bogotá Plantear un esquema de datos nuevo a implementar en el sistema de información adquirido según los requerimientos de la Secretaria General de la Alcaldía Mayor de Bogotá, D.C. Migración de datos actualmente existentes en las aplicaciones: WINISIS (Base de Datos ISIS), Access, Excel para poblar el esquema del sistema de información adquirido, realizando pruebas de funcionamiento de los datos migrados. Los servicios profesionales necesarios para la instalación, puesta en marcha y producción del sistema de información en el Archivo de Bogotá. Los servicios de capacitación a los diferentes perfiles de personal del Archivo de Bogotá y la Subdirección de Informática y Sistemas. Soporte técnico para asistencia en la resolución de incidencias e impartir capacitación adicional de interés del sistema de información, durante un año a partir del recibo a satisfacción de la solución adquirida. 2

3 1.4. Localización. El proyecto se realizará en la sede del Archivo de Bogotá, en la ciudad de Bogotá; para ello el cotizante deberá establecer su logística que le permita entregar los resultados dentro del tiempo establecido Régimen legal aplicable. El proceso resultante y el contrato que se derive de él se regirán por lo dispuesto en la Ley 80 de 1993, Ley 1150 de 2007 y sus decretos reglamentarios Naturaleza de la invitación. Este proceso de invitación y los documentos que se originen o emitan en desarrollo del mismo por el Archivo de Bogotá no implican la realización de una oferta por parte de él, ni crean obligación alguna de contratar con quien presente una cotización, busca establecer los precios de mercado, como base para un proceso de contratación futuro Correspondencia. Toda la correspondencia que se genere y que esté relacionada con la presente invitación, se enviará físicamente a la carrera 8 No Edificio Liévano, o electrónicamente a las siguientes direcciones: jasantos@alcaldiabogota.gov.co a nombre de Javier Alfonso Pacheco. mloaiza@alcaldiabogota.gov.co a nombre de Myriam Astrid Loaiza cluque@alcaldiabogota.gov.co a nombre de Carolina Luque Eusse ffsanchez@alcaldiabogota.gov.co a nombre de Fabio Fernando Sánchez Sánchez 1.8. Plazo estimado de ejecución del contrato. El plazo para la ejecución del objeto del contrato será de seis (6) meses. El participante puede proponer un plazo de ejecución del contrato diferente al solicitado, de acuerdo a su experiencia el cual debe especificar en el formato de cotización. 3

4 2. CONDICIONES ECONÓMICAS Y FINANCIERAS 2.1 Propuesta económica. El proponente deberá presentar el valor de la propuesta por ítem, a todo costo, que debe contener el cuadro resumen general de precios. Para determinar el valor total del proyecto, el cotizante deberá presentar un cuadro resumen general de precios en el cual se entienden incluidos todos los costos y gastos necesarios para cumplir el objeto de la Invitación Pública (suministros, personal, equipos, mobiliario, espacio físico y materiales que se requieran), en las condiciones previstas. El valor de la propuesta, debe incluir todos los costos directos e indirectos que genere la compra venta, del talento humano, de las prestaciones y los salarios del personal que vincule para la ejecución del contrato, de los aportes al Sistema de Seguridad Social Integral y aportes parafiscales, cumpliendo con las normas laborales sobre la materia, de los impuestos y demás gastos que origine el mismo. Por ningún motivo se consideraran costos adicionales. 2.2 Entrega de la cotización. El proponente debe enviar su cotización hasta el próximo 27 de junio de CONDICIONES TÉCNICAS. 3.1 Propuesta técnica. El Archivo de Bogotá está interesado en recibir propuestas para determinar los precios de mercado que permitan la adquisición, instalación y puesta en funcionamiento del software necesario para la administración de la documentación histórica física y digital del Archivo de Bogotá que permita el acceso a la información por parte del ciudadano Requerimientos mínimos. El sistema de información deberá permitir la gestión archivística de los fondos documentales con carácter histórico y colecciones que el Archivo de Bogotá acopia y custodia contempla las siguientes funcionalidades: 4

5 Organización jerárquica de la información. Grabación y referencia de información descriptiva. Digitalización de imágenes. Consulta de la información descriptiva y de las imágenes. Preparación de instrumentos de consulta (catálogos e índices), parametrizables por el usuario que genere el instrumento. La arquitectura de la plataforma es 100% web Está orientada a Servicios Web y cuenta con un BUS de integración ESB. Se utiliza para su desarrollo tecnologías "Open Source" de código completamente abierto (PHP, Codelgniter Framework y MySQL Server). Está orientada por procesos. Cuenta con herramientas de reporteo dinámico y análisis de datos tipo BI (business intelligence) La plataforma cuenta con soporte para dispositivos móviles El sistema debe permitir cargue de documentos, en diferentes versiones, cualquier formato y debe registrar su trazabilidad. Se integra con directorios activos de manera nativa. Sustenta tecnológicamente la posibilidad de integración de la plataforma con otros aplicativos. La empresa provee una metodología de capacitación para la utilización del software de los usuarios. El sistema de información deberá cumplir mínimo con cualidades de ejecución, como la seguridad, usabilidad, utilidad, fiabilidad, solidez o robustez y eficiencia o desempeño, observables en el término de ejecución, adicionalmente, con cualidades de evolución, como la testeabilidad, mantenibilidad, portabilidad, modularidad y extensibilidad o escalabilidad, claridad, robustez, amigabilidad, facilidad de uso, compatibilidad, extensibilidad, reusabilidad, parametrización, 5

6 vulnerabilidad. auditabilidad, descomponibilidad, componibilidad, comprensibilidad, continuidad, protección modular determinadas por la estructura estática del software. Estas son las características básicas, acordadas por el grupo especializado de Sistemas de Información de la Subdirección de Informática y Sistemas, y son las que debe cumplir todo sistema de información que se pretenda implementar en la plataforma tecnológica de la Secretaria General de la Alcaldía Mayor de Bogotá. A continuación se describe cada una de las cualidades: Seguridad: El sistema deberá restringir el acceso por medio de uso de claves asignadas a cada uno de los usuarios. Sólo podrán ingresar al sistema las personas que estén registradas, estos usuarios serán clasificados por roles con acceso a las opciones de menú definidas para cada rol. Debe darse cumplimiento a la política de seguridad de la información referenciada en la Directiva 042 de Puede ser consultada en el siguiente link: Teniendo en cuenta como mínimo los siguientes controles: Realizar pruebas manuales o automáticas para los datos de entrada al sistema para asegurar que dichos datos son correctos y apropiados, con sus debidos controles. Documentar procedimientos para evitar que los programas se ejecuten en orden erróneo o su ejecución después de falla previa del procesamiento. Determinar cuáles serían las verificaciones de validación mínimas a realizar al sistema para detectar cualquier corrupción de la información por errores de procesamiento. Validar los datos de salida de las aplicaciones para asegurar que el procesamiento de la información almacenada es correcto y adecuado a las necesidades esperadas. Respecto a la autenticación de usuarios se podrá realizar a través del Directorio Activo de la Secretaría General de la Alcaldía Mayor de Bogotá D.C. por medio de LDAP (Lightweight Directory Access Protocol) o a través de registro de usuarios propio del sistema, es decir, deberán existir los dos mecanismos. El sistema deberá contar con esquemas de agrupamiento de usuarios por roles y grupos, de esta manera un usuario podrá pertenecer a varios roles o grupos. El sistema debe tener la capacidad de generar un reporte de todos los usuarios y roles asignados. En cuanto a la definición de contraseñas: - Mínimo de caracteres para las claves de acceso 6

7 - Número de días de vigencia de las claves de acceso - Bloqueo automático de cuentas después de cierto número de días sin ser utilizada - Número de intentos de ingreso con clave errónea para bloquear la cuenta - Tiempo de inactividad de una cuenta antes de ser cerrada automáticamente - Las credenciales de autenticación deben ser almacenadas por el sistema con algoritmos de encripción o hash y longitudes de llave robusta. - Las claves no se deben presentar en pantalla, y se deben ocultar en todo momento, incluso en el momento en que se escriben. - Deberá contar con la funcionalidad de integrar un sistema de autenticación fuerte tipo Token de hardaware, que genere claves numéricas aleatorias de al menos 6 cifras y que cambien constantemente. Esta autenticación brinda mayor seguridad al integrar dos factores de seguridad, algo que se tiene más algo que se sabe. - Permitir incluir y modificar la información general del usuario (nombre, teléfono, extensión, dirección de , cargo, seccional, dependencia). La clave podrá ser cambiada por el usuario pero requerirá confirmación de la nueva clave y aprobación vía . - Debe manejar sesiones por usuario con Cookies generadas directamente por el sistema, las cuales deben estar cifradas. - Debe implementar mecanismos para la administración de sesiones activas de usuario y prevenir spoofin/suplantación. - Debe permitir implementan un número máximo de intentos fallidos de inicio de sesión. - Debe permitir configurar un tiempo límite para la expiración de sesión de los usuarios si no se detecta actividad. 7

8 - El sistema deberá permitir el establecimiento, revisión y actualización de perfiles de usuario denominados grupos de usuarios de acuerdo con su perfil o usuarios individuales, por medio de los cuales se define la capacidad de actuación de cada usuario con el sistema y su relación con los fondos, entre otras: Selección de los grupos de usuarios que pueden editar y/o consultar aquellos elementos que tengan asociada una ficha descriptiva concreta. Permite determinar condiciones de servicio, si se pueden servir las unidades físicas o imágenes digitales, a quién (listas de control de acceso), etc. Seguimiento de los movimientos de los documentos y su utilización por distintos usuarios. El sistema debe permitir el acceso a las descripciones correspondientes a los usuarios autorizados. El sistema deberá contar también con el módulo para Gestión de los Usuarios de la Sala de Consulta, permitiendo realizar las siguientes acciones: Creación, modificación y consulta de usuarios (investigadores ) Gestión temas de investigación. Renovación de tarjeta de investigador. Impresión de la tarjeta de investigador. El sistema deberá tener la capacidad de generar un reporte de todos los usuarios y roles asignados. Deberá permitir la operación en HTTPS con SSL, para lo cual se requerirá certificados generados por una entidad certificadora. Deberá permitir generar registros de auditoría (Logs de seguridad) registrando como mínimo el usuario, intento fallido o exitoso de autenticación, fecha y hora del evento, tipo de evento, descripción del evento, dirección IP desde donde se realizó el evento. El log de auditoría deberá estar protegido del borrado o modificación no autorizada, incluso del administrador del sistema. 8

9 Confidencialidad: El sistema deberá estar en capacidad de rechazar accesos o modificaciones indebidas (no autorizadas) a la información y proveer los servicios requeridos por los usuarios legítimos del sistema. Utilidad: El sistema deberá garantizar que satisface las necesidades del cliente. Fiabilidad: El sistema deberá garantizar que el tiempo entre fallas y el tiempo promedio de reparación sea el menor posible. Solidez o robustez: El sistema deberá responder de manera correcta a posibles entradas inválidas que se puedan presentar. Todos los aspectos concernientes a valores, reglas de validación, cálculos, comunicaciones, deberán quedar definidos de tal manera que con el producto de software se logren, aún en condiciones anormales. Eficiencia o desempeño: El sistema deberá garantizar que cuando haya hasta 500 usuarios accediendo simultáneamente a él, su tiempo de respuesta no será en ningún momento superior a 2 segundos, todo enmarcado en la medida de las posibilidades tecnológicas de la entidad. Testeabilidad: El sistema deberá contar con facilidades para la identificación de los errores durante la etapa de pruebas y de operación posterior. Mantenibilidad: El sistema deberá ser diseñado para que su mantenimiento sea fácil y de esta manera pueda ser ampliado y corregido en caso de ser necesario. Portabilidad: El sistema deberá poder ser fácilmente instalado en otro servidor con diferentes características al inicial, en caso de ser necesario. Alta Disponibilidad: El sistema deberá poder ser instalado en un esquema de alta disponibilidad, mediante conexión a base de datos por medio de ORACLE RAC 10g y gestionado por balanceadores de cargas y aplicaciones. Modularidad: El sistema deberá ser diseñado mediante componentes o módulos independientes integrados, que permita evolucionar módulos por separado. Adicionalmente, que sustente tecnológicamente la posibilidad de integración de la plataforma con otros aplicativos. 9

10 Claridad: Se deberá especificar en forma clara, completa y precisa las tareas que realiza el sistema. Robustez: Todos los aspectos concernientes a valores, reglas de validación cálculos, comunicaciones, deberán quedar definidos de tal manera que con el producto de software se logren aún en condiciones anormales. Amigabilidad: El desarrollo deberá realizarse en ambiente Windows y/o Linux y con las herramientas Oracle con las cuales cuenta la Secretaria General, contemplando los estándares propios de estos ambientes. La aplicación deberá contar con interfaces de usuario que permitan una fácil e intuitiva navegación por parte de los usuarios y ciudadanos en su operación, facilitando la entrada de datos, la interpretación de resultados y la recuperación de los errores cometidos. El desarrollo de las interfaces del sistema deben cumplir con la normatividad: Resolución 378 del 19 de Diciembre de 2008 por la cual se adopta la Guía para el diseño y desarrollo de sitios Web de las entidades y organismos del Distrito Capital. Puede ser consultada en la siguiente link: Facilidad de uso: La interface de entrada debe ser fácil de usar, que facilite la entrada de datos, la interpretación de fas resultados y la recuperación de los errores cometidos. Compatibilidad: Debe contemplar la fusión e interacción con los sistemas ya existentes. Extensibilidad o Escalabilidad: Teniendo en cuenta que el sistema generará óptimos resultados, se le podrá exigir que realice nuevas tareas, éste debe ser flexible para ser ampliado en su funcionalidad. El sistema deberá ser flexible para poder ser ampliado en su funcionalidad cuando sea necesario que realice nuevas tareas. Adicionalmente, las funcionalidades deberán ser construidas sobre objetos que sean fácilmente reutilizables para el uso en otros sistemas. Reusabilidad: En lo posible las interfaces se deben construir sobre objetos que sean fácilmente 10

11 utilizables para extender la aplicación. Portabilidad: Deberá contemplarse los aspectos que permitan migrar fácilmente la aplicación a sistemas operativos nuevos y su Independencia funcional con la plataforma. Parametrización: El sistema deberá tener la capacidad de soportar cambios sin necesidad de modificar el software desarrollado. Vulnerabilidad: El sistema debe facilitar el control de acceso y la auditoria necesaria para la ejecución de los proceso. Auditabilidad: El sistema debe tener un módulo que permita hacer el seguimiento de las transacciones realizadas en él. Modularidad: El sistema deberá ser diseñado mediante componentes o módulos independientes integrados, que permita evolucionar módulos por separado. Adicionalmente, que sustente tecnológicamente la posibilidad de integración de la plataforma con otros aplicativos. Descomponibilidad: Descomponer los problemas en subproblemas cuya solución pueda ser alcanzada separadamente. Componibilidad: Debe garantizar que el conjunto de soluciones definidas para los subproblemas sea la solución del sistema global. Comprensibilidad: Debe permitir que una persona entienda cualquiera de sus elementos separadamente. En el peor de los casos la persona debería tener que mirar unos pocos módulos relacionados. Continuidad: Debe desarrollarse de tal manera que un cambio pequeño en las especificaciones del sistema se traduzca en un cambio en un solo módulo, o en el peor de los casos en pocos módulos. Protección modular: Debe desarrollarse de tal manera que el efecto de una condición anormal que ocurra en un módulo permanezca confinada en dicho módulo, o en el peor de los casos a algunos pocos vecinos a él. 11

12 El sistema de Información deberá estar desarrollado e implementado sobre la actual plataforma de la Secretaria General de la Alcaldía Mayor de Bogotá, D.C., es decir, utilizando un esquema de tres capas y con las siguientes características: Ambiente 100% WEB Utilización de estándares abiertos ver listado. Para su funcionamiento no se debe requerir la adquisición de licencias y/o software adicional al que disponga la Secretaría General de la Alcaldía Mayor de Bogotá. La administración de los usuarios, creación, modificación, actualización y perfiles debe ser directamente desde la aplicación y no por base de datos. El software debe ser multicompañía, es decir que dentro del sistema se pueda diferenciar parametrización y transacciones individualmente para que gestione múltiples empresas (entidades distritales), de tal manera que permita su administración independiente. (parámetros, Usuarios, transacciones, seguridades, etc) sin que existan mezclas o traslapos de información entre empresas El sistema debe contar con una herramientas de reporteo dinámico, parametrizable. Los usuarios pueden extraer información no estándar sin necesidad de hacer un diseño y/o desarrollo de reportes. El sistema debe poderse integrar de manera nativa con directorios activos, al igual, que debe tener la opción de funcionar sin necesidad de un directorio activo. El sistema no debe incluir plugines, componentes o cualquier otro tipo de software privativo o licenciado bajo cualquier esquema de tipo comercial. Listado de estándares abiertos que debe cumplir el desarrollo del software: - SQL 2008 (structured query language) - W3C - HTML4 Y 5 - SOAP XML BPMN 1.2 Si la aplicación se desarrolla bajo lenguaje JAVA: - JEE - SERVLET

13 - JSF 2.0 Uso de interfaz gráfica con librerías como Rich Faces, ICE Faces o Prime Faces que enriquecen el ambiente gráfico del sistema y facilita su desarrollo. Infraestructura tecnológica: El sistema de información debe funcionar con independencia del sistema operativo que disponga la Secretaría General (Windows, Linux, o cualquier otro), se debe desarrollar e implementar en ambiente web y con soporte para dispositivos móviles, bajo la especificación JEE, lenguaje de programación JAVA ó PHP sobre la actual plataforma de la Entidad, es decir, utilizando un esquema de tres capas: 1) Capa cliente: Corresponde al navegador web (Internet Explorer 8 o superior, Mozilla Firefox 10 o superior y Safari en su versión más reciente), debe incorporar el estándar W3C; 2) Capa media: Compuesta por Servlet 3.0, JSF 2.0, Java Beans y EJB (Enterprise Java Beans) y/o Clases PHP), manejados por los contenedores Apache Tomcat 7, Glassfish 3.1 y/o Jetty 8 3) Capa de datos: Corresponde al motor de base de datos utilizando el estándar SQL (Structure Query Languaje) 2008 y que funcione sobre motores de base de datos ORACLE versión 11g, MySQL y PostgreSQL últimas versiones. No se deben utilizar paquetes, procedimientos almacenados y/o funciones de propias de los motores de base de datos, toda la funcionalidad debe ser realizada desde la aplicación. En cualquier caso se debe tener en cuenta el desarrollo orientado a componentes y las aplicaciones tipo RIA. Además con la solución propuesta debe incluir el Motor de reglas de negocio, así como el cargue de información y parametrización inicial para su correcta implementación y funcionamiento. Por otro lado, el sistema deberá entregarse probado y funcionando de forma correcta en los equipos de cómputo destinados por la entidad para tal fin. El sistema deberá garantizar que el diseño de las consultas no afecte el desempeño de la base de datos, ni considerablemente el tráfico de la red. El sistema de información de gestión de archivos históricos ofrecido, deberá ser un software orientado de forma específica para la gestión archivística de documentación con carácter histórico, con la capacidad y flexibilidad para permitir la gestión de los distintos tipos de fondos documentales 13

14 y colecciones conservados en el Archivo de Bogotá y con amplia implementación en archivos históricos. El objeto de este ítem técnico es definir las condiciones tanto generales como operativas que ha de cumplir la aplicación informática. Metodología De Desarrollo De Software: El proponente deberá especificar en su oferta la metodología de desarrollo software o mejor práctica de amplio aceptación a usar para el desarrollo e implementación del software. 3.3 Funcionalidades de manejo. El aplicativo deberá cumplir las siguientes funcionalidades de manejo: Idioma español. Facilidad de uso. debe proveer el manual de usuario en línea y proporcionar mensajes de error para ayuda de operación al usuario. Teclear lo indispensable uso de listas para escoger valores a partir de índices de entrada y recuperación de información. El sistema debe permitir la creación de listas de términos controlados ilimitadas. La actualización de la información deberá ser en línea, facilitando la consulta inmediata de los datos introducidos en el sistema. 3.4 Funcionalidades operativas. Los requerimientos que se enumeran a continuación deberán ser cumplidos por el sistema de información de gestión de archivos históricos y colecciones, su parametrización se hará a partir de los módulos requeridos por los usuarios del sistema Gestión inventarios documentales. Debe permitir la agrupación de los fondos documentales y colecciones por las diferentes formas de acopio (transferencia, donación, compra, canje) establecidas por la Dirección Archivo de Bogotá. Debe permitir la administración integral de los inventarios de los fondos documentales, colecciones y publicaciones. Debe permitir el control económico (cuantificado en número y en pesos) de los inventarios de los fondos documentales, colecciones y publicaciones. 14

15 Debe permitir la generación de estadísticas e informes detallando ingresos, egresos y asignación de costos de los inventarios, fondos documentales, colecciones y publicaciones acotados por fecha u otros índices (forma de acopio, costos) Organización de fondos documentales y colecciones. Debe permitir estructurar el sistema de clasificación de fondos documentales y colecciones de forma dinámica y sin límite en el número de niveles jerárquicos (utilizando la estructura de datos de árbol: conjunto de nodos conectados). Debe permitir la actualización en línea del sistema de clasificación de fondos documentales y colecciones. Debe permitir los cambios, duplicación y borrado de elementos individuales o ramas completas del sistema de clasificación de fondos documentales y colecciones, siempre que se cuente con el perfil de usuario necesario. Debe permitir la validación de elementos, sistema de clasificación de fondos documentales y colecciones de forma individual o de ramas completas, siempre asociado al perfil de usuario necesario. Debe permitir que el acceso a los distintos elementos del sistema de clasificación de fondos documentales y colecciones pueda ser abierto o restringido en función de los distintos acervos documentales, autorizándose el acceso únicamente a determinados perfiles de usuario Descripción archivística y catalogación documental. Debe tener dos módulos: un módulo para la descripción archivística conforme a los estándares ISAD(G) e ISAAR(CPF), y otro módulo para catalogación de material bibliográfico y hemerográfico en formato MARC. Debe disponer de herramientas para la actualización e incorporación de nuevos estándares de descripción archivística y catalogación. Debe permitir la generación de listas de términos controlados, que podrán ser: a) Abiertas, de forma que las vaya elaborando el usuario autorizado conforme las necesita, para su posterior validación por el responsable de normalización (organismos, personas, familias, toponímicos, entre otros). b) Cerradas, que se crean a priori con una serie cerrada de elementos y entre éstas podrían encuadrarse las de tipos de soporte, tipos de letra, niveles de descripción, entre otros. 15

16 Debe disponer de herramientas que faciliten la normalización de los términos de las listas de descriptores. Debe permitir la creación de un Thesauro de forma dinámica para la creación y modificación de los términos del Thesauro, las relaciones de Thesauro, el tratamiento de no descriptores y la visualización jerárquica del Thesauro o en forma de lista alfabética. Debe disponer de herramientas para la generación de signaturas de forma masiva conforme a un formato predefinido y con unas condiciones de servicio. Debe disponer herramientas que le permitirán al administrador controlar la producción de los responsables de la descripción. Debe disponer herramientas para que el administrador pueda realizar correcciones masivas en los textos de las descripciones con una herramienta de Buscar Sustituir. Debe desplegar mensajes de ayuda en cada campo definiendo las características de la descripción y la catalogación, con el objeto de normalizar la información que contiene cada campo. Debe generar mensajes de alerta cuando falten campos obligatorios por diligenciar. Debe permitir la generación de rótulos de las unidades documentales. Debe mostrar la ubicación de los documentos y generar alarmas de cumplimiento de términos en cada proceso técnico. La herramienta debe permitir que un administrador funcional cambie la parametrización de acuerdo a nuevas necesidades. Debe permitir logs de auditoría que registren la información de ingresos, modificaciones, eliminaciones. Debe permitir la gestión de los documentos electrónicos de archivo Digitalización, importación y exportación de imágenes. El propósito del módulo es permitir la conexión de diferentes sistemas de captura con el Sistema de Información y la vinculación de las imágenes con su respectiva descripción documental. Debe permitir la integración de sistemas de captura (escáneres planos, cenitales, cámaras digitales), mediante controladores TWAIN. Debe permitir la digitalización de imágenes según la estructura jerárquica de la documentación, en legajos, documentos, páginas, entre otros. Debe permitir la importación de Imágenes digitalizadas externamente en formatos estándar. 16

17 Debe permitir vincular imágenes a los registros descriptivos de forma individual o masiva. Debe permitir el tratamiento de la imagen para mejorar su legibilidad, este tratamiento debe ser específico para los problemas que se presentan en la documentación histórica. (Eliminación de manchas, reducción de tintas transparentadas, realce de tintas desvaidas, etc). El software para tratamiento y mejora de las imágenes debe ser un desarrollo propio. El sistema debe permitir que desde la estructura del documento se puedan identificar las imágenes asociadas a él, y debe tener acceso directo a las imágenes. Debe tener un sistema de hipervínculos que permitan recuperar y visualizar los distintos tipos documentales relacionados con una misma unidad documental Consulta, visualización de fondos documentales y colecciones. El propósito del módulo es permitir la consulta y búsqueda tanto de forma básica como avanzada. Igualmente debe facilitar la navegación gráfica a través del Cuadro de Clasificación. Debe permitir la opción de aplicar herramientas de restauración para mejorar la visualización de las imágenes digitalizadas. De este modo el usuario deberá poder aplicar, de manera opcional, sencilla y eficiente, durante la visualización de imágenes, tratamientos específicos para la eliminación de manchas, realce de tinta desvaída, entre otros, de forma que se facilite su lectura en el momento de la consulta, sin modificar la imagen original. Debe permitir la navegación a través de la estructura jerárquica de la documentación y la visualización de fichas, imágenes así como la reproducción sonora y audiovisual, integrando los componentes a partir de sus características. Debe permitir diferentes métodos de búsqueda, incluyendo la combinación de consultas de tipo texto libre, acotaciones por fecha y/o contexto jerárquico dentro del sistema de clasificación de fondos documentales, colecciones y descriptores, con o sin relaciones de Thesauro. Debe permitir una búsqueda avanzada con campos definidos. Debe permitir el uso de truncamiento de textos, operadores booleanos (y, o y no) y Thesauro definidos desde el proceso de descripción, clasificación y catalogación. Debe permitir la visualización y acceso a las imágenes vinculadas con la referencia descriptiva existente en la base de datos. Debe permitir la navegación rápida por las imágenes de la unidad archivística siguiendo su estructura y el acceso directo a imágenes concretas. Debe permitir en la visualización de imágenes la realización de rotaciones, desplazamientos, ampliaciones y reducciones de modo continuo sin modificar la imagen original. 17

18 3.4.6 Definición de perfil de usuarios. El objetivo del módulo es permitir la administración de los usuarios, grupos y permisos que sean asignados en el Sistema de Información con el fin de brindar privacidad y organización con la posibilidad de configurar al detalle el nivel de acceso de los mismos. Debe permitir definir, gestionar y administrar distintos perfiles de usuarios (internos o externos) y la asignación de funciones a usuarios y grupos de usuarios. Debe permitir controlar el acceso a la información mediante la creación de los grupos de usuarios que sean necesarios y la creación de listas de permisos de acceso a un objeto o conjunto de objetos de la base de datos, de tal forma que un usuario sólo pueda acceder a la información que le corresponda. Deberá permitir ocultar determinados campos de las fichas descriptivas a determinados usuarios. Debe disponer de herramientas para la creación, modificación y consulta de usuarios Debe disponer herramientas para la gestión de temas de investigación. Debe permitir emisión de carnet de investigador Gestión de la sala de consulta. El objetivo del módulo es permitir la administración de la sala de consulta del Archivo de Bogotá con sus diferentes puestos de trabajo controlando el préstamo de unidades documentales, material bibliográfico, gráfico, cartográfico, audiovisual, sonoro, hemerográfico, entre otros. Debe permitir la gestión de la sala de consulta en la identificación, asignación a los usuarios de las mesas de trabajo, y su liberación, como apoyo a la consulta de fondos documentales y colecciones. Debe permitir el control del servicio de circulación y préstamo para la generación de informes, estadísticas, histórico de consultas entre otros. Debe permitir la generación de alarmas para el préstamo externo del material que se facilite a los funcionarios. El sistema debe autorizar el servicio de reprografía y notificar al funcionario de Sala de Consulta y al área encargada de este proceso para que se haga su reproducción. Debe permitir el control de solicitudes y generación de reportes por tipos documentales y número de copias. 18

19 3.4.8 Servicio de reprografía. El propósito del módulo es permitir la administración de las reproducciones solicitadas de cualquier tipo de material documental que no tenga reserva legal. Así como el control de solicitudes y generación de reportes por tipos documentales y número de copias. Igualmente, el sistema debe permitir la configuración del servicio de reprografía en cuanto a procedimientos, costos y autorización de solicitudes. De igual manera, la consulta de las peticiones canceladas, entregadas y pendientes Preparación de instrumentos de descripción. Debe permitir la preparación de instrumentos de descripción identificando el contenido y definiendo el formato y salida en el que se desea obtener el resultado (fichas, guías, inventarios, catálogos) definidos en la parametrización de acuerdo a los índices de entrada, búsqueda de la información. Debe permitir incluir campos de descripción, modificarlos, y eliminarlos a partir de la definición previa de los niveles de descripción, índices de entrada y búsqueda de información. El sistema debe permitir la modificación de los elementos o metadatos de los que se quiere incluir información en el instrumento de descripción elaborado Gestión de depósito. El objetivo del módulo es permitir la administración de los depósitos con toda su disposición física para identificar el nivel de ocupación de los mismos y de esta forma proyectar el ingreso de nuevas unidades documentales. Debe permitir identificar el depósito, los elementos que lo componen (Islas, cuerpos de estantería, entrepaños, bandejas), el estado de los depósitos (espacio libre/ocupado, porcentaje de ocupación, y su equivalente en metros lineales), así como la asignación de números topográficos para las unidades de almacenamiento que ingresen al depósito. Debe permitir la identificación de la documentación que se encuentra ubicada en el depósito a través de un hipervínculo que permita la visualización del inventario de la misma y muestre de manera gráfica el depósito. 19

20 Generación de estadísticas e informes. El objetivo del módulo es permitir la generación de estadísticas que proporcionen información detallada del uso del Sistema de Información y sus diferentes módulos. Debe permitir la generación de estadísticas e informes incluyendo las unidades documentales solicitadas por: fecha de solicitud o devolución, estado, usuario, unidades procesadas por área técnica y funcionario, solicitudes de reprografía por usuario, consultas de fondos, series, unidades documentales y colecciones que se hagan de manera presencial o virtual. Debe permitir generación de informes a través de formatos normalizados. Debe permitir generar relación de investigadores. Debe permitir generar expedientes de investigación. Debe permitir elaborar estudio de usuarios. Debe generar un reporte las publicaciones, fondos documentales y colecciones acopiadas con sus respectivos precios Consultas a través de la página Web. El propósito del módulo es permitir la consulta de los fondos documentales y colecciones que se encuentren procesados en el Sistema de Información, de manera integral. Para la consulta a través de la página web debe permitir el acceso libre y el acceso mediante usuario y contraseña. Debe permitir a los usuarios autorizados realizar, a través de un navegador, la consulta mediante la estructura jerárquica de la documentación y por enlaces, las funciones de búsqueda por texto libre y por descriptores, y la búsqueda por criterios jerárquicos y cronológicos. Debe permitir el acceso a los instrumentos de descripción y catalogación de los fondos documentales y colecciones Funciones de acopio de fondos documentales y colecciones. Debe permitir incorporar Tablas de Retención Documental (TRD) y Tablas de valoración Documental (TVD) identificadas por productor documental, asociando alarmas de cumplimiento a los tiempos de retención documental. 20