MoReq: requisitos funcionales de un SGDEA

Componentes de un SGDEA en MoReqSiguiendo el plan que establecí para abordar la cuestión de MoReq, toca ahora explicar en qué consisten los requisitos que plantea -espero que no sea mucho tostón-. Para ello, haré referencia entre corchetes a la sección correspondiente de la especificación en que se incluyen, de manera que si alguien está interesado en alguna parte en especial pueda encontrarlo más fácilmente.

En la anterior anotación sobre el tema decía que un SGDEA estaba compuesto, de una parte, por el software destinado al efecto; y, de otra, por una serie de procedimientos y políticas (elementos no funcionales). El primero de estos componentes es el principal objeto de la especificación, que incluye no sólo los requisitos funcionales para la gestión de documentos electrónicos de archivo; también hace una somera relación de las funcionalidades que puede tener el sistema con respecto a:

  • la gestión de documentos de archivo no electrónicos [10.1];
  • la conservación y eliminación de expedientes mixtos [10.2];
  • su relación con los SGDE (partiendo de una diferenciación previa de ambos) [10.3];
  • posibles recursos de flujos de tareas [10.4];
  • la utilización de firmas electrónicas [10.5];
  • soportar tecnologías de encriptación [10.6];
  • utilizar filigranas electrónicas y elementos similares [10.7];
  • su interacción con otros sistemas [10.8].

Además, dedica un capítulo entero [12] a los requisitos que debe tener la aplicación con respecto a la utilización de metadatos, así como a los distintos elementos de éstos para cada nivel de la estructura jerárquica (cuadro de clasificación, expediente, volumen de expediente y documento de archivo).

Por otro lado, MoReq recoge también una serie de requisitos genéricos referentes al segundo de los componentes del SGDEA, a los que denomina “requisitos no funcionales”: la usabilidad del sistema [11.1]; el rendimiento [11.2] y disponibilidad [11.3] que debe proporcionar; su conformidad con las normas técnicas establecidas en cada caso [11.4], así como con las disposiciones normativas y reglamentarias aplicables -¡aquí hace referencia al temido efecto 2000!- [11.5]; y los requisitos a tener en cuenta ante la externalización de servicios y la gestión de datos por parte terceros [1.6].

De esta forma, se abarcan los cuatros ejes que comprende un SGDEA, tal y como ha representado gráficamente Roger Crumpton [pdf: 2,86 MB] en la ilustración que acompaña esta anotación. No obstante, esto se está alargando mucho y por eso dejo sólo mencionados los referidos requisitos y paso a describir brevemente los requisitos funcionales propiamente dichos que establece MoReq:

  • Cuadro de clasificación [3]
    Es el elemento clave de cualquier SGDEA, ya que define el modo en que los documentos electrónicos de archivo, una vez capturados en el sistema, se organizan en expedientes, así como las relaciones entre dichos expedientes. Es decir, se les asignan códigos que se corresponden con la clase del cuadro de clasificación a la que pertenecen, lo que permite que el SGDEA los gestione. Estas clases deben reflejar las funciones de la organización, generalmente representadas de forma jerárquica a través del cuadro. A través de cuatro secciones, la especificación enumera los requisitos aplicables a la configuración del cuadro de clasificación [3.1], el trabajo con clases (agrupaciones documentales lógicas en el cuadro de clasificación) y expedientes [3.2], volúmenes (agrupaciones documentales en que pueden dividirse los expedientes muy voluminosos, a efectos de facilitar su gestión) [3.3] y sobre el mantenimiento del cuadro de clasificación [3.4].
  • Controles y seguridad [4]
    Es este capítulo se establecen los requisitos destinados a controlar:

    • el acceso a los documentos del sistema [4.1];
    • la creación de copias de seguridad que permitan recuperar la información de los documentos originales ante cualquier fallo del sistema [4.3];
    • las transferencias y movimientos de los documentos [4.4];
    • la autenticidad de los documentos de archivo [4.5];
    • las condiciones de seguridad de los documentos clasificados [4.6];

    En relación con estos aspectos, la sección 4.2 recoge las pautas necesarias para que el sistema almacene en una pista de auditoría –que podría formar parte de los metadatos asociados a cada documento- cualquier acceso u otra actividad que afecte a un documento de archivo, con objeto de garantizar su admisibilidad jurídica y facilitar la recuperación de los datos.

  • Conservación, eliminación o transferencia [5]
    El sistema debe poder integrar las normas de conservación (tanto las legales como las internas) establecidas para cada expediente y asociarlas a éstos [5.1]. Del mismo modo, la especificación recoge los requisitos para poder gestionar los procesos de revisión de los expedientes una vez alcanzada la fecha o la acción especificada en la norma de conservación (valoración y selección), con el propósito de decidir su conservación, transferencia o eliminación, operaciones que se describen en la sección5.3.
  • Captura de documentos de archivo [6]
    Con el término “captura”, MoReq hace referencia al conjunto de procesos a través de los cuales un documento se incorpora al SGDEA: la captura en sentido estricto -a través de un sistema de entrada flexible, que permita recibir tanto documentos simples como expedientes, en distintos formatos, procedentes de distintos canales de comunicación (redes de área local, redes de área extensa, correo electrónico, fax, correo postal) y con frecuencias de llegada y volumen variables- y el registro (acto por el que se adjudica a un documento de archivo un identificador único en el momento de su entrada en el sistema); su clasificación con respecto al cuadro de clasificación establecido; la adición de metadatos; y almacenamiento en el depósito o repositorio correspondiente. La sección 6.4 hace especial mención a los requisitos necesarios para la gestión del correo electrónico.
  • Referencias [7]
    En este capítulo se abordan los requisitos necesarios para que el SGDEA pueda asignar identificadores únicos para referenciar las distintas entidades que lo componen (clases, expedientes, volúmenes, documentos de archivo).
  • Búsqueda, recuperación y presentación [8]
    “Una parte esencial del SGDEA es la capacidad para que el usuario recupere expedientes y documentos de archivo”. Para ello, se establecen requisitos para las herramientas de búsqueda (que puede apoyarse en un tesauro asociado) y navegación del sistema [8.1], así como para la presentación de la información recuperada, bien en forma de visualización en pantalla [8.2], a través de impresión [8.3] o de cualquier otra que resulte necesaria [8.4].
  • Funciones administrativas [9]
    MoReq se ocupa también de los aspectos relativos a la gestión interna del sistema y a las herramientas asociadas a ésta: recuperación del sistema, copias de seguridad, gestión de parámetros y supervisión del estado del sistema, administración de los perfiles de usuario, elaboración de informes…).

Ahora que ya tenemos una idea sobre lo que es MoReq, ¿qué cambios se van a producir con MoReq2? Esto lo veremos mañana (o pasado). Y así me lo quito de encima de una vez ;-)

Technorati Tags: , , , ,

MoReq: modelo de requisitos para la gestión de documentos electrónicos de archivo

A partir del impulso dado por el DLM-Forum, especialmente a través de su plan de acción -los llamados «10 puntos de seguimiento»-, la Comisión Europea decidió desarrollar un modelo de requisitos para la gestión de documentos electrónicos, que sería financiado a través del programa IDA -en la actualidad IDABC– (ver anotaciones anteriores). La licitación fue concedida a la consultoría británica Cornwell quienes –con el apoyo de un grupo de expertos de varios estados miembros- elaboraron entre 1999 y 2000 la especificación MoReq (versión española: pdf de 2,96 MB), editada por la Comisión Europea en 2001 como suplemento VI de Insar, el boletín europeo sobre archivos. Posteriormente se hicieron traducciones en otras lenguas oficiales comunitarias, incluido el español (cuya traducción fue revisada por el Grupo CARMEN).

El objetivo de MoReq es definir, de forma general, las características que debe tener una «aplicación destinada a la gestión de documentos electrónicos de archivo, si bien también se puede utilizar en la gestión de documentos de archivo tradicionales» (sección 2.2), en el marco de un sistema de gestión de documentos electrónicos de archivo o SGDEA (ERMS: Electronic Records Management System)-. Dicho sistema comprende:

  • El software destinado al efecto, que puede consistir en un módulo especializado, en varios módulos integrados, en software desarrollado a la medida del usuario o en una combinación de varios tipos de programas informáticos (1.3). En la sección 2.2 se indica que los SGDEA suelen o pueden estar integrados (aunque debidamente diferenciados) en un sistema de gestión de documentos electrónicos (SGDE). El SGDEA se ocuparía de gestionar documentos de archivo, mientras que el SGDE se ocupa de documentos electrónicos en el sentido amplio del concepto (que no son documentos de archivo, aunque pueden llegar a serlo).
  • Una serie de procedimientos y políticas, definidos en buena parte por las tradiciones, perspectivas y exigencias normativas propias de cada país y/o de cada organización (1.3).

MoReq se ocupa, fundamentalmente, del primero de los componentes: de definir los requisitos funcionales de la gestión de documentos electrónicos de archivo en el seno de un sistema de gestión de documentos electrónicos de archivo (SGDEA), es decir, aquellas funcionalidades que debe cumplir el software destinado a la gestión de documentos electrónicos de archivo. Y está destinado a:

  • Los posibles usuarios del SGDEA, como punto de partida en la preparación de una licitación.
  • Los usuarios de SGDEA, en la auditoría o evaluación de un sistema ya existente.
  • Las organizaciones dedicadas a la formación, como documento de referencia en la preparación de cursos de gestión de documentos de archivo o bien como material de trabajo en sus cursos.
  • Las instituciones académicas, como instrumento docente.
  • Los proveedores y creadores de SGDEA, como directriz que guíe el desarrollo de sus productos, destacando las funcionalidades necesarias.
  • Los proveedores de servicios de gestión de documentos de archivo, como orientación sobre la naturaleza de los servicios que prestan.
  • Los posibles usuarios de servicios externos de gestión de documentos de archivo, como referencia a la hora de especificar los servicios que van a contratar.

Se trata en cualquier caso de una especificación, no de una norma elaborada por un organismo de normalización reconocido. Sus elementos no son obligatorios, sino recomendaciones de carácter genérico que deben/pueden adaptarse en cada caso específico. No obstante, MoReq distingue entre requisitos preceptivos (aquellos que deberían ser tenido en cuenta en la mayoría de las implementaciones de SGDEA) y requisitos recomendables.

La estructura del documento -articulado en capítulos que a su vez se dividen en secciones- tiene cuatro partes diferenciadas:

  • En una primera se hace una introducción a la especificación (cap. 1) y se explica la terminología básica empleada empleada en la especificación, profundizando además sobre determinados conceptos clave (documento de archivo y documento electrónico de archivo; expediente y volumen electrónico; cuadro de clasificación; clase; SGDEA; captura de documentos de archivo; perfil del usuario), para terminar con una representación gráfica del modelo de relaciones entre entidades en un SGDEA (cap. 2).
  • La parte más importante de MoReq es, lógicamente, los requisitos, establecidos a lo largo de los capítulos 3 a 12. Para no hacer el post excesivamente pesado, dejamos para otro día el repaso a estos requisitos.
  • La parte final (cap. 13) está dedicada a explicar el modelo formal de referencia ya presentado en forma de diagrama en el capítulo 2. Además, cuenta con un glosario más amplio que incluye y completa la terminología básica d la primera parte.
  • Por último, se acompaña de unos anexos con información sobre las normas y documentos de referencia empleados, el desarrollo de la especificación, etc.

Para terminar (por ahora), otra cita de MoReq:

Si los requisitos incluidos en esta especificación MoReq llegan a aplicarse en la práctica, deberán dar lugar a un sistema que gestione documentos electrónicos de archivo con el grado de confianza e integridad deseados, aunando las ventajas del método de trabajo electrónico con la teoría clásica de gestión de documentos de archivo.

Mañana -si todo sale bien- acabo con todo esto de MoReq. Por lo menos, espero que a alguien le sirva (al menos lo mismo que me está sirviendo a mí).

Technorati Tags: , , , ,

IDABC: servicios paneuropeos de e-Administración. Introducción

En junio de 2006 se ha publicado en el sitio web del Consejo Superior de Administración Electrónica (Ministerio de Administraciones Públicas) la última actualización de su estudio La Construcción de los servicios pan-europeos de administración electrónica: estado de la situación de la integración en los servicios panaeuropeos de administración electrónica y actuación de la Administración: el Programa IDABC [documento electrónico]. El otro día lo estuve leyendo a propósito de MoReq (de ello hablaremos en futuros posts) y me pareció que explicaba de forma sencilla y con ilustrativos gráficos lo que hay detrás de esas siglas y en qué se materializa, así como el papel de la Administración española en este Programa. Luego estuve buceando un poco por el portal europa y el Diario Oficial de la Unión Europea y creo que más o menos lo tengo claro. Como introducción a posteriores entradas relacionadas puede estar bien, así que comienzo a soltar el rollo.

IDABC son las siglas de Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens (prestación interoperable de servicios paneuropeos de administración electrónica a las administraciones públicas, a las empresas y a los ciudadanos). Se trata de un programa con base normativa en la Decisión 2004/387/CE del Parlamento Europeo y del Consejo de 21 de abril de 2004 [documento pdf], y un ámbito de aplicación de cinco años (2005-2009). Como señala el art. 2.1 de dicho texto,

El objetivo del programa IDABC es definir, apoyar y promover el desarrollo y establecimiento de servicios paneuropeos de administración electrónica y de sus redes telemáticas interoperables que ayuden a los Estados miembros y a la Comunidad a aplicar, en sus respectivos ámbitos de competencia, las políticas y acciones comunitarias y obtener así importantes beneficios para el sector público, las empresas y los ciudadanos.

IDABC es la continuación de otros dos Programas que prepararon el camino para el despliegue de los servicios de la e-Administración que se desarrollan ahora: los programas IDA e IDA II.

EVOLUCIÓN DE LOS PROGRAMAS IDA-IDABC (1995-2009)

PROGRAMA IDA
(1995-1998)
IDA
II (1999-2004)
IDABC
(2005-2009)
FINALIDAD Interoperabilidad
de los
sistemas de información de los estados miembros
(aprovechamiento de sistemas existentes; política de
estandarización)
Establecimiento
de redes
de transmisión de datos para intercambio de
información (infraestructura, servicios y
aplicaciones)
Desarrollo
y
establecimiento de servicios paneuropeos de administración
electrónica

Como señala la citada Decision 2004/387/CE,

El despliegue de redes telemáticas transeuropeas para el intercambio de información entre las administraciones públicas de toda Europa, las instituciones de la Comunidad y otras entidades como las agencias, servicios y organizaciones europeas que se dedican a fomentar los intereses de la Comunidad no debe considerarse un fin, sino un medio para llegar a servicios de información interoperables y de administración electrónica interactivos a escala paneuropea, partiendo de los beneficios derivados de la cooperación entre las administraciones públicas en toda Europa y aplicando dichos beneficios a los ciudadanos y a las empresas.

Por otro lado, los Programas IDA e IDABC se han integrado en el marco de los sucesivos Planes de acción para el impulso de la Sociedad de la Información en la Unión Europea (eEurope2005, i2010). Sobre esta cuestión puede llerse más en el capítulo 3 del documento del MAP, «IDABC en las estrategias de Administración electrónica de la UE (eEurope 2005, 2010, I+DT,…)«.

Bueno, más o menos esto es lo que es eso de IDA e IDABC. En el siguiente post veremos cómo funciona.