Mo req2010 español 2

MoReq2010®

Modelo Modular de Requisitos para la gestión de documentos electrónicos de archivo

Volumen 1Servicios Básicos & Módulos de

integración informáticaVersión 1.0

Copyright © 2010 & 2011 DLM Forum Foundation, all rights reservedee

MoReq2010® – Volume 1 – Core Services & Plug-In Modules of 520

Copyright © 2010 & 2011 DLM Forum Foundation, all rights reserved

Tabla de contenidos

TABLA DE CONTENIDOS………. ......................................................................................................2

PARTE UNO –SERVICIOS BÁSICOS............................................................................................... 10

1. FUNDAMENTOS.. .................................................................................................................... 11

1.1 Información Importante 11

1.2 Propósito 12

1.3 Antecedentes 14

1.4 Generalidades 19

2. SERVICIOS DEL SISTEMA.......................................................................................................... 31

2.1 Información del Servicio 31

2.2 Conceptos Clave 31

2.4 Requerimientos Funcionales 39

3. SERVICIO A USUARIOS Y A GRUPOS.......................................................................................... 51




4. MODELO DE SERVICIO DEL ROL................................................................................................. 57


4.2 Cumplimiento con el Modelo Servicio del Rol 57



5. SERVICIO DE CLASIFICACIÓN..................................................................................................... 70




6. SERVICIO DEL DOCUMENTO..................................................................................................... 77





6.3 Ejemplos de Agrupación y Clasificación 89


7. MODELO SERVICIO DE METADATOS........................................................................................ 100


7.2 Cumplimiento con el Modelo servicio de Metadatos 100



8. SERVICIO PARA PROGRAMAR LA ELIMINACIÓN..................................................................... 117




9. SERVICIO DE RETENCIÓN DE LA ELIMINACIÓN....................................................................... 141




10. SERVICIO DE BÚSQUEDA E INFORMES.................................................................................. 145




11. SERVICIO DE EXPORTACIÓN................................................................................................. 156

11.1 Informacion del Servicio 156



12. REQUERIMIENTO NO FUNCIONALES. .................................................................................... 174


12.2 Los Aspectos no Funcionales de un Sistema de Documentos 178

12.3 Non-functional Requirements for Performance 185

12.4 Non-functional Requirements for Scalability 187

12.5 Non-functional Requirements for Manageability 188

12.6 Non-functional Requirements for Portability 190



12.7 Non-functional Requirements for Security 191

12.8 Non-functional Requirements for Privacy 192

12.9 Non-functional Requirements for Usability 193

12.10 Non-functional Requirements for Accessibility 193

12.11 Non-functional Requirements for Availability 193

12.12 Non-functional Requirements for Reliability 194

12.13 Non-functional Requirements for Recoverability 195

12.14 Non-functional Requirements for Maintainability 197

12.15 Non-functional Requirements for Supported 198

12.16 Non-functional Requirements for Warranted 199

12.17 Non-functional Requirements for Compliance 200

13. GLOSARIO DE TÉRMINOS..................................................................................................... 202

14. MODELO DE INFORMACIÓN................................................................................................. 252

14.1 Indice al Modelo de Información 252

14.2 Tipos de Entidad 262

14.3 Estructuras de los Datos 275

14.4 System Metadata Element Definitions 277

14.5 Definiciones de la Función 336

15. RECONOCIMIENTOS………...................................................................................................... 461

15.1 Equipo del Proyecto 461

15.2 Grupo de Revisores Expertos 461

15.3 Consultores 462

PARTE DOS –MODULOS DE INTEGRACIÓN INFORMÁTICA........................................................... 464

100. SERIES DE INTERFACE......................................................................................................... 465

101. INTERFACE GRÁFICA DE USUSARIO (IGU)............................................................................ 465

101.1 Información del Módulo 465



101.5 Requerimientos no funcionales 474

101.6 Glosario de Términos 476

102. INTERFACE DE APLICACIÓN DE PROGRAMACIÓN (IAP)....................................................... 481





102.4 Requisitos Funcionales 482

102.5 Requisitos no funcionales 484


200. SERIES DE CLASIFICACIÓN.................................................................................................. 487

201. CLASIFICACIÓN JERÁRQUICA.... ........................................................................................ 487






201.7 Información del Modelo 497

300. SERIES DE COMPONENTE.................................................................................................... 502

301. COMPONENTES ELECTRÓNICOS......................................................................................... 502






301.7 Información del Modelo 516



PARTE UNO – SERVICIOS BÁSICOS



1. Fundamentos

1.1 Información Importante

1.1.1 Propiedad de los Derechos Intelectuales

Los derechos de la especificación MoReq2010® pertenecen al la Fundación © DLM Forum, 2010 & 2011. Todos los derechos reservados incluyendo el texto completo y las ilustraciones originales.

Algunas ilustraciones provienen de clip arts de uso libre producidas por Microsoft Corporation disponibles en http://www.microsoft.com/.

La reproducción de esta obra se autoriza excepto con fines comerciales, siempre y cuando se cite la fuente original. Todos los reconocimientos se deben realizar a la Fundación DLM Forum en http://www.dlmforum.eu/.

1.1.2 Autenticidad

La última versión actualizada de este documento solo está disponible desde http://moreq2010.eu/ and http://www.dlmforum.eu/.

El DLM Forum® no actualiza, proporciona o aprueba la especificación MoReq2010® e n en ningún otro sitio web, servicio o mecanismo de distribución.

1.1.3 Citación

Esta publicación debe citarse formalmente como:

Fundación DLM Forum, MoReq2010® Modelo Modular de Requisitos para la gestión de documentos electrónicos de archivo, Volumen1 : Servicios Básicos y Módulos de Integración Informática, 2011, publicados en http://moreq2010.eu/. (MoReq2010®: Modular Requirements for Records Systems – Volume 1: Core Services & Plug-in Modules, 2011).

1.1.4 Traducciones

Debe obtenerse un permiso antes de que cualquier traducción de MoReq2010® sea publicada o distribuía con cualquier propósito. Los traductores deben dirigirse al secretariado de DLM Forum para solicitar permiso mediante un correo electrónico a [email protected].

El permiso para realizar una traducción de MoReq2010® la concede DLM Forum® y sus miembros para realizar copias libres, usar y distribuir la traducción con propósitos no comerciales y publicar la traducción en el sitio web de MoReq2010®.

1.1.5 Logos and marcas registradas

Los logos de la Fundación DLM Forum, el Concejo directivo de MoReq y MoReq2010®

están protegidos por derechos de autor en la Fundación © DLM Forum, desde 1996 hasta el presente.

Los términos “DLM Forum”, “MoReq”, “MoReq2” y “MoReq2010” son marcas registradas de la Fundación DLM Forum.

El símbolo de la Comisión Europea (European Commission) se utiliza con permiso otorgado

mailto:[email protected]

http://moreq2010.eu/

http://www.dlmforum.eu/

http://moreq2010.eu/

http://www.dlmforum.eu/

http://www.microsoft.com/


MoReq2010® – Volume 1 – Core Services & Plug-In Modules of 520por dicha entidad.



1.1.6 Convenciones utilizadas en esta publicacion

A lo largo de esta especificacion, todos los requisites formales asi como las definiciones para los tipos de datos, se han fijado para una facil identificacion, de la siguiente manera:

• E – Estructura de los datos;• T – Tipo de entrada;• F – Definicion de la funcion;• M – Definicion del elemento de los metadatos;• N – Requisitos no funcionales; y• R – Requisitos (funcionales).

Note que cualquier numero de referencia prefijado de esta forma, tiene el unico proposito de facilitar su busqueda, y se refiere a versions anteriores de MoReq2010®, y puede estar sujeto a cambios en cualquier version anterior o posterior, a medida que se agregen o cambien los requisitos y las definiciones.

Los sistemas de documentos y otras aplicaciones que implemente MoReq2010® deberan utilizar siempre los identificadores unicos universales proporcionados por la informacion del modelo.

Tanto los requerimientos funcionales como los no funcionales en esta especificación, pueden estar acompañados por una nota explicatoria en cursiva. Donde se presente, la nota pretende proporcionar claridad y ampliar el requisito.

1.2 Propósito

1.2.1 Objetivo

MoReq2010® pretende proporcionar una serie de requerimientos para un sistema de registro de documentos, comprensible, pero sencilla y facil de entender, que sea adaptable y aplicable a información y actividades divergentes, sectores comerciales y tipos de organizaciones variados. El Modelo evita la implementación de una metodología “única” para la gestión de documentos al establecer una definición de una serie común de servicios centrales que son compartidos por muchos tipos diferentes de sistemas de registro, pero que a la vez son modulares y flexibles permitiéndoles la incorporación a aplicaciones altamente especializadas que pudieron no haber sido reconocidas con anterioridad, como sistemas de registro de documentos.

El proposito de esta publicacion, es el de describir las funciones de un sistema de registro de documentos compatibles con MoReq2010® minimas requeridas, para definir los procesos comunes. Tales como exportacion y eliminacion, asi como establecer y estandarizar un modelo de información fundamental que incluya los tipos de entidad, la estructura de los datos y las definiciones de la función y del elemento de los metadatos. Donde sea implementado completamente, proporcionara confiabilidad y soporte a la interoperabilidad del sistema de documentos, incluyendo la transferencia y la migración exitosa de documentos en ciclo medio de vida, entre soluciones de compatibilidad diferentemente implementadas provenientes del mismo o de diferentes proveedores.

La funcionalidad descrita por la especificacion MoReq2010® propone una construcción basada en una serie de módulos que cubren temas tanto genéricos como específicos que serán desarrollados en los próximos meses y años bajo la dirección de la mesa directiva de DLM Forum de MoReq, para cubrir con las necesidades y demandas de los diferentes mercados,


MoReq2010® – Volume 1 – Core Services & Plug-In Modules of 520industrias, países y regiones.



Una guía adicional será elaborada por la mesa directiva de MoReq que incluya información adicional sobre la compatibilidad para aquellos consumidores que deseen actualizarse desde MoReq2

® a MoReq2010®.

1.2.2 Audiencia

Esta especificacion puede ser utilizada de diferentes formas incluyendo:

Por comerciantes:

• Como una ayuda en la implementación de un sistema para el registro de documentos;• Como herramienta practica de ayuda a las organizaciones en la configuración de sus

sistemas de registro para cumplir con sus obligaciones legales y comerciales: y • Como guía para el seguimiento a la implementación de un sistema de registro de documentos

existente.

Por expertos:

• Como documento de referencia para cursos de capacitación y la preparación de material instruccional:

• Como recurso de enseñanza para instituciones académicas; y• Como un ejemplo de la forma como los modelos tradicionales de gestión de documentos y las

ciencias archivísticas, pueden aplicarse a los requerimientos de los sistemas modernos.

Por la industria:

• Para guiar el desarrollo de sistemas de registro de documentos por parte de los proveedores; • Para integrar los sistemas de registro de documentos con otros sistemas comerciales; y • Como fuente oficial en la evaluación y certificación de soluciones de compatibidad por centros evaluadores acreditados.

Por usuarios:

• Como fuente clara de consulta basada en el usuario e introducción en la implementación de sistemas para el registro de documentos;

• Como documento original para todas las traducciones; y• Como glosario de referencia de términos en la gestión de documentos y su significado.

1.2.3 Buena practica

MoReq2010® es mejor utilizado al interior de las organizaciones de consumidores como parte de una política predominante de gestión de documentos, dentro de un marco estratégico muy bien desarrollado. Tan importante como la automatización e integración de un sistema de registro de documentos en un ambiente comercial, son la capacitación a los usuarios, la motivación para la adopción, el apoyo a la cultura corporativa de buena práctica alrededor de los documentos y la información, la concientización sobre los requerimientos para el manejo de la información, el énfasis dentro del personal, en cualquier nivel, acerca de consideraciones importantes como seguridad, privacidad, sensibilidad de datos, libertad de información e iniciativas de apertura de datos; así como para ofrecer un manual práctico y claro de procedimientos, acompañado de revisiones de certificación de calidad.

La implementación de una buena gestión de documentos requiere planeación, anticipación de los asuntos que puedan surgir, y el desarrollo y ejecución de políticas y procedimientos organizacionales que aclaren qué documentos deberían ser guardador, cómo son creados y capturados dichos documentos; cómo se mantienen, manejan y accesan a través de su ciclo



activo de vida; y todos los aspectos para su eventual eliminación. Esta planeación anticipada requiere sobrepasar los límites de cualquier tecnología o sistema de solución y considerar la pregunta de ¿cómo migrarán los documentos al siguiente sistema corporativo, con el mismo valor y características inherentes, y cómo asegurar su captura en el sistema actual de registros?

Dentro de un ambiente así, la adopción y uso de sistemas compatibles de MoReq2010® , puede ser una inversión invaluable.

1.3 Antecedentes

1.3.1 MoReq®

La primera especificación MoReq® fue publicada en el 2001 como resultado de una cercana cooperación entre el DLM Forum y la Comisión Europea (European Commission). MoReq® proporcionó una nueva especificación pana-europea para sistemas de computación que gestionan documentos electrónicos. Antes de esta publicación, solo existían en Europa algunos pocos países con sus estándares propios para la gestión de documentos.

Aún desde sus inicios, MoReq®siempre ha tenido las siguientes características:

• Alcance y aplicación universal – MoReq® es una especificación internacional y ha sido utilizado y adoptado a lo largo de un gran número de países, incluyendo algunos fuera de Europa;

• Disponible en muchos idiomas – MoReq® y su sucesor MoReq2® han sido

traducidos completamente a mas de una docena de idiomas europeos y no europeos; y

• Estandarización de hecho – aunque fue concebido originalmente como una especificación y no como un estándar impuesto, MoReq®es ampliamente reconocido como un estándar industrial de hecho, debido a su aplicación universal, disponibilidad y facilidad para su adopción.

“MoReq” fue inicialmente utilizado como una abreviación para “Modelo de Requisitos” y originalmente se pensó que la especificación proporcionaría una serie de requerimientos que luego serian modificados para cumplir con las necesidades particulares. Sin embargo, la primera edición contenía una guía sobre la manera de agregar, editar y borrar capítulos y requerimientos, y manejar asuntos como las referencias cruzadas dentro de la especificación.

1.3.2 MoReq2®

En el año 2005, la Fundación DLM Forum® terminó un estudio destinado a actualizar y ampliar la especificación MoReq®original. El resultado de este trabajo fue el desarrollo de MoReq2® y su publicación a comienzos de 2008.Un aspecto fundamental de MoReq2® fue la inclusión por primera vez de un régimen de evaluación y certificación. Los proveedores ahora pueden tener sus modelos revisados en el centro de evaluación de MoReq2® y recibir una certificación independiente de que sus productos cumplen con la especificación.

En diciembre de 2008, en su conferencia trianual en Toulouse, el DLM Forum® nombró un subcomité permanente llamado Concejo Directivo de MoReq. El papel del concejo directivo es el de manejar todos los aspectos de la especificación MoReq® incluyendo:

• Proporcionar una hoja de ruta para el mantenimiento posterior de MoReq® , y planear la



futura actualización de la especificación; • Dirigir el programa de traducción, organizar la validación de traducciones

aceptadas, y proporcionar una guía a los traductores de MoReq®;

• Otorgar la acreditación a centros evaluadores reconocidos para que emprendan pruebas de software comparativas con la especificación;

• Supervisar la evaluación y certificación de productos de software contra MoReq®por parte de centros evaluadores acreditados;

• Presentar un programa educativo paralelo que incluya talleres y cursos que elaboren guía suplementaria y material educativo; y

• Comercializar activamente la especificación, recoger estudio de casos especiales y motivar la adopción mientras se proteje simultáneamente la marca de MoReq®

1.3.3 Hoja de ruta de MoReq®

En el 2009, el Concejo Directivo de MoReq elaboró una hoja de ruta para MoReq®, que subsecuentemente fue adoptada por la resolución del DLM Forum, en una reunión de miembros en Härnösand, Suecia en noviembre de ese año.

La hoja de ruta, una imagen de la cual se presenta en la Figura 1a, identificaba que mientras la especificación de MoReq® era ampliamente reconocida por la industria como que cumplía con los requisitos para la gestión de documentos, algunos dominios como Sistemas de Gestión de Documentos y documentos electrónicos (SGDE), así como Gestión de Contenidos Empresariales (GCE), eran vistos como menos factibles de adoptar en algunas áreas como las médicas, farmacéuticas, legales y de servicios financieros donde lo usual eran aplicaciones especializadas que resolvieran problemas específicos del dominio.



Figura 1a – La hoja de ruta del Concejo Directivo de MoReq (circa 2009)

Otra tendencia identificada por el Concejo Directivo de MoReq, fue la heterogeneidad creciente en el diseño del sistema de documentos. Conceptualmente, MoReq® se basó originalmente en un modelo de repositorio simple centralizado, donde un sistema de documentos independientes de una organización, capturarían los registros dentro de su propio almacén de datos desde una variedad de fuentes externas, que incluirían a los usuarios y a otros sistemas comerciales. Esta arquitectura tradicional se muestra en la Figura 1b.

Figura 1b – La arquitectura “tradicional” de un sistema de documentos incluye la captura de documentos desde otros sistemas y manejos centralizados en un

repositorio controlado por el sistema de documentos



La hoja de ruta del concejo directivo reconoce una adopción expandida de arquitecturas alternativas. Un modelo emergente, se muestra en la Figura 1c, ilustra el sistema de documentos in situ dentro del sistema comercial en el cual se originaron, en lugar de duplicarlos dentro de su propio repositorio centralizado.

Figura 1c – Una arquitectura alternativa maneja los documentos en el lugar, permitiendo al sistema de documentos aplicar controles y procesos a los documentos

que han sido declarados in situ

Otra posible arquitectura es la adopción de controles de documentos por el mismo sistema comercial. Dicho sistema comercial es, es efecto, simultáneamente un sistema de documentos que gestiona únicamente la serie específica de documentos capturados o generados por ese sistema. Este modelo se muestra en la Figura 1d.

Figura 1d –Mientras los controles y procesos para el manejo de documentos se simplifican, flexibilizan y se entienden mejor, es cada vez más posible que los sistemas comerciales se conviertan en sistemas de documentos, al menos para los documentos

que ellos mismos producen

1.3.4 MoReq2010®

Además de la innovación al interior de la misma especificación, el DLM Forum® decidió incorporar dos fases de consulta pública dentro del desarrollo de la nueva especificación, mientras que la Comisión Europea nombraba un Grupo de Revisores Expertos. Se abrió una fase de consulta pública para el desarrollo del programa. La especificación resultante se benefició al ser desarrollada y discutida de forma abierta.



Hoy, la gestión de documentos puede ser un proceso complejo y MoReq2010®, con su arquitectura flexible y extensible, proporciona un modelo posible para superar las dificultades al especificar la implementación de un sistema de documentos atractiva y adecuada para los proveedores, practicantes y consumidores.

El año 2011 marca el 15 aniversario del DLM Forum® y el 10 aniversario de MoReq® .

1.4 Generalidades

1.4.1 Documentos e información

Cada organización y cada ciudadano tiene y usa documentos.

Los documentos son aquellas piezas de información que tienen un valor intrínseco el cual los hace lo suficientemente importantes para ser guardados y conservados con seguridad, por su valor probatorio.

La mayoría de las personas, por ejemplo, tiene diferentes documentos en su posesión, los cuales guardan como prueba de su identidad. Algunos de ellos pueden ser:

• Certificado de nacimiento,

• Pasaporte

• Licencia de conducción, y/o

• Documento de identidad

En cada uno de los ejemplos anteriores la importancia de los documentos y su naturaleza probatoria es obvia. Sin embargo, este no puede ser siempre el caso. La gente frecuentemente no considera todas las piezas de información que tiene en su posesión necesariamente como documentos.

Por ejemplo, una lista de compras puede no ser considerada como un documento, a diferencia del recibo de la tienda, donde los productos de la lista fueron adquiridos, que proporciona prueba de la compra y pueden ser considerados como documentos, si son importantes para un individuo o negocio.

Dicho recibo podría ser usado para reclamar por los gastos por parte del empleador, o para recibir un reembolso al retornar artículos dañados o estropeados. Este ejemplo es ilustrado en la Figura 1e.



Figura 1e. Uno de estos probablemtente no es un documento… ¿el otro lo puede ser?

La diferencia entre información y documentos es la misma tanto para las organizaciones como para los individuos, por lo tanto para cada organización se puede decir que su conjunto de documentos es un subconjunto del conjunto de los activos de su información, mostrado conceptualmente como un diagrama de Venn en la Figura 1f.1

Figura 1f – Los documentos son un sub-conjunto de toda la información poseída por una persona o una organización.

Para poder decidir si una pieza de información es un documento o no, debe ser entendido su contexto comercial al igual que su relevancia y significancia para la organización. Por lo tanto, una tarea importante para cualquier organización, es la de adquirir un entendimiento de su negocio y poder usar este entendimiento para evaluar qué información requiere ser conservada y administrada como documentos propios.

1 Information= información. Records= documentos



Los activos de la información que pertenecen a una organización, pero no son considerados como documentos, como los borradores de un documento, o una transacción incompleta, deben ser considerados temporales y deben ser eliminados frecuentemente. Por ejemplo, borradores intermedios pueden ser borrados cuando un documento es publicado, e información parcial de transacciones puede ser borrada cuando la transacción sea completada o cancelada.

Fallar al eliminar información temporal puede, en el mejor de los casos, desperdiciar la capacidad de almacenamiento de datos de una organización con copias redundantes o incompletas y desperdiciar tiempo del personal clasificando qué información está completa y correcta y cual no lo está. En el peor de los casos, puede causar violación en la privacidad u otras regulaciones, o conducir a costosos ejercicios compilando la información si esta es requerida como parte de una acción legal, una petición de la libertad de la información, o semejantes.

1.4.2 Procesos y sistemas de gestión de documentos

ISO 15489, publicado en el 2001, es quizás el estándar más influyente en la gestión de documentos internacionalmente. Determinar la información que debe ser administrada como documentos es solamente el primero de los procesos de gestión que este identifica. La lista completa de procesos de gestión de documentos identificada por ISO 15489 incluye, adicionalmente:

• Determinar por cuánto tiempo se mantienen documentos;

• Crear y registrar documentos;

• Clasificación de documentos;

• Almacenamiento y manejo de documentos;

• Controlar acceso a documentos;

• Rastreo de documentos;

• Eliminación de documentos; y

• Documentar procesos de gestión de documentos.

ISO 15489 propone que una organización debe usar un sistema de documentos para implementar estos procesos. Este define un sistema de documentos como un “sistema de información que captura, gestiona y provee acceso a documentos a través del tiempo” (ISO 15489-1:2001, 3.17).

MoReq2010® es una especificación para definir un sistema de documentos expresado como un conjunto modular de requerimientos. Esta va más allá de una descripción general ofrecida por ISO 15489 y agrega un nivel más grande de especificad en cómo estos procesos deben ser llevados a cabo. Lograr una conformidad a MoReq2010® requiere un mayor grado de rigor que puede ser logrado simplemente creando un sistema de documentos que maneje los procesos de gestión de documentos descritos por ISO 15489 en su forma de propiedad exclusiva.



Una de sus ventajas, y un objetivo de diseño de MoReq2010®, es el potencial para la interoperabilidad entre los Sistemas de Documentos Compatibles con MoReq2010® (SDCM). Un SDCM no sólo entiende sus propias entidades y procesos, este puede exportarlos a un formato estandarizado que puede ser entendido por otro SDCM.

La interoperabilidad es esencial para la gestión de documentos al usar un sistema de documentos. Las organizaciones del hoy por hoy usualmente actualizan su tecnología cada tres a cinco años. Los documentos suelen ser conservados por mucho más tiempo que eso. Si una organización tiene la necesidad de mantener un documento particular durante 75 años, luego, al final de ese periodo, el documento puede haber sido transferido de un sistema de registro a otro de 15 a 25 veces. Esto se ilustra en la Figura 1g. Si con cada transferencia se obtiene perdida de la información contextual acerca del documento, entonces este número de transferencias puede tener un fuerte impacto en la integridad del documento.2

Figura1g– Los documentos pueden ser transferidos múltiples veces entre sistemas de registro durante su período de vida.

Debe anotarse que la importación no es parte de los servicios básicos de un SDCM3, pero que todo SDCM debe ser capaz de exportar su información al formato común XML de exportación de MoReq2010®. La importación requiere un nivel mucho más alto de sofisticación de la aplicación que la exportación, y permitir esto para todos los sistemas de documentos evitaría que muchos sistemas comerciales adoptaran MoReq2010®.

1.4.3 La naturaleza de los documentos

Casi todo lo que contiene información de valor probatorio puede gestionarse como un documento. ISO 15489 define formalmente un documento como, “información creada, recibida y mantenida como evidencia e información por una organización o persona, en cumplimiento de obligaciones legales o en las transacciones de negocios” (ISO 15489-1:2001, 3.15).

En el pasado, los documentos fueron en su mayoría a base de papel, pero durante el Siglo 21 están siendo implacablemente remplazados por el incremento exponencial de la información electrónica. Sin embargo, la necesidad de sistemas que manejen documentos físicos siempre existirá, tanto para documentos en papel como en físico, por ejemplo, para rastrear muestras forenses o bio-médicas.

2 Record created= documento creado. Record transferred= documento transferido. Records system= sistema de documentos.3 SDCM = Sistemas de Documentos Compatibles con MoReq2010



Todos los documentos, incluyendo los físicos como los electrónicos, tienen ciertas características. ISO 15489 enuncia las características esenciales de un documento como:

• Autenticidad- El documento es lo que pretende ser y fue creado por la persona que pretendía haberlo creado;

• Confiabilidad- La información en el documento es exacta y confiable.

• Integridad –El documento es completo e inalterado, y

• Uso – El documento puede ser localizado, recuperado, presentado e interpretado.

Un SDCM solo puede asegurar estas características desde el momento en el cuál el documento es creado en el sistema de documentos. Como lo afirmó ISO 15489, “Los documentos deben ser creados al mismo tiempo que la transacción o incidente al cual se relacionan, o poco después, por individuos que tengan directo conocimiento de los hechos o por los instrumentos usados rutinariamente en el negocio para llevar a cabo la transacción.” (ISO 15489, 7.2.3).

Esta declaración indica dos formas en las cuales los documentos pueden ser creados, ya sea: • Creados por un individuo; o

• Creados por un instrumento.

En MoReq2010® tanto los humanos como los sistemas comerciales son considerados como posibles “usuarios” de un sistema de documentos y pueden ser autorizados para crear documentos. Un SDCM puede ser desarrollado para interrelacionarse solo con usuarios humanos, con otros sistemas comerciales, o con ambos.

Además de las características mencionadas previamente, todos los documentos en un sistema de documentos deben tener metadatos asociados a ellos. Los metadatos son definidos por ISO 15489 como, “ Datos que describen el contexto, contenido y estructura de los documentos y su gestión a través del tiempo” (ISO 15489-1: 2001, 3.12).

1.4.4 Entidades y servicios

Un sistema de documentos compatibles con MoReq2010® gestiona documentos como entidades. Los documentos son solo uno de los tipos de entidades definidas por la especificación. Además de los documentos, MoReq2010® también define otro número de entidades de diferente tipo. Por ejemplo, MoReq2010® define un tipo de entidad de usuario que representa los usuarios que acceden a los sistemas de documentos, y un tipo de clase de entidad para cada entrada en el esquema de clasificación del sistema, y así sucesivamente. Una lista completa de entidades puede ser encontrada en 14.2 Tipos de Entidades.

Aunque las entidades administradas por un SDCM son de diferente tipo, MoReq2010® intenta hacerlas tan uniformes como sea posible de una forma en la que sus metadatos sean representados y su historia de eventos sea manejada, en sus controles de accesos y en el ciclo de vida de la identidad. A diferencia de las entidades en otros sistemas de información, las entidades en un SDCM son destruidas, en lugar de borradas, dejando un rastro residual que permanece en el SDCM. Las entidades residuales son un concepto importante en los sistemas de documentos ya que ellas indican que alguna vez estuvieron presentes en el sistema. Sin ellas, no sería posible reconstruir el pleno contexto de un documento histórico.



Dentro de un SDCM, las entidades de diferentes tipos son descritas nominalmente como siendo administradas por diferentes servicios de acuerdo a “arquitectura basada en servicio” (ver 2. Servicios del Sistema):

• Un usuario y grupo de servicio administra entidades de usuarios y grupos de entidades (ver 3. Servicio a usuarios y a grupos

• Una función de servicio administra roles (ver 4. Modelo de Servicio del Rol);

• Un servicio de clasificación maneja clases (ver 5. Servicio de Clasificación);

• Un servicio de documento administra documentos y agrupacioneses de documentos (ver 6. Servicio del Documento);

• Un servicio de metadatos administra metadatos y plantillas de metadatos (ver 7.Modelo de Servicio de los Metadatos);

• Un servicio de programación de eliminación administra los horarios de eliminación (ver 8. Servicio de Programación de Eliminación); y

• Un servicio de mantenimiento de eliminaciones administra las reservas de los residuos (ver 9. Servicio de Retención de la Eliminación).

Otros servicios son puramente basados en procesos y no gestionan entidades, incluyendo:

• Un servicio de búsqueda y reportes (ver 10. Servicio de Búsqueda y Reportes),y

• Un servicio de exportación (ver 11. Servicio de Exportación).

Mientras que este usa el lenguaje, y promueve la adopción, de un arquitectura basada en el servicio, MoReq2010® reconoce que históricamente los sistemas de documentos no han necesariamente entregado funcionalidad usando un modelo de servicio discreto. Por esta razón, MoReq2010® no hace más que simplemente encerrar sus requerimientos funcionales en servicios lógicos y probarlos en cada “servicio” (paquete) de requerimientos funcionales individualmente. Un SDCM que no proporciona servicios discretos en su implementación seguirá siendo certificado como compatible con la especificacion MoReq2010®.

Sin embargo, el enfoque tomado por MoReq2010® es deliberado y anticipa un futuro donde la interoperabilidad no está limitada a la transferencia de documentos de un SDCM a otro, pero donde los diferentes sistemas de documentos pueden compartir los mismos servicios en común. Dentro de una organización del futuro, puede ser posible para todos los sistemas de documentos hacer uso de un único usuario y servicio de grupo, un único servicio de rol, un único servicio de programación de eliminación y/o un único servicio de búsqueda y reporte.

Tal enfoque permitiría, por ejemplo, un esquema comercial de clasificación para ser definido una vez a través de la totalidad de la organización y gestionado centralmente usando un servicio de clasificación compartido, como se aprecia en la Figura 1h. Lo mismo aplica igualmente para otros servicios.4

4 Central Classification Service= Servicio Centralizado de Clasificación.



Figura 1h – En el futuro diversos sistemas de documentos serán capaces de compartir un único y centralizado servicio de clasificación

La utilización de servicios compartidos no estará necesariamente confinada a los límites dentro de una única organización. Por ejemplo, un regulador puede expedir y mantener un conjunto estandarizado de programación de eliminación para ser usado por todas las organizaciones en un sector particular, organizándolo como un servicio ampliamente accesible de programación de eliminación, o un servicio de retención de la eliminación compartidos entre litigantes, puede administrar el proceso de eliminación solicitado por una corte legal en particular.

1.4.5 Clasificación y agrupación

Existen muchos otros conceptos que son nuevos en MoReq2010®. Uno de ellos es la distinción hecha entre clasificación y agrupación. ISO 15489 define clasificación como “la identificación y los convenios sistemáticos de actividades comerciales y/o documentos en categorías, de acuerdo a convenciones lógicamente estructuradas, métodos, y reglas procedimentales representadas en un sistema de clasificación” (ISO 15489-1:2001, 3.5).

Mientras que a la clasificación le concierne proveer el contexto comercial para un documento y establecer la relación entre un documento y la actividad transaccional por la cual fue creado, la agrupación describe la actividad de colocar juntos documentos relacionados. A diferencia de la clasificación, la agrupación puede tener como base cualquier criterio o requerimiento organizacional, en lugar de únicamente un contexto comercial. Un servicio completo de documento podría decirse que se considera que representa un nivel alto de agrupación.

Históricamente, algunas especificaciones para la gestión de documentos unen un esquema de clasificación jerárquica sobre una capa de agrupación de forma que un documento siempre hereda su clase por su agrupación. Este enfoque ilustrado en la Figura 1i, utiliza clases en lugar de niveles altos de agrupación. Dicha organización, mientras que es conveniente por su simplicidad, si puede ser alcanzada, también es flexible y no siempre se presta para el uso en el mundo real. Las restricciones que este enfoque impone han llevado en muchos casos a que elementos basados en sujetos y en organizaciones se unan en un esquema de clasificación funcional de negocios a crear un híbrido localizado.5

5 Aggregation= agrupación. Relationship= relación. Record= documento. Class= clase.



Figura 1i –Un modelo tradicional jerárquico de clasificación y agrupación, donde tanto las clases como las agrupaciones están unificadas en una única estructura (este enfoque puede ser implementado por un SDCM, pero MoReq2010®

siempre permite una flexibilidad mayor)

Muchas organizaciones emprenden trabajo colaborativo, trabajo de casos o trabajo basado en proyecto. Donde estas actividades ocurren, la tendencia natural dentro de las organizaciones es a agrupar documentos con base en el tema principal, tales como el proyecto particular, y no basados únicamente en la actividad comercial o los procesos que crearon el documento.

Por ejemplo, una pequeña asociación puede almacenar documentos por cada uno de sus miembros en una única agrupación por miembro. En cada agrupación de miembro se podría encontrar:

• El formulario original de registro, valoración y aprobación,

• Detalles de identificación, bancarios y de contacto incluyendo varias notificaciones de cambio,

• Subscripciones anuales y renovaciones de membresías,

• Solicitudes, citas y cargos tenidos dentro de la asociación,

• Correspondencia, y diversa información sobre varias actividades de la asociación emprendidas por el miembro,

• Reclamos de gastos y reembolsos,

• Contratos, certificados, documentos legales y renuncias,

• Etc.



En este ejemplo, los documentos en la agrupación del miembro se relacionan con diferentes funciones, actividades y transacciones y deben por lo tanto, conllevar a clasificaciones comerciales diferentes. Pueden existir razones legales, regulatorias o por buenas prácticas basadas en las clasificaciones de por qué algunos documentos en cada agrupación de un miembro, deben ser conservadas por un período estatutario relativamente largo, mientras otros documentos en la agrupación solamente deben ser conservados por un período corto y luego destruidos.

Un acuerdo como este, aunque es muy común, es difícil de catalogar en una clasificación jerárquica tradicional basada en estructura como se muestra en la Figura 1i. Esto es porque en los acuerdos tradicionales, la agrupación completa del miembro, debe encajar en una única clase en el esquema de clasficación.

Como resultado, existe inevitablemente una tensión creada entre la eficacia práctica y operacional y las necesidades administrativas de los documentos. O el esquema de clasificación es hibridado, como por ejemplo introduciendo clasificaciones generales como “trabajo de caso”, “clientes”, “proyectos”, “personal”, y “eventos”; o naturalmente ocurre que las agrupaciones son separadas, por ejemplo, los registros de documentos para todos los miembros pueden encontrarse juntos bajo una única clasificación/agrupación como “formulario de membresía”, mientras los documentos de subscripciones anuales para todos los miembros son recogidos en una clasificación/agrupación totalmente separada, como “Renovaciones de membresías 2011”. Ningún compromiso puede ser visto enteramente como satisfactorio.

Al proveer una clara distinción entre los conceptos relacionados a clasificación y agrupación, MoReq2010® permite una flexibilidad más amplia al hacer decisiones planificadas en conservar documentos juntos, combinados con qué esquema de clasificación a usar y cómo aplicarlo. Esto hace de MoReq2010® más adaptable a situaciones del mundo real. La especificación permite las agrupaciones, incluyendo incluso las clases de asociación con documentos individualmente si se requiere (esto se muestra en la Figura 5d y se discute posteriormente en 5. Servicio de Clasificación). Al mismo tiempo, la compatibilidad de versiones anteriores con el enfoque tradicional mostrado en la Figura 1i se mantiene.

1.4.6 Retención y eliminación

MoReq2010® asocia cercanamente la clasificación comercial con la retención y eliminación, así cada clase tiene una programación de eliminación asociada y cada documento hereda su programación de eliminación, por defecto, de su clase, adoptando el principio “la clasificación determina el destino”. Esto es diferente a algunos enfoques donde las programaciones de eliminación son heredadas de la agrupación de un documento y solo indirectamente de su clasificación.

Una característica significativa de la programación de eliminación es que MoReq2010® no le permite a un documento estar sujeto a más de una programación de eliminación simultáneamente. La especificación permite a la programación de eliminación por defecto, heredada de la clase de documento, ser anulada, pero en algún punto solo una programación de eliminación puede aplicar a un documento particular. Por lo tanto no existe una oportunidad para que ocurra un conflicto de eliminación en la que se requiera la intervención directa de un usuario para resolverlo.

Como cada documento en una agrupación puede tener una clasificación diferente para otros



documentos, y cada documento puede también tener su propia programación de eliminación heredada de su clase, es posible que documentos individuales en una agrupación esten programados para su eliminación en momentos diferentes. Esto es determinado por la programación de eliminación que la organización use y los dispositivos de eliminación que estén especificados.

MoReq2010® utiliza el principio de destrucción ascendente para disponer de una agrupación, solo cuando todo su contenido ha sido destruido y la agrupación se ha cerrado. La destrucción ascendente es descrita en mayor detalle en 8.2.9. Una de las ventajas de la destrucción ascendente es que no requiere que las agrupaciones tengan programaciones de eliminación. Sólo hay un tipo de programación de eliminación en MoReq2010®, el cual está relacionado al documento.

Aun cuando MoReq2010® aplica una eliminación individualmente a cada documento, es posible aplicar la misma acción de eliminación a varios documentos simultáneamente. Por ejemplo, MoReq2010® posibilita al usuario a autorizar la misma acción de eliminación una vez para una agrupación en su conjunto. Esto facilita el uso mientras mantiene un enfoque simple y flexible a la retención y eliminación.

1.4.7 Historias de evento y auditoría

ISO 15489 requiere el uso de metadatos, o alternativamente de pistas de auditoría para ser conservados como “representaciones completas y exactas de todas las transacciones que ocurren en relación a un documento particular” (ISO 15489-1: 2001,8.3.2). MoReq2010® adopta este enfoque pero lo extiende al acoger el concepto de una historia de evento para cada documento de ISO 23081.

ISO 23081, un estándar internacional de metadatos para documentos, describe una historia de evento así: “La historia de los eventos de los documentos de un grupo de metadatos, sus eventos de registros pasados y otros eventos de gestión tanto en la entidad como en sus metadatos. Para cada evento especifica el tipo de evento, lo que paso, cuándo sucedió, por qué ocurrió, y quien lo llevo a cabo. Los metadatos in este elemento son una secuencia que documentan un evento específico”.

En MoReq2010® cada entidad tiene un evento de historia asociado con él. Esto es particularmente importante al brindar interoperabilidad, donde las entidades son transferidas de un sistema de documentos a otro. Cada entidad es transferida como un todo, incluyendo sus metadatos, historias de eventos, controles de acceso, etc. Las historias de eventos son una parte integral de una entidad y su enfoque permite a todos los SDCM importar y entender completamente los eventos que ocurrieron a una entidad mientras esta fue parte de un sistema de documentos previos.

Aun cuando las historias de evento están vinculadas a las entidades, MoReq2010® permite una mirada a un “sistema de pista de auditoria” a través de un SDCM al permitir a los usuarios buscar a través de todos los eventos para todas las entidades y clasificarlos por el momento en el que ocurrieron. De esta forma, los eventos acumulados de todas las historias de eventos conforman la pista de auditoría para un SDCM.

Bajo MoReq2010® las historias de evento y los metadatos para las entidades, son reducidos cuando las entidades son destruidas en línea con ISO 15489, el cual afirma que las pistas de



auditoria debe ser conservadas por lo menos el mismo tiempo que el documento [ej. contenido del documento] relacionado con ellos” (ISO 15489-1:2001,8.3.2).

1.4.8 Arquitectura Modular

La Figura 1j muestra la arquitectura modular de MoReq2010®. Cada cuadro en el diagrama representa un conjunto de requerimientos que representa o un servicio, o un módulo. El núcleo de los servicios está definido en el Volumen 1 de la especificación y suministra el conjunto mínimo de funcionalidad para la compatibilidad con MoReq2010® ; o, en otras palabras, definen el SDCM más posible.

Figura 1j – La estructura de la especificación MoReq2010®

Algunas de las funcionalidades descritas por los servicios básicos pueden ser implementadas en forma alternativa, pero igualmente válidas. Cuando esto ocurre, MoReq2010® hace uso de sus módulos de integración informática. Cada módulo de integración informática representa exactamente la funcionalidad equivalente como cualquier otro módulo de inserción de las mismas series. Un SDCM debe implementar la funcionalidad descrita por lo menos en un módulo de inserción en una serie y puede elegir implementar más de un módulo de integración informática.

Los módulos de integración informática son usados por los servicios básicos para permitir la flexibilidad en áreas de funcionalidad:

• Tipo de interface – incluyendo si el SDCM es administrado directamente por usuarios a través de una interface de computador, o como un sistema de soporte comercial a través de una interface de máquina;

• Tipo de clasificación- permite un SDCM adoptar diferentes enfoques de clasificación, por ejemplo, un esquema de clasificación jerárquico; y

• Tipo de componentes de documentos – le permite a un SDCM soportar tipos diferentes de documentos, como componentes electrónicos en lugar de componentes físicos.



Los servicios básicos y módulos de integración informática descritos en el Volumen 1 de la especificación de MoReq2010® conforman la plataforma esencial en la cual diferentes módulos de extensión pueden ser organizados. El rango y la variedad de los módulos de extensión en MoReq2010, serán extensivos, y cubrirán:

• Servicios adicionales – como importar;

• Conceptos adicionales – como documentos vitales;

• Tecnologías específicas – como correos; y

• Requerimientos para sistemas de documentos para industrias particulares y jurisdicciones.

Como se muestra en la Figura 1j, los módulos de extensión pueden construir el uno al otro así como extender los servicios básicos. El prefacio de cada módulo contiene una lista de sus prerrequisitos y correquisitos.

Los prerrequisitos definen una dependencia donde los SDCM deben implementar el módulo previamente requerido así como la extensión del módulo. Los correquisitos son módulos que atraen requerimientos funcionales adicionales, si son implementados simultáneamente con el módulo de extensión.

1.4.9 Servicios del modelo

El desarrollo de MoReq2010® ha requerido compromiso entre el estado de la industria de gestión de documentos de hoy y la visión del futuro promovido por la especificación y la Junta de Gobierno de MoReq2010®. Este compromiso es particularmente evidente en dos servicios: roles y metadatos.

En el interés de interoperabilidad, MoReq2010® busca codificar ambos, los controles de acceso de una entidad y sus elementos de metadatos de forma que ellos puedan ser transferidos a nuevos sistemas de documentos donde sean exitosamente importados, entendidos y usados. Los metadatos pueden describir información contextual valiosa acerca de la entidad original, mientras que los controles de acceso, incluso cuando son sustituidos en el sistema de recepción, proveen conocimiento importante acerca de quién había tenido acceso a que documentos en el sistema de documentos original.

Ya que ninguna especificación anterior ha buscado tratar estos asuntos a través de la estandarización, los proveedores han tenido que implementar por necesidad, sus propios métodos individuales de aplicar metadatos y controles de metadatos dentro de su software de sistema de documentos. Como consecuencia, una cantidad excesiva de refactorización sería requerida dentro de estos sistemas de documentos existentes, para adoptar un modelo de metadatos o un modelos de control de acceso que fuese común a todos los SDCM.

Por esta razón, MoReq2010® especifica estos dos servicios como modelos de servicios. Un modelo de servicio en un servicio ejemplar, que pretende que sea adoptado como la forma apropiada para desarrollar nuevo software de gestión de documentos en el futuro, sin impedir que productos existentes busquen compatibilidad con, y certificación contra, MoReq2010®



MoReq2010® acepta los dos diferentes métodos para proveer compatibilidad con un modelo de servicio. El Método A está diseñado para implementar los requisitos de funcionalidad del modelo de servicio y ser probado en este. El Método B, está planeado principalmente para software preexistente, y para establecer una solución única, rica en funcionalidad como el modelo de servicio, y dónde los constructos y datos puedan ser convertidos y exportados como si se hubiesen creado en un sistema de documentos que implementa el modelo de servicio.

Este requerimiento es esencial para la compatibilidad con cualquier modelo de servicio: cuyas entidades, sus metadatos y sus controles de acceso son significativamente exportados al formato de exportación XML estándar de MoReq2010®. Si esto puede ser logrado luego otro SDCM puede importar las entidades y usarlas en conjunto con un modelo de servicio.

1.4.10 Evaluación y certificación

El Foro DLM6 ha iniciado un programa de evaluación y certificación para MoReq2010®. El programa permite a los proveedores de los sistemas de documentos comunes fuera de plataforma (COTS), así como también en sistemas de documentos caseros, ser probados por un Foro DLM acreditado por un centro de pruebas de MoReq2010®.

Los proveedores deben haber probado sus productos con los servicios básicos, y opcionalmente pueden tener cualquiera de los módulos de extensión probados también. Persiguiendo el cumplimiento satisfactorio de prueba utilizando el marco de evaluación de MoReq2010®, un producto o instalación puede ser certificado por el Foro de DLM como compatible con MoReq2010®.

Los proveedores estarán en capacidad de mostrar que sus productos están completamente certificados como compatibles con MoReq2010®, mientras que los miembros del Foro DLM se beneficiaran teniendo acceso a los reportes de evaluación, permitiéndoles levar a cabo un análisis preliminar de diferentes sistemas de documentos de compatibilidad de MoReq2010®.

El Foro DLM publicará listados de los Centros de evaluación acreditados por MoReq2010®, y listados de sistemas de documentos certificados como compatibles conMoReq2010®, en su sitio web www.dlmforum.eu.

6 Fundación sin ánimo de lucro. Foro DLM: Document Lifecycle Management =Gestión del ciclo de vida del documento.



2. Servicios del Sistema

2.1 Información del Servicio

Cada uno de los servicios básicos del SDCM (Sistema de Documentos Compatibles) de MoReq® viene definido por su nombre de servicio (por ejemplo, «Servicio a usuarios y a grupos»), su versión de servicio (por ejemplo, «1.0») y su identificador de servicio de implementación (por ejemplo, «5e69596d-5fac -4017-B204-1aeb85b004b0 »), o Instrumentos de Identificación del Módulo de integración informática (plug-in) y módulos de extensión.

Estos detalles pueden encontrarse en el bloque de información de servicios (véase, por ejemplo, 3.1). El identificador de instrumentos de servicio es, como su nombre lo indica, un identificador único universal que se utiliza internamente por un SDCM para mostrar qué servicios implementa.

Esta sección, 2. Servicios del sistema, contiene la funcionalidad común a todos los servicios básicos MoReq2010® y, como tal, no tiene información de servicio por aparte. Para cada servicio en particular, remítase al bloque de información de servicio correspondiente.

2.2 Conceptos clave

2.2.1 Arquitectura basada en servicios

Los requisitos funcionales del núcleo MoReq2010® se agrupan en nueve definiciones de servicios que se observan en la Figura 2a. En conjunto, estos servicios describen la funcionalidad que requiere un SDCM. Este primer módulo, titulado 2. Servicios del sistema, describe la función común requerida por todos los servicios básicos MoReq2010®.

La arquitectura basada en servicios de MoReq2010® no se hizo con el propósito de limitar a los proveedores de software de desarrollar soluciones compatibles que combinen y ofrezcan la funcionalidad de muchos, o incluso todos, los servicios básicos en una sola aplicación. Sin embargo, al dividir la arquitectura de MoReq2010® en distintos servicios, los proveedores para desarrollo de sistemas de registros también podrán considerar el desarrollo de sistemas de registro donde cada uno de los servicios se desvincule de los demás y pueda así compartirse entre más de un SDCM.

Por ejemplo, en el futuro cada sistema de registros dentro de una organización podrá compartir el servicio de clasificación o incluso el servicio de almacenamiento de eliminación. También será posible construir un SDCM mediante diferentes servicios de diferentes proveedores e integrarlos todos entre sí.

Sea que se ofrezca como una sola aplicación, una colección de servicios integral o no integral, todas las soluciones SDCM deben probarse atendiendo a los mismos criterios de cumplimiento.



El servicio de registro está ubicado en el centro de la arquitectura basada en servicios de SDCM. El servicio de registro es el único servicio principal que no puede ser compartido con otro SDCM. De hecho, es solo el servicio de registro lo que distingue a un SDCM de otro. Todos los demás servicios que respaldan al servicio de registro pueden apoyar otros servicios de registro al mismo tiempo, y, por lo tanto, ser parte de varias soluciones SDCM simultáneamente.

(Círculo)1. Almacenamiento de componentes2. Interfaces3. Servicio grupal y de usuario4. Servicio de modelos de rol5. Clasificación de servicios6. Registro de servicios7. Servicio modelo de metadatos8. Servicio de agenda de eliminación9. Servicio de almacenamiento de eliminación



10. Servicio de búsqueda y reporte11. Servicio de exportación(Dentro del cuadro)Servicio núcleo Componentes (no servicios)Modelo de servicio Módulos de respaldo plug-in

Figura 2a - Un sistema de documentos compatibles MoReq2010® (SDCM) visto como un conjunto de servicios relacionados entre sí con arquitectura basada en servicios (cada

servicio básico tiene su propia sección numerada de especificación)

2.2.2 Servicios del modelo y módulos de integración informática

Dos de los servicios básicos de MoReq2010® son servicios de modelo (estos son 4. Servicios modelo de rol y 7. Servicio modelo de metadatos). Esto significa que mientras que la especificación proporciona un conjunto predeterminado de requisitos funcionales para cada uno de estos servicios, MoReq2010® no exige a los proveedores estos servicios tal y como están previstos para implementarse, salvo que el proveedor desee apoyar los módulos avanzados, como el de importación .

También hay tres áreas dentro de los servicios esenciales en las que se especifica la funcionalidad del módulolo de integración informática (plug-in). Los módulos plug-in representan conjuntos de funcionalidad alternativas, pero igualmente válidas, que permiten alcanzar el mismo objetivo pero de diferentes maneras. Los proveedores pueden elegir libremente qué enfoque adoptar. Cada SDCM debe proporcionar apoyo por lo menos para una aplicación de la funcionalidad, (así como debe estar certificado en contra de al menos una funcionalidad). Asimismo podrá apoyar y estar certificado contra otros módulos plug-in alternativos en la misma serie. La interface para el SDCM es un ejemplo de un área en la que se especifica la funcionalidad plug-in.

2.2.3 Comunicación con los usuarios

MoReq2010® no requiere que los usuarios siempre interactúen directamente en la interface con sistemas de registro.

En las implementaciones tradicionales de sistemas de registro, los usuarios interactúan directamente con el sistema de registros a través de una interface gráfica de usuario (IGU)7, que se ilustra conceptualmente en la Figura 2b.

Figura 2b – Usuario interactuando directamente con un sistema de registro a través de una interface gráfica de usuario (IGU)

Cada vez más los sistemas de registros se están desarrollando para apoyar a uno o varios sistemas de negocio distintos. Estos sistemas de registro no proporcionan una interface gráfica de usuario, sino que interactúan directamente con los sistemas de negocio mediante una interface de aplicación de programacion (IAP). En este escenario, ilustrado en la Figura 2c, el usuario realiza las funciones en el sistema de registros sólo de forma indirecta, como resultado

7 GUI: Graphic User Interface = Interface gráfica de usuario



de las acciones del usuario en el sistema de negocios. El usuario puede que incluso no llegue a darse cuenta de la existencia de un sistema de registros aparte.

Sistema Interface de aplicacion SDCM comercial de programacion

Figura 2c – Usuario interactuando indirectamente con un sistema de registro a través de una IAP

MoReq2010® ofrece soporte para ambos tipos de sistema de registros al permitir que un SDCM especifique qué tipo de interface soporta. Un SDCM también puede soportar más de un tipo de interface al mismo tiempo. Del mismo modo, cada uno de los servicios básicos de MoReq2010® puede apoyar una opción de interface distinta. Por ejemplo, el sistema de usuarios y grupos pueden ofrecer una IPA, mientras que el sistema de búsqueda y elaboración de informes ofrece una interface gráfica de usuario.

Al usar MoReq2010® es importante tener en cuenta que el usuario de un SDCM no necesariamente es una persona. En su lugar, el usuario autorizado puede ser un sistema comercial.

2.2.4 Tipos y sub tipos de la entidad

Cada servicio básico MoReq2010® gestiona las entidades pertenecientes a un determinado número de tipos de entidad. Los servicios básicos MoReq2010® refieren a los siguientes tipos de entidad:

• Listas de control de acceso, que se define en 4. Servicios de modelo de rol;• Agrupacioneses, que se define en 6. Servicio de registro;• Clases, que se define en 5. Servicio de Clasificación;• Componentes, que se define en 6. Servicio de registro;• Almacenamiento de eliminación, definido en 9. Servicio de almacenamiento de eliminación;• Agenda de eliminación, se define en 8. Servicio de agenda de eliminación;• Tipos de entidad, que se definen en 2. Servicios del sistema;• Eventos, definidos en 2. Servicios del sistema;• Definiciones de función, definidas en 2. Servicios del sistema;• Grupos, que se definen en 3. Servicios de usuario y de grupo;• Las definiciones de elementos de metadatos, que se definen en 7. Modelo de servicio de metadatos;• El registro, que se define en 6. Servicio de registro;• Los roles, definidos en 4. Servicios de modelo de rol;• Servicios, que se definen en 2. Sistema de Servicios y• los usuarios, definidos en 3. Servicios a usuario y a grupos.

Los cuadros con los atributos de cada uno de estos tipos de entidad pueden encontrarse en



14,2 Tipos de Entidad.

Las listas de control de acceso y los eventos se muestran arriba con otros tipos de entidades, aunque estas no sean entidades independientes. Todas las entidades excepto las listas de control de acceso y los eventos tendrán un historial de eventos asociado, que consiste en una serie de eventos y una lista de control de acceso, que a su vez consiste de una serie de entradas de control de acceso.

Los tipos de entidad gestionada por cada servicio se encuentran enumerados en 1.4.4 Entidades y servicios y en la fundamentación R2.4.9. Por ejemplo, el servicio de registro gestiona agrupacioneses, registros y componentes, mientras que el servicio de agenda de eliminación los horarios para dicho proceso. Cuando los servicios no están separados lógicamente dentro de un SDCM, entonces tienen que gestionarse colectivamente las entidades que pertenecen a todos los tipos de entidad MoReq2010®.

MoReq2010®

permite tipos sub-especializados de cada entidad, por ejemplo las definiciones de elementos de meta datos se dividen en:

• Definiciones de elementos en sistemas de meta datos. • Definiciones de elementos contextuales de meta datos.

MoReq2010 ® permite subtipos especializados para cada clase de entidad. Por ejemplo, las definiciones de elementos de metadatos se dividen en:

• Sistema de definiciones de elementos de metadatos, y

• definiciones contextuales de elementos de metadatos.

Cada uno de estos es un subtipo de la entidad base: Definición de tipo de elemento de metadatos. Los subtipos se caracterizan por tener elementos adicionales de metadatos del sistema en comparación con el tipo de entidad de base, y por las normas adicionales de comportamiento especificado por los requisitos.

Algunos tipos de entidades dentro de los servicios básicos MoReq2010® son intencionalmente diseñados para ser un tipo base para la entidad sub-tipos. Adicionalmente a estas definiciones de elementos de metadatos, están:

• Clases - la clase sub-tipos son definidos por los diferentes módulos en el MoReq2010®, 200. series de clasificación, y

• Componentes - componente subtipos son definidos por diferentes módulos plug-in en el

MoReq2010®, 300. Componente de la serie.

Una Clase Jerárquica, definida en el 201. Clasificación Jerárquica del módulo de integración informática, es un ejemplo de un sub tipo del tipo de entidad Clase. Un Componente Electrónico definido por el 301. Componentes electrónicos del módulo de integración informática, es un ejemplo de un sub tipo del tipo de entidad Componente.

Los módulos de extención para MoReq2010®

pueden agregar nuevos tipos y subtipos de entidad.



2.2.5 Anatomía de una entidad.

La mayoría de entidades tienen tres grupos de información asociados con ellos, mostrados en la Figura 2d:

• Metadatos – Información que describe la entidad, contenida en las definiciones de elementos de metadatos, y dividida dentro del sistema de metadatos. (Definido por MoReq2010

®)y contextualización de metadatos (definido por el proveedor y/o por el

usuario); • Historial de eventos: Un conjunto de eventos, asociados con la entidad, que almacena información acerca de diferentes funciones que han sido realizadas en la entidad; y• Lista de control de acceso: Una lista de acceso de control entra especificando que usuarios o grupos pueden realizar funciones en la entidad. Donde los grupos específicos de intencionalidad son colectivamente definidos como roles.

Figura 2d – Cada entidad tiene metadatos asociados, un historial de eventos y una lista de control de acceso

Figura 2d1. Entity: Entidad2. Metadata: Metadatos3. Event History: Evento Histórico4. Access Control List: Lista de Control de Acceso.

Para más información de cómo los metadatos son manejados. En MoReq2010®

puede ser encontrado en 7. Modelo de Servicio de Metadatos. Mientras el historial de eventos son discutidos a continuación. Información sobre control de acceso puede ser encontrada en 4. (Roles del Modelo de Servicio)

Eventos y entradas de control de acceso comparten el historial de eventos y la lista de control de acceso de una entidad a la cual ellos pertenecen. Los componentes comparten la lista de control de acceso de la entrada de registro a la cual ellos pertenecen.

Cada MoReq 2010®

de servicios básicos, no es solo un contenedor para las entidades de tipos de entidad en particular, sino que es considerado como una entidad con sus propios metadatos , historial de eventos y una lista de control de acceso la cual está extendida a todas las entidades en ese servicio. La composición de entidades y su relación con servicios es mostrada en la Figura 2e.



Figura 2e – Un servicio contiene entidades con sus propios metadatos, historial deeventos y ACL, y además es considerado como una entidad con metadatos, historial de

eventos y ACL

Figura 2e – Entity: EntidadMetadata: metadatosEvent History: Historial de EventosAccess Control List: Lista de Control de AccesoService: Servicio



2.2.6 Identificación de entidades

Tal vez el elemento más importante de los metadatos para cualquier entidad es su Sistema Identificador. MoReq2010

® requiere identificadores universalmente únicos (UUID8) para cada

entidad y cada servicio dentro de un SDCM. El uso de un UUID es obligatorio para el cumplimiento de la especificación. Esto significa que cada entidad puede ser exportada desde un SDCM e importada dentro de otro SDCM y continuar siendo identificada. La importación SDCM puede incluso coincidir con las diferentes copias de la entidad original que fueron exportadas a diferentes tiempos o que fueron trasferidas a esta vía en un SDCM intermedio. Todas las entidades pueden ser remontadas a la instancia específica de su servicio de origen donde fueron creadas.

2.2.7 Realización de Funciones

Los usuarios manipulan las entidades en un SDCM al realizar funciones de estas. Algunas veces la SDCM es la que realiza la función como cuando esta genera un nuevo sistema identificador para un servicio en la instalación.

MoReq2010® es una especificación de requisitos y cada función que puede ser realizada a una

entidad en una SDCM que puede ser remontada a uno o más de los requisitos funcionales.

Los usuarios pueden solamente realizar funciones para entidades donde ellos tengan suficiente autoridad para hacerlo.

En acuerdo con 4. Modelo de Rol de Servicio, la autoridad para realizar una función viene de asociar un rol con un usuario o un grupo al cual los usuarios pertenezcan. Los roles son asignados a un usuario individual o a un grupo usando una entrada de control de acceso la cual se convierte en parte de ya sea un servicio o una lista de control de acceso de la entidad.

Como se discutió en 2.2.2, en la parte de arriba, algunas soluciones de SDCM pueden desviarse de los requerimientos específicos del modelo del rol de servicio, pero todas las soluciones de SDCM deben ser capaces de proveer un acuerdo similar y compatible de funcionalidad. El significado de un modelo de rol de servicio es discutido más adelante en 4. Modelo de Rol de Servicio.

2.2.8 Historial de Eventos

Cada entidad en un SDCM tiene un historial de eventos, compuesto de una serie de eventos que le han ocurrido a la entidad. Cuando sea que una función sea presentada, si por un usuario o por el sistema, en el cual la entidad es una entidad participativa, un evento es generado y adicionado al historial de eventos de la entidad. Cada evento es un historial de eventos por lo tanto se correlaciona a una única función que ha sido realizada en el SDCM.

Al fin de evitar que los historiales de eventos crezcan mucho, o sean llenados con eventos triviales, MoReq2010® incluye disposición para un usuario autorizado para desactivar la generación de eventos para funciones seleccionadas.

8 UUID: Universally Unique Identifier = Identificador universalmente único



Los metadatos de un evento siempre se establecen por un SDCM y no debe ser permitido que este sea alterado por el usuario. Los eventos no tienen un historial de eventos.

Los diferentes eventos tendrán diferente metadatos dependiendo de la función que ha sido realizada para generar el evento. Esto hace posible que el evento aparezca en el historial de eventos de más de una entidad participativa. Por ejemplo:

• Sí un usuario autorizado cambia el nombre de una agrupación, bajo R6.5.3, entonces hay solo una entidad participativa (la agrupación). El evento (F14.5.17 Agrupación Metadato Modificado) aparecerá solamente en el historial de eventos de la misma.

• Sí un usuario autorizado crea un registro en una agrupación, bajo R6.5.10, entonces hay dos entidades participativas (los dos, la agrupación y el registro) y el mismo evento (F14.5.121 Registro – creación) aparecerán en los historiales de eventos de los dos.

• Sí un usuario autorizado mueve un registro de una agrupación a otra, bajo R6.5.13, entonces hay tres entidades participativas (la anterior agrupación parental, la nueva parental y el registro). El evento (F14.5.3 Agrupación – Adicionar Registro) tendrá tres entidades participativas y el único evento aparecerá en tres historiales de eventos simultáneamente. • Bajo R6.5.21, un registro es siempre una entidad participativa en funciones realizadas

en sus componentes así que el evento generado siempre aparece en el historial de los dos componentes y el registro al cual este pertenece.

La figura 2f muestra cómo un evento puede pertenecer a más de un historial de eventos de una entidad.

Figura 2f – El mismo evento de la entidad puede aparecer en más de un historial de eventos.

Un recorrido de auditoria tradicional puede ser conceptualizado como una vista de todos los eventos desde el historial de eventos de todas las entidades a través del SDCM completo (en un ordenador de marcas de tiempo)



2.2.9 Marcas de tiempo.

MoReq2010® tiene características particulares que permiten a los sistemas de registro inter

operar en un nivel universal. Uno de estos es el uso de marcas de tiempo.

La especificación requiere que las marcas de tiempo deben ser aplicadas por el SDCM como metadatos a una compañía en cada evento que esta genere. Por ejemplo, cada entidad tiene una marca de tiempo creada que indica cuando la entidad fue creada.

Las marcas de tiempo deben contener los datos de fecha y hora completa y precisa, incluyendo la información del uso horario, que permita a los eventos ser ordenados en la secuencia en la cual ellos ocurren. Sí un SDCM es capaz de realizar muchos eventos en un segundo entonces el SDCM debería proveer una mejor precisión de milisegundos así estos eventos seguirían en orden cuando sean clasificados por la marca de tiempo.

Las marcas de tiempo mantienen la interoperabilidad al permitir que las entidades sean exitosamente trasferidas a otra SDCM en otro uso horario.

2.2.10 Apoyo en Idioma Universal

Otra característica universal de MoReq2010® es su apoyo para un código único. Todos los

elementos textuales de los metadatos deben estar en un formato de código único y deben estar acompañados por un identificador de idioma. Un SDCM puede soportar solo uno o un número limitado de idiomas. Sin embargo, así como soporta interoperabilidad, un identificador de idioma debe ser capturado por todo los metadatos textuales.

2.2.11 Ciclo de vida de una entidad

Sin tener en cuenta su tipo de entidad, todas las entidades en un SDCM tienen un ciclo de vida similar. Un esquema de un ciclo de vida de una entidad es mostrado usando la línea de tiempo en la Figura 1g.

Figura 2g – Cada entidad en un SDCM sigue un ciclo de vida similarCreation event: Evento Creado Residual: ResidualMay be deleted: Debe ser borrado Active: ActivoFirst used: Usado primero Time: TiempoDestruction Event: Evento de destrucción



Cada entidad será creada en el SDCM, por lo que su primer evento es su evento de creación. La entidad entonces se mantendrá activa hasta que esta sea destruida, generando un evento de destrucción. Siguiendo su evento de destrucción el SDCM seguirá manteniendo una entidad residual para indicar que la entidad anterior existió en el SDCM.

Todas las soluciones del SDCM deben conservar entidades residuales. La destrucción es diferente a la supresión, donde todo rastro de la entidad es borrado. No es posible suprimir entidades desde un SDCM como si ellas nunca hubieran sido creadas a menos de que ellas hayan suprimidas antes de ser usadas. Las entidades que han sido usadas no pueden ser suprimidas.

Algunas entidades, sobre todo registros y sus componentes, (pero también entidades tales como eventos, control de acceso de entradas, sistema de definiciones de elementos de metadatos, etc) no tienen una primera marca de tiempo usada y nunca pueden ser borradas. Una vez ellas hayan sido creadas, las entidades de estos tipos de entidades nunca pueden ser borradas sin rastro desde un SDCM. El ciclo de vida de un registro es explicado con más detalle en 6. Servicio de registros y 8. Servicio de Disposición de clasificación.

2.4 Requerimientos Funcionales

R2.4.1

Un SDCM debe implementar la funcionalidad de:

• Un usuario y un servicio grupal,• Un servicio de rol,• Un servicio de clasificación,• Un servicio de registros,• Un servicio de metadatos,• Un servicio de clasificación de la eliminación,• Un servicio de retención de la eliminación,• Un servicio de reporte y búsqueda, y• Un servicio de exportación.Cada servicio puede ser implementado individualmente o varios servicios pueden ser incluidos juntos.

Los Requerimientos funcionales para cada uno de estos servicios pueden ser encontrados en el MoReq2010

® servicios principales. El SDCM puede también implementar la funcionalidad adicional como se define en los módulos de ampliación de MoReq2010

®.

El SDCM puede compartir cualquiera de sus servicios, excepto su servicio de registro, con otros sistemas de registros. MoReq2010

® no especifica como los servicios son compartidos entre sistemas de

registros.

El SDCM debe implementar la funcionalidad descrita por tres servicios, sin embargo no hay requerimiento para implementarlos como servicios discretos. El SDCM puede crear cada servicio separadamente o puede combinar la funcionalidad de varios servicios juntos dentro de un paquete de servicios. El SDCM completo puede representar un único paquete de servicios.



R2.4.2

En la instalación, El SDCM debe iniciar los siguientes metadatos para cada servicio. (E14.2.14), o un paquete de servicios bajo R2.4.1:

• Sistema Identificador (M14.4.100),• Servicio Identificador de Implementos (M14.4.42),• Modulo Identificador de Implementos (M14.4.41),• SDCM Identificador de certificación (M14.4.54),• Información del proveedor (M14.4.99),• Identificador de Idioma defectuoso (M14.4.12),• Titulo (M14.4.104),• Descripción (M14.4.16), and• Información del propietario (M14.4.62).Cada servicio o paquete de servicios, también contiene:

• Tipos de entidades por cada entidad dirigida por el servicio o paquete de servicios,• Entidades que son dirigidas por el servicio o el paquete de servicios,• Historial de eventos para cada servicio o paquete de servicios,• Lista de control de acceso (o equivalente, ver 4.Modelo de Servicio de Roles),Y puede tener:

• Metadatos contextuales (o equivalentes, ver 7 Modelo de Servicio de Metadatos)Cada servicio o paquete de servicios tiene su propios metadatos, historial de eventos y lista de control de acceso. Cada valor de un elemento de metadatos que implementa un Servicio Identificador debe

coincidir con un Servicio de publicación con la especificación del MoReq2010® (el valor del

identificador es dada en el bloque de información de servicios en el encabezado de cada sección desde 3. Usuario y Grupos de Servicio en adelante). Cada Módulo Identificador de Implementos debe

coincidir con un módulo de publicación con la especificación del MoReq2010®. Cada Identificador de

Certificación del SDCM debe coincidir con un certificado expedido por el DLM Forum® a un SDCM

que ha pasado las pruebas de compatibilidad con un examen central acreditado y siendo certificado.

La información del proveedor debe describirlo, El producto y la versión del producto instalado. Este puede también contener otra información útil acerca del proveedor, el producto, y la versión del producto instalado. Esto puede también contener otra información útil acerca del proveedor tal como información del contacto y el URI para e sitio del soporte del producto.

Dependiendo del enfoque tomado por el SDCM en la implementación 4. Modelo del rol de servicio, un lista de control de acceso del MoReq2010® puede no estar presente durante el sistema de operación y puede solamente ser adicionada a un servicio de exportación.

Dependiendo del enfoque tomado por el SDCM en la aplicación 7. Modelo de servicios de metadatos, el mecanismo en el cual los metadatos contextuales son adicionados a los servicios puede variar.



R2.4.3

El SDCM debe permitir que un usuario autorizado busque a través de sus servicios, o paquetes de servicios bajo R2.4.1, e inspeccionar los metadatos de cada uno como se indica bajo R2.4.2.

Los términos “buscar” e “inspeccionar” son definidos en 13. Glosario de Términos.

El usuario debe buscar cada servicio o paquete de servicios. Sí el SDCM combina todo funcionalmente dentro de un único paquete entonces habrá solo un conjunto de metadatos por inspeccionar para el sistema como un todo.

Función de referencia: F14.5.158

R2.4.4

El SDCM debe permitir a un usuario autorizado modificar los metadatos para cada servicio, o paquete de servicios bajo R2.4.1, incluyendo:

• Titulo,• Descripción,• Información de propietario, y• Metadatos contextuales (si hay alguno).

La información del propietario da información acerca de organización u organizaciones usando el SDCM, y puede incluir servicio de asistencia o información de contacto. El título y la descripción deberían proveer el nombre local del SDCM y una descripción descriptiva adicional.


R2.4.5

El SDCM debe permitir al usuario autorizado generar una lista de reporte de cumplimiento del MoReq2010® en cada de sus servicios activos, o paquete de servicios bajo R2.4.1, y por cada servicio o paquete de servicios listando los metadatos para cada servicio o paquete de servicios, bajo R2.4.2.

El reporte deber ía indicar cua l es serv ic ios es tán implementados indiv idua lmente , y donde var ios servic ios es tán empaquetados juntos .

Este requisito tiene por objeto proporcionar a los usuarios autorizados con seguridad de que un SDCM

instalado en MoReq2010®

cumple cuando es implementado en un sitio particular para una organización particular. Por esta razón los valores de los Identificadores de Servicio de Implementos, los Identificadores de Módulos de Implementos y el Identificador de Certificación de SDCM de elementos de metadatos listados en contra de cada servicio, deben precisamente reportar el estado de cumplimiento de la instalación particular del SDCM.

El reporte debe hacer más que indicar si el SDCM históricamente ha pasado las pruebas de cumplimiento

de MoReq2010®, el reporte debe también indicar si el SDCM ha sido instalado y configurado

correctamente y está en compatibilidad con esos servicios y módulos a tiempo cuando el reporte es

generado. MoReq2010®

no especifica cómo cada SDCM individual debería revisar su consistencia interna y configuración después de la instalación, sin embargo este es un requerimiento importante para operar un SDCM en un medio de cumplimiento regularmente.

Función de Referencia: F14.5.163



R2.4.6

El SDCM debe asegurar que cada servicio, o paquete de servicios bajo R2.4.1, tengan una interface que implemente uno de los módulos del MoReq2010

®, 100. Series de Interfaces.

Un SDCM, o diferentes servicios dentro del SDCM, pueden implementar más de uno de los 100 módulos de la serie de interface, pero cada servicio o paquete de servicios, debe ser completamente compatible con este y evaluado al menos con un módulo de interface en las 100 series..

R2.4.7

Si embargo si el SDCM falla al completar una función requerida por sí mismo o por un usuario autorizado el SDCM debe escribir por lo menos la siguiente información de error a un registro externo:

• La fecha / hora de la falla;• El sistema identificador de la función que se intentó;• El sistema identificador del usuario autorizado que inició la función;• El sistema(s) identificador(es) de cualquier entidad participativa; y• Una amplia información del error explicando la falla.

Este requerimiento se refiere a un registro de errores que no se mantiene dentro del propio SDCM. El propósito de guardar un registro externo a el sistema es hacer este asequible aun cuando el SDCM no esté disponible.

La información amplia del error puede ser generalmente definida como información de diagnóstico incluyendo códigos de errores, detalles acerca del estado del sistema y la hora en la cual el error ocurrió,

las excepciones del software que fueron encontradas. MoReq2010®

no especifica qué información de error debe ser proporcionada por un SDCM

Observe que funciones deben ser realizadas automáticamente. MoReq2010®

no permite que las funciones sean parcialmente exitosas ya que esta dejaría el SDCM en un e s t ad o in de f i n i do . S i una func i ón fa l l a en a lgún punto entonces e l SDCM debe revertir todos los cambios a su estado interno hecho por la función antes de que estos estén comprometidos. MoReq2010

® no especifica

cómo se hace esto.

R2.4.8

Siguiendo la falla de una función requerida por un usuario, bajo R2.4.7, e l SDCM debe proporcionar unos medios por los cuales el usuario puede recuperar amplia información del error sobre la función fallida sin acceder al registro externo.

MoReq2010® no especifica el mecanismo por el cual un SDCM debería proporcionar una amplia información del error siguiendo una función fallida por el usuario. (Esto funcionalmente no está incluido en las definiciones de la función en 14.5 Definiciones de Función.)

El medio por el cual el SDCM comunica una anterior function fallida al usuario será dependiente al tipo de interface que el SDCM proporcione ver R2.4.6.

R2.4.9

El SDCM debe permitir a un usuario autorizado buscar los tipos de entidad asociados con cada servicio, o paquete de servicios bajo R2.4.1, e inspeccionar sus metadatos.

Los siguientes tipos de entidades están asociadas con cada servicio:

El usuario y el grupo de servicio manejan entidades de usuario y grupos;



El servicio de rol maneja roles;

El servicio de clasificación maneja clases;

El servicio de grabación maneja adiciones , grabaciones y componentes;

El servicio de metadatos maneja definiciones elementales de datos y plantillas.

El servicio de programación de eliminación maneja eliminación de datos; y

El servicio de eliminación maneja las eliminaciones

La función de definiciones y eventos puede ser encontrada en todos los servicios mencionados anteriormente, que maneja uno o más tipos de entidad.

Para más información sobre cada uno de estos tipos de entidad, ver 14.2 tipos de entidad. función de referencia: f14.5.83

R2.4.10

Cada tipo de entidad (E14.2.7)bajo R2.4.9,debe tener el siguiente metadato

• sistema de identificación(M14.4.100),

• titulo(M14.4.104), y

• descripción(M14.4.16).

Cada tipo de entidad, tiene también:

• Sistema de definiciones de elementos de metadatos para ese tipo de entidad,

• Definiciones de función para ese tipo de entidad,

• Caso de historia, y

• Lista de control de acceso (o equivalente, ver 4. Modelo de servicio del rol

Los sistemas de identificación para cada tipo de entidad en MoReq2010®, junto con los títulos por defecto y las descripciones puede ser encontrado en 14.2 tipos de entidad. Los SDCM deben

siempre usar el MoReq2010® sistema de identificadores proveído y no debe generar su propio

sistema de identificadores para tipos de entidades. Sin embargo, los títulos por defecto y

descripciones pueden ser remplazados por el SDCM con valores localizado.

R2.4.11

Para cada tipo de entidad, bajo R2.4.10, El SDCM debe permitir un usuario autorizado para ver las entidades de definición de la función asociada a ese tipo de entidad y revisar sus metadatos.

Para las listas completas de las definiciones de función asociadas con cada tipo de entidad, ver 14.5 definiciones de la función



Referencia de la función: F14.5.87

R2.4.12

Toda definición de función (E14.2.9) BAJO R2.4.11, debe tener el siguiente metadato:

• Sistema de identificación (m14.4.100),

• Título (M14.4.104),

• Descripción (M14.4.16),

• Generar marcador del evento (bandera) (M14.4.34), y

• mantener el identificador de destrucción (ver "bandera". cap.13) (M14.4.88).

Toda definición de la función, también tiene:

• Los elementos del sistema de metadatos que se añade a los acontecimientos,

• Historial de eventos, y

• Lista de control de acceso (o equivalente, ver 4. Servicio de modelo de rol),

Los identificadores de sistema para cada definición de funcionen MoReq2010®,junto con los títulos por defecto, descripciones y los tipos de entidad que ellos aplican, pueden ser encontrados en 14.5 definiciones de Función.

El SDCM debe siempre utilizar el MoReq2010 ®, identificadores del sistema y no debe generar su propio sistema de identificadores para las definiciones de función. Sin embargo los títulos por defecto y descripciones de las definiciones de función pueden ser remplazadas por el SDCM con valores localizados.

R2.4.13

Para cada definición de función, bajo R2.4.11, el SDCM debe permitir un usuario autorizado para especificar si sí o no un caso debe ser generado por el SDCM cuando la función se lleva a cabo.

El valor es almacenado en el indicador de caso generado. Ver R2.4.12.

llevar a cabo la función descrita por esta exigencia, cambiar el valor del indicador de evento debe siempre resultar en un evento siendo generado como explicado por R2.4.14 antes, los casos son generados y agregados a casos de historias bajo, R2.4.15 anterior.

además , llevar a cabo las funciones descritas en R2.4.21, R3.4.4 y R7.5.7resultarà siempre en un caso evento siendo generado, además de el valor de la indicador de evento.referencia de función: F14.5.91

R2.4.14

Un evento debe siempre generarse por parte del SDCM cuando la función descrita por 12.4.13 sea llevada a cabo.



Esta condición es una excepción para R2.4.13 cuando la generación de un evento para esta función, no esté en capacidad de ser suprimida.

El propósito de este requerimiento es el de asegurar que un historial sea guardado por el SDCM de todos los cambios, ya sea que las funciones particulares capturadas como eventos, así como la información de los usuarios que los realizaron.

R2.4.15.

Cada vez que una función descrita en MoReq2010® es llevada a cabo por alguna entidad en el

SDCM, y conducente a generar una bandera indicadora del evento, descrita en R2.4.13, entonces

el SDCM debe crear automáticamente un nuevo evento que describa la función que fue

desarrollada e incluirla en el historial del evento para todas las entidades participantes.

El SDCM debe mantener un historial de eventos como parte de los metadatos de toda entidad en el SDCM.

R2.4.16

Para cada evento (E14.2.8) creado bajo R2.4.15, por una función siendo llevada a cabo, el SDCM debe incluir los siguientes metadatos:

• identificador de sistema (M14.4.100),

• Marca de tiempo creada (M14.4.9),

• Marca de tiempo del evento (M14.4.27), and

• Identificador de función del evento (M14.4.26).

Donde la función sea llevada a cabo por el usuario, y no el SDCM, el evento también incluirá:

• Realizado por el identificador de Usuario (M14.4.83), y puede incluir , bajo R2.4.18:

• Comentario del evento (M14.4.25).

Donde el evento haya sido duplicado bajo R6.5.16, también incluirá

• Identificador del duplicado (M14.4.23).

Donde el evento modifica los metadatos de la entidad, bajo R2.4.17, incluirá:

• Entrada de cambio de los metadatos (D14.3.3).

Los eventos deben también tener uno o más de los siguientes elementos adicionales del sistema de metadatos dependiendo de la función que representan, como se especifica en la descripción de cada función dada en 14.5 Definiciones de la Función:



• Identificador de plantilla aplicada(M14.4.2),• identificador de definición de función de caso borrador (M14.4.14),• identificador de definición de la función de borrado de (M14.4.15),• inicio de la exportación de tiempo y hora (M14.4.28),• fecha y hora de exportación completados (M14.4.29),• Identificador de exportación (M14.4.30),• exportado en bandera complete (M14.4.31),• identificador de rol otorgado (M14.4.35),• fecha histórica/ hora (M14.4.40),• código de acción de eliminación atrasada (M14.4.58),• acción de fecha de vencimiento de eliminación atrasada (M14.4.59),• fecha de vencimiento de confirmación de eliminación atrasada (M14.4.60),• identificador de participación agregada (M14.4.64),• identificador de clase participante (M14.4.65),• identificador de componente participante (M14.4.66),• identificador de participación de eliminación permanente (M14.4.67),• identificador de eliminación de participante calendario de (M14.4.68),• identificador de participación duplicada (M14.4.69),• o de participación de tipo de entidad (M14.4.70),• identificador de participación de caso (M14.4.71),• identificador de participación de definición de (M14.4.72),• identificador de participación de grupo (M14.4.73),• identificador de definición de elementos de participación de metadatos (M14.4.74),• identificador de participación de nueva causa (M14.4.75),• identificador de participación de causa anterior (M14.4.76),• identificador de participación de registro (M14.4.77),• identificador de rol de participación (M14.4.78),• identificador de servicio de participación (M14.4.79),• identificador de participación de plantilla (M14.4.80),• Identificador de participación de usuario (M14.4.81),• Identificador de participación de grupo o usuario (M14.4.82),• Identificador de rol Revocado (M14.4.87),

• Petición de búsqueda (M14.4.98), and

• Entidades totales (M14.4.105).

El identificador de función de evento debe ser una referencia para la definición de función que fue realizada por el usuario, hace referencia a lo realizado por el identificador de usuario. La marca de tiempo del evento refleja cuando la función fue realizada; esto será establecido por el SDCM y usualmente será igual a la marca de tiempo creada, a menos que el evento haya sido creado por otro SDCM.

Los elementos de metadatos adicionales para ser adicionados a un evento dependerán de la función que fue realizada y son enlistados como parte de la definición de función (ver R2.4.12) y son dados en su totalidad en 14.Definiciones de la función. Dependiendo de la función que fue realizada el caso puede



requerir metadatos. Por ejemplo , si la función era exportar la entidad, entonces el SDCM debe incluir el identificador de Exportación y la Bandera de Exportado en su Totalidad en el evento bajo, R11.4.8.

Cualquier entidad referenciada por un identificador que toma la forma, “identificador de … participación” es una entidad participante en el evento. Todas las funciones tienen al menos una entidad participante y algunas funciones tienen varias entidades participantes. El evento debe aparecer en el historial del evento de todas las entidades participantes.

R2.4.17

Cada vez que los metadatos de una entidad son modificados como consecuencia de la realización de una función y el evento es generado `por la función, bajo R2.4.15, el SDCM debe incluir una entrada de metadatos de cambio (D14.3.3) en el caso por cada valor de metadato que es modificado, con los siguientes metadatos:

• identificador de definición de elementos de metadatos (M14.4.55),• valor previo (M14.4.85), y• valor nuevo (M14.4.57).

Una entrada de cambio de metadatos es una estructura de datos definida en D14.3.3, y capta los anter iores y s iguientes es tados de un e lemento de metadatos pertenec iente a la ent idad. E l ident i f i cador de def in ic ión de e lemento de metadatos cont iene la referencia para el elemento de metadatos que fue modificado. El valor previo contiene el valor del elemento del metadatos antes que la función sea realizada. El nuevo valor contiene el valor del elemento del metadatos después que la función fuera realizada.

No habrá valor previo si el valor es nuevamente aplicado a la entidad y tampoco nuevo valor si el valor previo es eliminado.

Por ejemplo, si un usuario cambia el titulo de una entidad entonces el caso correspondiente tendría una entrada de metadatos de cambio que referenció el Titulo definición de elementos de metadatos (M14.4.104), s u a n t i g u o v a l o r a n t e s q u e l a f u n c i ó n s e a r e a l i z a d a , y e l n u e v o v a l o r e s t e d a d o p o r e l u s u a r i o .

Todo elemento de metadatos que es cambiado por una función resultará en una entrada de cambio de metadatos incluida en el caso. Si múltiples elementos de metadatos son cambiados simultáneamente por una función entonces el caso incluirá una entrada de cambios de metadatos para cada elemento de metadatos que es cambiado.

R 2 . 4 . 1 8

siempre que el SDCM realice una función solicitada por un usuario, y no por sí mismo, el cual cambia el metadato de una entidad, el SDCM debe permitir al usuario proveer un comentario



explicando porque la función fue realizada. si dado, el comentario debe ser incluido en el caso como el elemento de caso, bajo según R2.4.16.

El SDCM no es necesario Para crear las condiciones para que el usuario introduzca un comentario de eventos para las funciones, las cuales no cambian el metadatos de la entidad, t a l c o m o n a v e g a n d o como la navegación por la entidad y la inspección de sumetadatos. Tenga en cuenta que cambiar los metadatos de la entidad dará lugar a la generación de una o más entradas de metadatos de cambio, según R2.4.17.

Proporcionar un comentario es opcional en la mayoría de los casos. Sin embargo, algunas funciones requieren un comentario por parte del usuario

(Por Ejemplo, Ver R2.4.21, R2.4.26, R8.4.17, R8.4.18, R7.5.7 Y R11.4.10).Mientras que el SDCM no está obligado a proporcionar un comentario de eventos para las funciones que se lleva a cabo

Mientras que el SDCM no está obligado a proporcionar un comentario de eventos para las funciones que este mismo realiza, según R2.4.16, el SDCM puede ser implementada de tal manera que esta automáticamente genera un comentario de caso mientras se realizan tales funciones y lo incluye en el caso.

R2.4.19

El SDCM debe permitir un usuario autorizado para ver el historial de eventos de una entidad con el fin de la hora del evento, e inspeccionar los metadatos de cada evento.

Los términos “Navegar” E “Inspeccionar” Son definidos en 13. Glosario de términos. Los historiales de eventos son usualmente mas navegados desde los más recientes acontecimientos de los primeros eventos en orden descendente de la hora del evento. El SDCM también puede proporcionar otras formas de navegar por el historial de eventos. El SDCM puede proveer otros modos de explorar el historial de eventos.

Referencias de función: F14.5.14, F14.5.32, F14.5.45, F14.5.65, F14.5.79, F14.5.85, F14.5.89,F14.5.103, F14.5.111, F14.5.133, F14.5.151, F14.5.160, F14.5.173, F14.5.189

R2.4.20

para cada definición de función, según R2.4.11, La SDCM debe permitir un usuario autorizado para especificar si o no un evento generado por el SDCM, cuando la función fue realizada, debe mantenerse cuando la entidad que pertenece se destruye.

El valor es almacenado en la Retención del aviso de destrucción, ver R2.4.12.

Los eventos para funciones donde se mantiene el aviso de destrucción no es establecida será eliminada automáticamente será borrada del historial de eventos de la entidad cuando la entidad sea destruida. Ellas no serán parte del historial del caso de la entidad residual.



La eliminación automática de casos por entidades puede ser realizada por un numero de razones, incluida pero no limitadas a:

Destrucción asegurada a remover casos cuyo metadatos, especialmente como resultado de la información almacenada en los metadatos cambian las entradas, según,

Corte automático de eventos para entidades residuales debe ser completado por un numero de razones, Incluyendo pero no limitado a:R2.4.17, Puede hacer posible Parcialmente o completamente reconstituir la entidad,

•Privacidad – Quitar eventos que pueden potencialmente almacenar información personal, y

•Almacenamiento - Reducir la huella de una entidad residual

Nótese que podría no ser posible activar una entidad residual una vez ha sido destruida.Los eventos solo son automáticamente terminados en la destrucción de la entidad participante contra cualquier función para el evento que fue puesta en marcha (ver el motivo en R2.4.21). Esto es solamente aplicable En eventos donde Hay más de una entidad actuando. Ver. 14.5 Definición de las Funciones.

Referencia de función: F14.5.92

R2.4.21

El SDCM debe permitir un usuario autorizado borrar un evento desde el historial de una entidad residual, permitiendo al usuario dar una razón por la eliminación y un evento es generado

Este requerimiento describe una circunstancia especial donde es necesario eliminar metadatos o eventos desde entidades individuales, por ejemplo, donde esta ha sido ordenada por una corte de leyes. debería no ser necesario ejecutar este requerimiento como parte de una rutina de procesos de datos administrativos

Este requerimiento debe ser solo aplicado a una entidad residual que ya ha sido destruida, y es en adición a el corte automático de metadatos y eventos que se generan en la destrucción

Nótese que un nuevo evento debe siempre ser generado para esta función sustituyendo la petición R2.4.13El usuario autorizado debe dar una razón para eliminar el evento eliminado que es almacenado como el evento comentado en el nuevo evento

El nuevo evento debe también contener una función de identificador de definición de evento eliminado (ver M14.4.14) el cual indica la función identificadora de el evento eliminado, esto da una indicación de que tipo de evento fue eliminado sin retención alguna del metadato de el evento eliminado

Donde el evento a ser eliminado tiene más de una entidad participante, el mismo debe ser eliminado desde la entidad contraria de la función que fue originalmente ejecutada. esto es también la entidad participante para el evento de notificación de la eliminación. Por ejemplo,



para eliminar el evento donde una entrada es movida de un registro a otro, debe ser eliminado desde la raíz del registro nuevo, porque esto es la entidad contraria a la función que fue completada y el evento generado ver F14.4.3 Agregando el nuevo registroVer también R7.5.7

Referencias de función F14.5.7, F14.5.26, F14.5.39, F14.5.50, F14.5.59, F14.5.73, F14.5.97, F14.5.122,

F14.5.145, F14.5.167, F14.5.181

R2.4.22

Cuando un usuario autorizado está explorando un grupo de entidades el SDCM debe por defecto, solo limitar el grupo de entidades a activas, a menos de que el usuario escoja explorar ambas activas y entidades residuales

El término "explorar" es definido en 13. Glosario de términos

Por defecto, las entidades que han sido destruidas no serán explorables. Ver también R10.4.17 y R11.4.2

R2.4.23

El SDCM siempre debe usar los identificadores del sistema que acompañe las especificaciones del MoReq2010® , donde sean dadas

MoReq2010®provee identificadores de sistema que hayan sido previamente generados para:

• Servicios y módulos (ver 2.1 Servicio de información);

• Tipos de entidades (ver R2.4.10 y 14.2 tipos de entidades);

• Definiciones de entidades (ver R2.4.12 y 14.5 Definiciones de funciones); y

• Sistema metadatos elementos y definiciones (ver R7.5.1 y 14.4 sistema metadatos definiciones de elementos).

Los identificadores de sistema proveídos con MoReq2010® deben ser usados para asegurar la interoperabilidad con otros sistemas de registros

R2.4.24

El SDCM debe generar sistemas identificadores para nuevas entidades como universalmente identificadores únicos (UUID) y no debe permitir cambios en esos identificadores.

MoReq2010® no especifica cual algoritmo SDCM debe usar para generar identificadores de sistema. las aproximaciones listadas en RFC4122 son recomendadas y pueden proveer "altos porcentajes de asignación hasta de 10 millones por segundo por maquina" (RFC4122:2005,2.)

R2.4.25



El SDCM debe automáticamente configurar el la hora y fecha y donde exista., la fecha/hora originada para todas las nuevas entidades en creación

Por defecto ambos creados hora y fecha y día y hora reflejaran la fecha y tiempo de la creación de la entidad

Funciones referenciadas: F14.5.5, F14.5.24, F14.5.38, F14.5.48, F14.5.57, F14.5.71, F14.5.95, F14.5.121,

F14.5.143, F14.5.165, F14.5.179

R2.4.26

Donde exista, el SDCM debe permitir al usuario autorizado cargar la fecha/hora para una entidad activa a una anterior fecha y hora que la marca de tiempo, proviniendo a el usuario una razón para el cambio

por defecto la fecha/hora originada es configurada a la misma fecha y hora que la marca de tiempo creada bajo R2.4.25. Un usuario autorizado puede subsecuentemente cambiar este valor por una entidad activa para reflejar una anterior fecha y hora, pero nunca una fecha y hora futuros. donde sea el usuario cambie la fecha/hora a una anterior, un comentario debe ser provisto el cual es almacenado en el evento generado para la función

nótese que la hora/fecha originados es un posible disparador bajo R8.4.4. y resteándolo por una adición o registro puede afectar el cálculo de una o más retenciones de fechas de inicio

Funciones referenciadas F14.5.18, F14.5.36, F14.5.47, F14.5.54, F14.5.68, F14.5.82, F14.5.106,F14.5.136, F14.5.154, F14.5.176, F14.5.192

R2.4.27El SDCM debe generar marcas de tiempo que son compatible con W3C XML formatos marca de tiempo y debe siempre incluir la hora de la zona de información en las marcas de tiempo.

El formato requerido es definido en W3C XML esquema definidor de lenguaje (en inglés XSD) 11 parte 2: data tipos el formato de la marca de tiempo es una variante del formato XML hora/fecha que es a su vez un subconjunto de ISO 8601 que no permite formatos reducidos o truncados.

la Información de la hora y fecha es una inclusión necesaria en todas las marcas de tiempo para determinar cuando los eventos ocurrirán relativos a otros eventos, y para asegurar interoperabilidad con sistema de registros in deferentes husos horarios

R2.4.28El SDCM debe almacenar todo elemento textual en Unicode acompañado por un identificador de lenguaje que es compatible con RFC5646 y el Registro sub identificador de lenguaje IANA .

Un elemento de metadatos es considerado textual si la marca textual es puesta en el metadato correspondiente definidor elemental ver R7.5.1

MoReq2010® no especifica como un SDCM identificará el identificador de lenguaje usado para metadatos textuales. Opciones puede incluir



• En contextos monolingües puede ser derivado desde el identificador de lenguaje preestablecido para el servicio o el paquete de servicios (ver R2.4.2)

• puede ser especificados en procedimientos operaciones o por la naturaleza del metadato

• puede ser derivado desde las configuraciones de la sesión del sistema operativo de un cliente usuario o

• puede ser suplido como información adicional por el usuario

El uso de Unicode asegura que toda configuración de carácter puede ser representada y es necesaria para interoperabilidad. la ultima versión estándar de Unicode es 6.0



3. Usuario y Grupo de Servicios

3.1 Información de servicio

Nombre de Servicio Usuario y Grupo de Servicios

Versión de Servicio 1.0

Implementos Identificadores de servicio (ver M14.4.42)

cd532472-85b0-4c1c-82b4-5c8370b7d0e6

3.2 Conceptos Clave

3.2.1 MoReq2010®

Enfoque para Usuario y administración de Grupo

Un buen manejo de usuarios y grupos es esencial para una operación exitosa de sistemas de documentos. Todos los sistemas de negocios comparten esta misma necesidad. Como consecuencia hay muchas herramientas del sistema disponibles que manejan usuarios y grupos, con frecuencia esta funcionalidad es construida directamente en sistemas operativos computacionales. También hay estándares bien establecidos para el manejo de usuarios y grupos, directorios de servicio relacionados tales como X.500 y OpenID para autentificación de usuario.

Por esta razón MoReq2010® no aprueba oficialmente los protocolos que soluciones SDCM debería usar para la autentificación de usuario y manejo de usuario y grupo. El servicio de grupo y usuario en MoReq2010® es un conjunto de requerimientos que actúan como envoltorio permitiendo el uso de un servicio directorio corporativo externo o un servicio directorio tradicional construido en el SDCM. Aparte de los conceptos básicos de un usuario y un grupo descritos abajo, MoReq2010® no establece cómo los usuarios y grupos son manejados.

3.2.2 Requisitos para la Gestión de Documentos

Los servicios de directorios tradicionales por si mismos no proveen toda la funcionalidad requerida para la disciplina del manejo documentos. La información retenida dentro de un servicio directorio es frecuentemente temporal por naturaleza. Usualmente hay poca o ninguna capacidad para poder rastrear usuarios anteriores de un sistema. Los identificadores del sistema para usuarios y grupos no pueden ser universales o podrían ser sujetos a cambios, por ejemplo si un servicio directorio externo es duplicado o reconstruido. Significativamente, la información en un servicio directorio privado no debe estar en un formato común que pueda ser fácilmente entendido por otro sistema de documentos cuando los documentos son transferidos. Estos factores pueden hacer difícil



determinar desde una perspectiva histórica que usuarios llevan a cabo acciones particulares, quienes fueron y a que grupos pertenecieron.

MoReq2010® por lo tanto se requiere que SDCM conserve información estable y adicional sobre usuarios y grupos incluyendo su información histórica. Esto incluye crear entidades que representen a todos los usuarios y grupos dentro de SDCM, usando el sistema universal de identificadores MoReq2010®, rastrear cambios en los metadatos de las entidades y retener información destruyendo usuarios y grupos para dejar entidades residuales antes que borrarlos enteramente del sistema cuando ya no están activos.



Si el SDCM usa un directorio externo para administrar el usuario y grupo entonces necesitara sincronizarse o por otra parte integrarse con este, para asegurar que la información es capturada, actualizada regularmente y retenida seguida de su eliminación del sistema externo. MoReq2010

® no especifica como esto deberá ser llevado a cabo.

3.2.3 Cómo Trabajan Usuarios y Grupos

La Figura 3a muestra la asociación many-to-many e n t r e u s u a r i o s y g r u p o s e n u n S D C M . Cada usuario puede pertenecer a muchos grupos y muchos usuarios pueden pertenecer al mismo grupo.

Usuarios pertenecen a gruposFigura 3a – En un SDCM, usuarios y grupos tienen una asociación many-to-

many.

Esta figura aplanada representa el grado de información que MoReq2010® requiere sobre una asociación entre usuarios y grupos. No hay requerimiento para rastrear las asociaciones entre grupos, aunque por ejemplo, muchos de los grupos mostrados en la Figura 3a de hecho pueden ser subgrupos de otro grupo.

3.2.4 Destrucción de usuarios y grupos

El servicio de grupo y usuario debe adoptar el enfoque común a través de la especificación de MoReq2010® para destruir entidades que dejen una entidad residual. De esta manera un documento se mantiene en estas entidades incluso cuando ya no están funcionando. MoReq2010® requiere que entidades de usuario y grupo no sean borradas de el SDCM una vez hayan sido usadas, y en su lugar deben ser retenidas para proveer un contexto a los documentos manejados por el sistema. Ver la discusión previa bajo 2.2.10 Ciclo de vida de una entidad



Una entidad residual no ejercita la misma funcionalidad que una entidad activa. En el caso de una entidad de usuario que ha sido destruida, un usuario residual no debe permitírsele acceder al SCDM.

En el caso de un grupo residual de entidades, cualquier rol que haya sido concedido a los miembros del grupo no aplica. Por lo tanto, un usuario activo que es miembro de un grupo residual, no se beneficiara por heredar cualquier rol asignado a ese grupo. Para más detalles, ver3. Modelo de servicio de Rol.

3.4 Requerimientos funcionales

R3.4.1

Al SDCM solo deber tener acceso los usuarios quienes han sido autentificados y para quienes existe una entidad de usuario activa (E14.2.16) como mínimo con los siguientes metadatos del sistema:

• Identificador del Sistema (M14.4.100),• Creación Sellado de Tiempo (M14.4.9),• Origen Sellado de Tiempo (M14.4.61),• Sellado de Tiempo usado por primera vez (M14.4.32),• Identificador de grupo (M14.4.36),• Titulo (M14.4.104),• Descripción (M14.4.16), and• Destrucción Sellado de Tiempo (M14.4.17).

Cada entidad de usuario también tiene:

• Historial del Evento (ver 2. Servicios del Sistema),• Acceso a la lista de control (o su equivalente a, ver 4. Modelo de Servicio de Rol),

Y puede tener:

Metadatos contextuales (o su equivalente a, ver 7. Modelo de Servicio de Metadatos).La autentificación describe el proceso del establecimiento de la identidad del usuario, por lo tanto el SDCM puede permitir un nivel apropiado de acceso para ejecutar funciones, y puede asociar cada función que es ejecutada con una entidad de usuario particular. MoReq2010® no define como debería ocurrir la autentificación. Una forma simple de autentificación es requiere que el usuario provea un nombre y una contraseña, y así pueda ser adecuado para muchos documentos del sistema. Otros métodos más complejos incluyen dos factores de autentificación en donde se requiere más de un ítem de identificación.

Dependiendo del enfoque tomado por el SCDM en la implementación del 4. Modelo de Servicio de Rol, un acceso a la lista de control de MoReq2010® puede no presentarse durante la operación del sistema y solo puede ser añadida a una entidad de usuario a exportar.

Dependiendo del enfoque tomado por el SCDM en la implementación del 7. Modelo de Servicio de Metadatos, el mecanismo por el cual los metadatos contextuales son añadidos a entidades de usuario, pueden variar.



R3.4.2

El SCDM debe mantener un proceso para crear nuevas entidades de usuario en el SCDM con los metadatos y otras propiedades listadas abajo R3.4.1.

MoReq2010® no define como debería operar el proceso, dependiendo de la implementación especifica, nuevas entidades de usuario no pueden ser creadas por usuarios de SCDM. Las organizaciones deben evaluar si el proveedor de procesos cumple con sus necesidades operacionales y de seguridad.Función de Referencia: F14.5.179.

R3.4.3

El SCDM debe mantener un proceso para actualizar el Titulo y la Descripción de una entidad de usuario y cualquier metadato contextual para reflejar cambios en los detalles del usuario.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este, sin embargo cambios en los metadatos del usuario deben generar un evento en el historial de eventos del usuario, bajo R2.4.15, sujeto a R2.4.13.

Funciones de Referencia: F14.5.191

R3.4.4

El SDCM debe mantener un proceso para añadir y remover usuarios activos de y para grupos activos cada vez que esto ocurra un evento debe ser generado.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este. Solo usuarios activos pueden cambiar su membrecía, únicamente pueden ser removidos de grupos activos y añadidos a estos. De esta manera un usuario residual conservara la membrecía de su grupo como lo fue en la destrucción; y un grupo residual conservara la membrecía de su usuario como lo estuvo cuando el grupo fue destruido.

Tenga en cuenta que un nuevo evento debe siempre ser generado para esta función, reemplazando el requisito R2.4.13. Los eventos son así generados para proveer datos correctos para reportar bajo.4.7 y R3.4.13.

Funciones de Referencia: F14.5.94, F14.5.107

R3.4.5

El SDCM debe mantener un proceso para eliminar un usuario que nunca ha usado el SDCM para ejecutar alguna función.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este. Cuando un usuario usa por primera vez el SDCM y ejecuta una función, el SDCM debe establecer el Sellado de Tiempo usado por primera vez.




R3.4.6

El SDCM debe mantener un proceso para destruir un usuario que ha usado el SDCM para ejecutar funciones.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este. Una vez un usuario ha usado el SDCM la entidad correspondiente del usuario no puede ser eliminada, solo puede ser destruida. Destruir un usuario establecerá el Sellado de Tiempo destruido y dejara una entidad de usuario residual.


R3.4.7

El SDCM debe ser capaz de generar un reporte por un usuario autorizado listando los grupos activos de la entidad a la que un usuario designado pertenece a una fecha y hora específicas.

El reporte no incluye grupos que el usuario solicitando el reporte no está autorizado a inspeccionar.El reporte debe indicar si la fecha y la hora fueron dadas antes o después de que la entidad de usuario fue creada o destruida.


R3.4.8

El SDCM debe ser capaz de mantener grupos (E14.2.10) p o r l o m e n o s c o n l o s s i g u i e n t e s m e t a d a t o s del sistema:

• Identificador del Sistema (M14.4.100),• Creación Sellado de Tiempo (M14.4.9),• Origen Sellado de Tiempo (M14.4.61),• Sellado de Tiempo usado por primera vez (M14.4.32),• Titulo (M14.4.104),• Descripción (M14.4.16), and• Destrucción Sellado de Tiempo (M14.4.17).

Cada entidad de usuario también tiene:

• Historial del Evento (ver 2. Servicios del Sistema),• Acceso a la lista de control (o su equivalente a, ver 4. Modelo de Servicio de Rol),

Y puede tener:

• Metadatos contextuales (o su equivalente a, ver 7. Modelo de Servicio de Metadatos).

Dependiendo del enfoque tomado por el SCDM en la implementación del 4. Modelo de Servicio de Rol, un acceso a la lista de control de MoReq2010® puede no presentarse durante la operación del sistema y solo puede ser añadida a una entidad de usuario a exportar.

Dependiendo del enfoque tomado por el SCDM en la implementación del 7. Modelo de Servicio de Metadatos, el mecanismo por el cual los metadatos contextuales son añadidos a entidades de usuario puede variar.



R3.4.9

El SDCM debe mantener un proceso para crear nuevos grupos en el SDCM con los metadatos y otras propiedades listadas R3.4.8.

MoReq2010® no determina como debería operar el proceso y dependiendo en la implementación especifica nuevas entidades de grupo no pueden ser creadas por usuarios de SDCM


R3.4.10

El SDCM debe mantener un proceso para actualizar el Titulo y la Descripción de un grupo activo y cualquier metadato contextual para reflejar los cambios en los detalles del grupo.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este, sin embargo los cambios en los metadatos de un grupo deben generar un evento en el historial de eventos del grupo, bajo R2.4.15, sujeto a R2.4.13.


R3.4.11El SDCM debe mantener un proceso para eliminar un grupo que nunca ha tenido usuarios añadidos a este.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este. Usuarios son añadidos a grupos, bajo R3.4.4.


R3.4.12El SDCM debe mantener un proceso para destruir un grupo que ha tenido usuarios como miembros.

MoReq2010® no determina como debería ser implementado este mecanismo, puede ser ejecutado externamente al SDCM y sincronizado después en este. Cualquier grupo al que los usuarios pertenecen o anteriormente han pertenecido, no pueden ser eliminados, solo pueden ser destruidos. Destruir un grupo dejara una entidad de grupo residual.

Bajo el Modelo de Servicio de Rol un usuario no puede heredar roles concedidos a un grupo residual al cual el usuario pertenece incluso si el usuario esta activo, ver R4.5.10.


R3.4.13El SDCM debe ser capaz de generar un reporte para un usuario autorizado listando los usuarios que estuvieron activos y pertenecieron a un grupo a una fecha y hora históricas específicas.

El reporte no incluye grupos que el usuario solicitando el reporte no está autorizado a inspeccionar. Los usuarios deben haber estado activos en la fecha y la hora especificas, pero no necesitan ser usuarios activos cuando el reporte es generado.

El reporte debe indicar si la fecha y la hora fueron dadas antes o después de que la entidad de usuario fue creada o destruida.




R3.4.14Sujeto a R2.4.22, El SDCM debe permitir a un usuario autorizado navegar e inspeccionar usuarios y grupos como mínimo de las siguientes maneras:

• Navegar a través de usuarios en el servicio de usuarios y grupos e inspeccionar sus metadatos.• Navegar a través de grupos en el servicio de usuario y grupo e inspeccionar sus metadatos.• Navegar de un usuario a los grupos a los cuales el usuario pertenece e inspeccionar sus metadatos.• Navegar de un grupo a los usuarios que pertenecen a ese grupo e inspeccionar sus metadatos.Los términos “Navegar” e “inspeccionar” son definidos en 13. Glosario de términos. Funciones de Referencia: F14.5.101, F14.5.1



4. Servicios de Modelo de Roles

4.1 Servicio de Información

Nombre del Servicio Servicio de Modelo de Roles

Versión del Servicio 1.0

Implementar identificador del servicio (véase M14.4.42)

Para un SDCM que implementa el Servicio Modelo de Roles MoReq2010®, se utiliza:

2f6d05c6-51e6-4a32-a7fc-c0a6883eb85b

Para un SDCM que implementa su propio modelo de permiso nativo, se utiliza:

d945dcd9-dc2d-491d-965a-11ce936d044b

4.2 Cumplir con el servicio de Modelo de roles

4.2.1 Falta de normas de la industria para los roles y permisos

Este modulo de MoReq2010® contiene la definición del servicio de modelo de roles con los requisitos funcionales que explica la forma en que los usuarios están autorizados para desempeñar funciones en el SDCM.

Al momento de la publicación de la Norma MoReq2010® seguía sin efecto la norma para toda la industria en cuanto a la aplicación de modelos de permisos a las entidades dentro de un sistema de información. Los modelos de servicios básicos sobre la base de crear, leer, actualizar y borrar (CRUD) son muy simples para la aplicación directa en un sistema de gestión documental. Por ejemplo, CRUD no hace ninguna diferencia entre eliminación y destrucción, y no permite retener las entidades residuales, necesarias en los sistemas de gestión documental. Teniendo en cuenta que no hay normas establecidas para la industria, los proveedores han desarrollado, con razón, sus propios métodos para controlar el acceso de los usuarios a los sistemas de gestión documental. Estos métodos de propiedad exclusiva, aunque muchas veces son muy efectivos, casi siempre son de aplicación específica y no se prestan para la interoperabilidad entre los sistemas de gestión documental, ya que los modelos de permisos de los proveedores no se pueden mapear fácilmente a otros.

4.2.2 Servicio modelo de rolesEl servicio de modelo de roles del MoReq2010® es un modelo sencillo estandarizado que se encarga de los requisitos específicos de los sistemas de gestión documental, dentro del contexto de la especificación. Se ha tenido especial cuidado para garantizar que el servicio de modelo de roles que se describe en este documento sea neutral y se base en los conceptos comunes que se encuentran en la mayoría de los sistemas de información modernos, como las listas de control de acceso y las definiciones de los roles.

Sin embargo, el servicio de modelo de roles del MoReq2010® solo puede representar un posible método de control de acceso y se reconoce que puede variar mucho del método



asumido por algunos de los sistemas de gestión documental que ya existen, para hacer que no puedan probar su cumplimiento frente al MoReq2010® sin una mayor reorganización de sus propios métodos integrados de control de acceso.

Esto presenta una dualidad: mientras que los nuevos sistemas de gestión documental tienen la oportunidad de adoptar el servicio de modelo de roles, no pueden resultar rentables para los productos que se ofrecen en el mercado.

4.2.3 Métodos de prueba y certificación frente al servicio de modelo de roles.

Por las razones mencionadas anteriormente, el DLM Forum® permite dos posibles métodos para la prueba y certificación para que los sistemas de gestión documental cumplan con el servicio de modelo de roles del MoReq2010®

CUALQUIERAA. Los Sistemas de Gestión Documental implementan en su totalidad el servicio de

modelo de roles de MoReq2010® y se prueba y certifica de acuerdo con los requisitos de este modulo.

OB. Los sistemas de gestión documental implementan sus propios modelos de permiso

nativo; en cuyo caso la aplicación debe cumplir con los siguientes criterios: • Debe demostrar que su modelo de permisos nativos es equivalente en flexibilidad

y funcionalidad con el servicio de modelo de roles de MoReq2010®, y • Debe soportar la interoperabilidad para que puedan, durante la

exportación, convertir sus permisos nativos al formato XML utilizado por el servicio de modelo de roles, de manera que los usuarios y los grupos de usuarios conserven los niveles equivalentes de acceso a las entidades y la misma autoridad para realizar funciones cuando los datos se transfieran posteriormente a otro SDCM.

4.2.4 Cómo cumplir con los requisitos alternos (Tipo B)

Para demostrar que el modelo de permisos nativos de SDCM es equivalente en flexibilidad y funcionalidad con el servicio de modelo de roles de MoReq2010®, el sistema de gestión documental debe estar en capacidad de demostrar los siguientes aspectos:

• Que el usuario no pueda tener acceso a ninguna entidad en el SDCM hasta que se le haya otorgado la autoridad de acceso a la entidad, ya sea de manera individual o como miembro de un grupo;

• Que existan usuarios que se puedan configurar y niveles de acceso múltiples a las entidades, incluyendo la capacidad discrecional para establecer los permisos de los usuarios, de manera que ellos puedan:

Descubrir algunas entidades y otras no, y Realizar algunas funciones y otras no;

• Que la autoridad para tener acceso a las entidades y realizar funciones, se pueda configurar a nivel de una entidad individual o una vez a través de todo el compendio de entidades, como una agrupación de documentos;



• Que la autoridad para tener acceso a las entidades y realizar funciones se pueda configurar de manera diferente en diferentes partes del SDCM, por ejemplo, que la autoridad del usuario para realizar funciones a algunas clases se pueda configurar de tal manera que sea diferente a la autoridad del mismo usuario sobre otras clases dentro del mismo servicio de clasificación;

• Que cuando se cree una nueva entidad, se le asigne la configuración adecuada de los permisos por defecto, por ejemplo, al capturar un documento nuevo dentro de una agrupación, debe recibir automáticamente un nivel de permisos similar al de los demás documentos en la agrupación, y

• Existen algunos tipos de roles o permisos que no los pueden bloquear los dueños de las entidades particulares, para que los usuarios que tienen esos permisos puedan administrar adecuadamente todo o parte de un SDCM.

Al convertir los metadatos para exportar desde los documentos del modelo de permisos nativos del sistema, al formato de metadatos del servicio de modelo de roles del MoReq2010®, se deben cumplir los siguientes aspectos:

• A ningún usuario se le puede conceder autorización para acceder a más entidades de las que tuvo acceso en el ambiente original,

• A ningún usuario se le puede conceder autorización para realizar funciones a las entidades que este usuario no pudo realizar a las mismas entidades en el ambiente original,

• La autoridad que se concede a través de los miembros del grupo no se deben convertir en instancias de autoridad múltiples otorgadas a los usuarios individuales.

• En lo posible, los sistemas de gestión documental deben utilizar las características de herencia del servicio de modelo de roles del MoReq2010® y evitar la adición de configuraciones repetitivas a las entradas de control de acceso a la lista de control de acceso de cada entidad hijo que este exporta, si en vez de eso, es posible atribuir una configuración única a las entradas de control de acceso a la entidad padre del hijo.

• El proveedor debe describir el algoritmo de conversión utilizado en el sistema de gestión documental y proporcionar información y ejemplos sobre la forma en que se han hecho los roles y las listas de control de acceso para la exportación de datos, con el fin de imitar con la mayor precisión posible, el servicio de modelo de roles, y

• El proveedor debe hacer el esquema del mapeo de sus permisos disponibles para incluirlo en el reporte de la prueba completa de su producto.

Más información y asesoría para los proveedores se puede solicitar al Consejo Directivo de MoReq a través de la Secretaria del DLM Forum

®

De aquí en adelante, este modulo describe los conceptos y requisitos del servicio de modelo de roles del MoReq2010®.



4.3 Conceptos importantes

4.3.1 Definición de roles

Antes de realizar cualquier función en cualquier entidad, el SDCM debe realizar siempre una revisión preliminar para determinar si el usuario que solicita la función tiene la autoridad para llevarla a cabo. La autoridad para realizar funciones se le da a los usuarios cuando se le otorgan los roles.

Como “usuario autorizado”, se define a lo largo de esta especificación, a aquel usuario autenticado correctamente (véase R3.4.1) que tiene acceso al SDCM con autorización para realizar una función.

Teniendo en cuenta que se puede otorgar el mismo rol para cualquier entidad en el SDCM, o que se puede utilizar a través de varios sistemas de gestión documental, todas las definiciones de rol se manejan a través del servicio de rol. La definición de rol representa un conjunto de definición de funciones, como se muestra en la Figura 4a

Las definiciones de rol y las definiciones de función tienen una relación de muchos-a-muchos; cualquier rol puede tener muchas definiciones de funciones asociadas con este y la misma definición de función puede estar asociada con más de un rol.

El término rol indica que el grupo de funciones que se define se selecciona de manera lógica para describir colectivamente la autoridad requerida por un miembro del personal en particular o de una posición en particular dentro de la organización, como por ejemplo, un “Funcionario Local de Documentos”.

La creación de roles en esta forma, con base en grupos de funcionalidades coherentes, es parte integral del manejo de un sistema de gestión documental. Existen muchas funciones ya definidas por la especificación MoReq2010

®, y no sería practico asignarlas a los usuario y a los grupos de usuarios de manera individual.

Figura 4a – Funciones que están asociadas con roles (todas las funciones deben estar incluidas por lo menos en un rol)

Rol 1

Rol 2 2

Rol 3 2

Rol 4 2

Función

2



4.3.2 Roles otorgados

El rol se puede otorgar ya sea a un usuario o a un grupo de usuarios en relación con cualquier entidad en el SDCM, incluyendo un servicio. La entrada de control de acceso nombrando al usuario o al grupo de usuarios y la lista de los roles que se van a otorgar, se crea y se adiciona a la lista de control de acceso a la entidad, cuando se otorga un rol. Otorgar un rol a un usuario en relación con una entidad permite que el usuario realice cualquiera de las funciones mencionadas en la definición de rol, que aplican a esa entidad.

Otorgar un rol a un grupo de usuarios en relación a una entidad tiene el efecto de otorgar el rol a cada usuario miembro de ese grupo (véase 3, Usuario y Servicio de Grupo). Los nuevos usuarios que se vinculan al grupo, heredan automáticamente el rol, mientras que los usuarios que dejan el grupo, pierden automáticamente su acceso al rol, sin que se haya otorgado o anulado el rol individualmente a cada usuario.

Se recomienda como una buena práctica, asignar roles a grupos de usuarios más que a usuarios individuales, ya que esto facilita el control del acceso de los usuarios a las entidades cuando se vinculan o abandonan la organización, y cambian de trabajo, sin tener que actualizar las listas de control de acceso para las entidades en el SDCM. Normalmente, el control a nivel de grupo es más sencillo y menos propenso a errores que el micro control para asignar y cancelar roles con frecuencia a los usuarios individuales.

La figura 4b muestra la forma en que se otorga uno o más roles a un usuario o grupo de usuarios en relación con una entidad, mediante la adición de una nueva entrada de control de acceso a la lista de control de acceso para esa entidad. Todas las entidades en el SDCM, así como los servicios, tienen una lista de control de acceso.



Figura 4b – La Lista de control de acceso está compuesta de entradas de control de acceso que conectan al usuario o al grupo de usuarios con el rol.

4.3.3 Roles heredados

Además de las entradas de control de acceso en su propia lista de control de acceso, la entidad también pude heredar los roles otorgados a los usuarios y a los grupos de usuarios de otras entidades. MoReq2010® indica en los requisitos funcionales específicos en que casos aplica la herencia en mención. Como norma general, si existe una relación padre/hijo entre entidades en toda la especificación, luego entonces la entidad hijo heredará la lista de control de acceso de su padre. Por ejemplo, la agrupación hijo hereda de su agrupación padre, así como un documento. También hay algunos casos bajo los cuales las entidades pueden heredar de múltiples fuentes, como se describe a continuación.

La herencia es un mecanismo muy importante para controlar sistemas de gestión documental muy grandes, en donde la asignación de roles frente a entidades individuales, no es nada práctico.

El modelo convencional de herencia en las entradas de control de acceso también se puede interrumpir por algunos roles, si se requiere. MoReq2010® establece normas dentro de cada lista de control de acceso por medio de una Bandera que Incluye Roles Heredados que especifica si los roles asignados a las entidades padre son heredados o no por la entidad hijo.

Si la Bandera que Incluye Roles Heredados está apagada en una lista de control de acceso a la entidad, quiere decir que solo los roles administrativos se heredarán automáticamente de su entidad padre.

Lista control

de acceso

Entidad

2Incluye

Entrada Control de Acceso

Se otorga al usuario o al grupo de usuarios

Rol 2 22

Rol 4



4.3.4 Roles Administrativos

Si tienen dos tipos diferentes de roles en MoReq2010®:

• Los roles administrativos, y • Los roles no administrativos.

El tipo de rol se especifica como parte de la definición del rol.

Luego de ser otorgado a través de un servicio como un todo, o por cualquier entidad padre, El rol administrativo aplica siempre a todas las entidades que se heredan de este servicio o entidad. En esta caso, los roles administrativos anulan la configuración de la Bandera que Incluye los Roles Heredados para las entidades hijo.

En comparación, los roles no administrativos solo serán heredados por una entidad hijo, si la lista de control de acceso de la entidad hijo está configurada para incluir roles heredados.

En la Figura 4c se muestra un ejemplo de este caso. En este ejemplo, el Role 2 es un rol administrativo, mientras que el role 4 está configurado como un rol no administrativo. La entidad Hijo 1 está configurada para incluir roles heredados y hereda como es debido tanto del Rol 2 como del Rol 4. Sin embargo, la entidad Hijo 2 no incluye roles heredados y por lo tanto solo heredará el Rol administrativo 2.

Figura 4c – Los roles administrativos anulan la función de la Bandera que Incluye los Roles Heredados y siempre se heredan de las entidades padre.

EntidadPadre

Rol 2Es Rol Administrativo = SI

Rol 4Es Rol Administrativo = NO

Hijo 1 heredaTodos los roles

Rol 2

Rol 4

Hijo 2 hereda solo los roles administrativos

Hijo 1Hijo 2

Incluye Roles de Herencia = SI Incluye Roles de Herencia = NO

Lista control

de acceso



4.3.5 Herencia Múltiple

Como se mencionó anteriormente, hay algunas partes de la especificación MoReq1010® en donde una entidad puede heredar roles de más de una entidad.

Por ejemplo, las agrupaciones y los documentos que son conservados por el servicio de documentos heredarán el control de acceso configurado de ambos, de su agrupación padre y de su clasificación, como se muestra en la Figura 4d. Si esto ocurre, la entidad heredará los roles de su padre y de su clase. Naturalmente, si la bandera de herencia de todos los roles se apaga, luego entonces la entidad hijo heredará solo los roles administrativos de estas entidades.

Figura 4d – Algunas veces las listas de control de acceso pueden ser heredadas de más de una fuente

Esta distribución permite que las diferentes organizaciones configuren el acceso a los documentos tanto a nivel de clasificación como a nivel de agrupación.

4.3.6 Roles configurados previamente

Es una práctica común que los sistemas de gestión documental sean instalados con un grupo de roles configurados por defecto previamente, por parte del proveedor para la conveniencia de la organización de consumidores y para que permita el uso inmediato del sistema. Si esto ocurre, un usuario autorizado puede modificar e incluso borrar, (si no se han usado) o destruir algunos de estos roles configurados previamente, mientras que hay otros roles que el proveedor configuró previamente como fijos y que se mantienen inalterables dentro de esta solución particular de SDCM.

Clase

Servicio o Agrupación

Padre

Lista control

de acceso

Agrupación o documento

Hijo



MoReq2010® permite que los proveedores proporcionen uno o más roles pre configurados dentro de sus productos incluyendo roles fijos, siempre y cuando estén documentados como parte del informe de verificación de prueba, y que el SDCM también pueda incluir funcionalidades para que los usuarios puedan crear, modificar y destruir las definiciones de sus propios roles personalizados, de conformidad con los siguientes requisitos y con las políticas de gestión de documentos establecidas por la organización consumidora.

Tenga en cuenta que mientras los proveedores pueden pre configurar alguno roles como fijos dentro de su propia solución SDCM, estos roles no necesariamente continúan como fijos cuando las entidades y sus roles asociados se transfieren a otra solución SDCM.



8. Servicio de Programación de Eliminación9

8.1 Información sobre el servicio

Nombre del Servicio Servicio de Programación de Eliminación


Implementa el Identificador del servicio (ver M14.4.42)

fd05e284-181f-4f5d-bd8c-4bed835c8931

8.2 Conceptos clave

8.2.1 Ciclo de vida del documento en MoReq2010®

Los programas de eliminación se utilizan para administrar el ciclo de vida de los documentos en todas las soluciones que cumplen con el Sistema de Documentos MoReq2010 -SDCM (por sus siglas en inglés).

Un archivo, una vez que se ha creado en un SDCM, nunca se puede eliminar completamente como si nunca hubiera existido. Este concepto de seguridad es importante para una buena gestión de documentos: aunque el archivo completo y su contenido ya no existen, sigue existiendo un archivo residual para demostrar que una vez éste habría sido manejado por el SDCM. El archivo residual, que se mantiene con el SDCM durante toda la vida del sistema, prueba no solo que el archivo estuvo una vez activo sino, y posiblemente lo más importante, que el archivo se eliminó de forma adecuada bajo un cronograma de disposición apropiado.

La transición de una entidad activa con metadatos completos, historia y contenido de la entidad a una entidad residual se conoce como “destrucción” para distinguirla de “eliminación” (en el que todas las trazas de una entidad se eliminan). MoReq2010® también aplica este concepto a otras entidades diferentes a los documentos, como agrupaciones, clases, cronogramas de disposición, etc. La destrucción es un proceso irreversible porque partes de la entidad se borran de modo que la entidad no se puede volver a activar. La Figura 8a da una visión general simple del ciclo de vida del archivo del MoReq2010®, la cual toma en consideración solo dos eventos: la creación del archivo en el SDCM como una entidad activa y su posterior destrucción.

Note que a diferencia del ciclo de vida de la entidad genérica que se mostró anteriormente en la Figura 2g, con los documentos en particular no existe el concepto de “primer uso” ni un período inmediatamente posterior a la creación en el que se pueda borrar el archivo. La figura simple mostrada en la Figura 8a se ampliará más adelante, en donde ciclos de vidas de

9 Nota del Traductor: Dado que el proceso de gestión de archivos incluye el definir la conservación, la transferencia, la eliminación y/o la destrucción de los archivos se traduce el término “disposal” no como eliminación sino como “disposición” en el sentido de asignar a cada paso del proceso una acción diferente sobre los archivos y no solo la eliminación/destrucción de estos. Del mismo modo, para mantener la congruencia, en el Capítulo 9, el término “disposal hold” se traduce como “disposición retenida” antes que eliminación o destrucción retenida.



documentos más detallados mostrarán cómo cada acción de disposición tiene su propia variación del ciclo de vida del archivo.

Evento de creación Evento de destrucción ACTIVO RESIDUAL

Componente(s) creado(s) Componente(s) destruido(s)Inicia el historial de eventos Historial de eventos recortadaMetadatos capturados Metadatos recortadosTiempo

Figura 8a – Vista simple del ciclo de vida de un documento

Como se muestra en la Figura 8a, cuando un archivo activo se crea sus componentes y el contenido de su componente se crean de forma simultánea, se capturan los metadatos para el archivo y sus componentes, y se inicia la historia de eventos del archivo con el evento de creación. Cuando un archivo activo posteriormente es destruido sus metadatos y la historia de eventos se recorta, junto con los metadatos y la historia de eventos de sus componentes, y lo que es más importante, el contenido del componente del archivo se borra.

Los eventos y los elementos de los metadatos que se recortarán automáticamente en el momento de la destrucción de una entidad pueden ser configurados por un usuario autorizado



(ver R2.4.20 and R7.5.6). Los metadatos restantes del archivo, junto con su historia de eventos restante, conforman el archivo residual y sus componentes residuales.

El recorte de eventos y metadatos de un archivo residual que ha sido destruido anteriormente, también puede hacerlo un usuario autorizado, por lo general en respuesta a una orden o sentencia judicial (R2.4.21 y R7.5.7). Cada cierto tiempo un archivo en particular, incluyendo sus metadatos y eventos, se debe purgar porque una corte/juzgado considera que mantener su existencia es problemática o injusta.

Una consideración secundaria en el recorte de metadatos y las historias de eventos en el momento de la destrucción es la capacidad de almacenamiento, ya que los documentos residuales se mantienen durante toda la vida del SDCM.

8.2.2 Cronogramas de eliminación y acciones de eliminación

En la gestión de documentos, los cronogramas de eliminación son críticos ya que MoReq2010®

especifica que un archivo en una SDCM solo pueden destruirse como parte de un proceso de eliminación, el cual está regido por el cronograma de eliminación que le ha sido asignado a ese archivo. Es el cronograma de eliminación del archivo el que determina por cuánto tiempo un archivo se conserva y cómo es su posterior eliminación al final de su período de conservación. Por esta razón, todos los documentos deben tener un cronograma de eliminación.

Aunque todos los cronogramas de eliminación deben cumplir con el proceso de eliminación de MoReq2010®, estos pueden especificar funcionamientos muy diferentes. El cronograma de eliminación de un archivo puede establecer que este se debe conservar de forma permanente y nunca destruirse. Un cronograma de eliminación diferente puede establecer que el archivo sea eliminado inmediatamente. Pero otro cronograma de eliminación puede establecer que el archivo sea revisado al final de su período de conservación, y así sucesivamente.

Cada uno de estos ejemplos da como resultado una acción de eliminación diferente. MoReq2010® requiere que todos los cronogramas de eliminación especifiquen uno de cuatro posibles resultados:

• Conservar de forma permanente• Revisar al final del período de conservación• Transferencia al final del período de conservación• Destrucción al final del período de conservación

8.2.3 Cálculo del período de conservación

Cada cronograma de eliminación tendrá un período de conservación definido como un número de días, semanas, meses o años. El período de conservación empieza en una fecha de inicio de conservación particular, la cual está definida por un evento que da inicio a la conservación. Los eventos que dan inicio a la conservación pueden estar relacionados con el archivo individual o con la agrupación padre del archivo.

Las organizaciones que prefieren gestionar las agrupaciones completas, y eliminarlas de forma colectiva, deberán especificar los activadores de conservación relacionados con la agrupación para sus cronogramas de disposición. También deberán evitar clasificar los documentos de forma individual dentro de las agrupaciones. Los siguientes activadores de conservación se relacionan con la agrupación padre del archivo:



• A partir de la fecha en que se originó la agrupación • A partir de la fecha de la adición más reciente a la agrupación• A partir de la fecha en que se cerró la agrupación, y • A partir de una fecha especificada por un elemento de metadatos contextuales

asociados a la agrupación.

Por contraste, los siguientes activadores de conservación se relacionan con documentos individuales. Cuando estos activadores de conservación son usados, los documentos serán eliminados de forma selectiva de sus agrupaciones padre en diferentes momentos, mientras que otros documentos en las mismas agrupaciones se mantienen activos:

• A partir de la Fecha/Hora de origen del archivo • A partir de la fecha en que el archivo se agregó a la agrupación padre, y

• A partir de una fecha especificada por un elemento de metadatos contextuales asociados al archivo.

Los siguientes activadores de conservación se pueden aplicar tanto a los documentos individuales como a las agrupaciones:

• Conservar de forma permanente (allí no existe un activador de conservación) • A partir de ahora (es decir con efecto inmediato), y

• A partir de la fecha de la última revisión.

La fecha de inicio de conservación para un archivo debe ser calculada nuevamente por un SDCM si el cronograma de disposición del archivo cambia o si el valor al cual se refiere el activador de conservación se actualiza, por ejemplo, siempre que:

• Un cronograma automático de eliminación de documentos se reemplace mediante un cambio (ver R5.4.4) o una reclasificación del archivo (ver R5.4.8, R6.5.4 y R6.5.12),

• La agrupación padre de un archivo se cierra (ver R6.3.7), o• Un cronograma automático de disposición de documentos es reemplazado por uno

aplicado directamente al archivo (ver R6.5.15).

Además de los anteriores, todos los siguientes son posibles activadores de conservación y los cambios a ellos también pueden dar como resultado un nuevo cálculo de la fechas de inicio de conservación:

• La Fecha/Hora de Creación del archivo se cambia (ver R2.4.26), • Un cronograma automático de eliminación de documentos se reemplace moviéndolo, o

a su padre, a una nueva agrupación (ver R6.5.8 y R6.5.13), o• Un elemento de metadatos contextuales asociados a la agrupación se modifica (ver

R8.4.4).

Debe anotarse que MoReq2010® ve la disposición más como una actividad programada y por lo tanto no requiere que los activadores de conservación sean revisados y las fechas de inicio de la conservación se calculen más de una vez al día. Se asume que nuevos lotes de documentos serán aptos para su disposición diariamente y las rutinas de la gestión de documentos se planearán en torno a esto. Sin embargo, bajo R8.4.14, es posible que un usuario autorizado solicite de forma individual la actualización inmediata del estatus de una disposición de documentos por el SDCM.

También hay que anotar que MoReq2010® requiere que la Fecha/Hora de Creación de los



documentos y las agrupaciones se utilicen para calcular las fechas de conservación, y no la Marca de Tiempo de Creación para estas entidades. Esto permite la interoperabilidad entre sistemas de documentos mientras se mantiene la continuidad a lo largo del ciclo de vida del archivo. Cada vez que un archivo o agrupación se importa a un nuevo sistema de documentos, este será creado nuevamente en ese sistema. Tendrá una nueva marca de Tiempo de Creación que reflejará cuando ha sido importado al nuevo SDCM, pero en comparación el valor establecido en el SDCM anterior para la Fecha/Hora de Creación no será actualizado cuando el archivo o la agrupación se han importado.

Una consecuencia de lo anterior, es que la fecha de inicio de conservación para un archivo puede ser anterior al evento de creación del archivo. Por ejemplo, si un nuevo archivo se crea en la agrupación y dado un cronograma de disposición con el activador de conservación basado en la Fecha/Hora de Creación de su archivo padre, entonces el período de conservación para el archivo habrá efectivamente comenzado antes de la creación del archivo. Esta circunstancia no se muestra en ninguna de las ilustraciones que se incluyen, como las Figuras 8c, 8d y 8e, que para facilitar su comprensión siempre muestran una fecha de inicio de conservación posterior a la fecha de creación del archivo.

8.2.4. Confirmación de la eliminación de un archivo

Además de la acción de eliminación, el activador de conservación y el período de conservación, un cronograma de eliminación debe también especificar un período de confirmación. El período de confirmación representa el período de tiempo permitido para llevar a cabo la acción de eliminación. La duración del período de confirmación variará de una organización a otra, y también puede ser diferente en los diferentes cronogramas de eliminación.

El significado preciso del período de confirmación depende de la acción de eliminación escogida. Para las revisiones, el período de confirmación representa el tiempo asignado para completar la revisión y aplicar la decisión de revisión. Para las acciones de destrucción, el período de confirmación representa el tiempo asignado para borrar el contenido de un archivo y confirmar que este ha sido borrado.

Las acciones de transferencia tienen dos períodos de confirmación. Primero los documentos deben ser transferidos a su nueva ubicación fuera de la gestión del SDCM. Esto normalmente involucra exportar los documentos desde el SDCM. Con la confirmación de que la transferencia se ha completado, la acción de disposición cambia de transferencia a destrucción y el proceso de disposición introduce un segundo período de confirmación para asegurar que el contenido del archivo que estaba en el SDCM ha sido destruido.

Si se sobrepasa el período de confirmación sin que el SDCM haya recibido la confirmación necesaria de que la acción de disposición se ha completado, entonces el SDCM emite una alerta, que se envía a los usuarios autorizados, indicando que la disposición de los documentos correspondientes se ha vencido. El objetivo de esta medida es asegurar que los documentos son eliminados oportunamente en el plazo más corto posible después de la fecha de vencimiento de la disposición.

8.2.5 Ciclo de vida de la conservación permanente

Un aspecto importante de la gestión de documentos es la conservación de documentos importantes por períodos de tiempo muy largos, incluyendo la posibilidad de designar algunos documentos que nunca deberán ser eliminados. En MoReq2010®, esto se hace



aplicando un cronograma de disposición con un activador de conservación que especifique la conservación permanente. Este tipo de cronograma de disposición, sin un activador de conservación, tiene el efecto de prevenir el cálculo de una fecha de inicio de conservación y un período de conservación posterior. En la Figura 8b, se muestra el efecto de la conservación permanente, que puede contrastarse con el ciclo de vida simple ilustrado en la Figura 8a.

Evento de creaciónCONSERVAR PERMANENTEMENTETiempo ACTIVO

Figura 8b – Si su programación de eliminación especifica que la conservación sea permanente, entonces no se establece una fecha de inicio de conservación para un

documento y, sin que se cambia su programación de eliminación, este se mantendrá activo durante toda la vida del SDCM.

8.2.6 Revisión del ciclo de vida

MoReq2010® promueve que, siempre que sea posible, la disposición siga a, y sea determinada por, la clasificación. Esto significa que el período de tiempo en que un archivo se mantiene y su método de disposición están basados en su clasificación de negocio. Este principio de buena práctica de gestión de documentos a veces se conoce como su “condena en el momento de la creación”.

Sin embargo, puede haber ocasiones en que la importancia de un archivo y el período de tiempo en que se debe mantener no se conocen en el momento de su creación, y no se puede calcular de forma simple a partir de eventos posteriores, como el cierre de la agrupación en la que se coloca el archivo. También puede ocurrir que en algunas jurisdicciones el período de conservación es tan largo que se considera que la guía para su conservación puede cambiar en el ínterin. Por ejemplo, si se requiere que una clase determinada de documentos se destruya después de 40 años, un administrador de documentos puede argumentar que existe la posibilidad de que en 40 años la regla de disposición de los 40 años haya sido actualizada. En estas circunstancias, en donde haya una duda razonable acerca de su destino final, se puede programar a los documentos para una revisión posterior, antes que programarlos para conservación permanente, transferencia o destrucción.

Cuando se propone examinar una acción de disposición de un archivo, este no es sujeto de transferencia o destrucción inmediata. En cambio, el resultado de la revisión debe incluir la aplicación de un cronograma de disposición al archivo sobre la base de la decisión de revisión. El nuevo cronograma de disposición reemplazará el cronograma de disposición anterior



asociado con el archivo, y luego especificará el destino final del archivo, o puede ser utilizado para programar una revisión posterior, o para retener el archivo de forma permanente.

La Figura 8c muestra como el completar una revisión resulta en la aplicación de un nuevo cronograma de disposición al archivo, que a su vez forzará el cálculo de una nueva fecha de inicio de conservación, acción de disposición y período de confirmación. El proceso de disposición por lo tanto seguirá y podrá dar lugar a períodos de revisión adicionales. Note que detener la disposición no interrumpe el proceso de revisión, solo previene la eventual destrucción de un archivo.

Creation event= Evento de creación Retention start date= Fecha de inicio de conservaciónRetention period= Período de retenciónDisposal due date (Review)= Fecha de vencimiento de la eliminación (REVISIÓN)Review confirmation= Confirmación de revisiónReview completed= Revisión terminadaRetention start date (nueva)= Fecha de inicio de conservación (nueva)Retention period= Período de retenciónACTIVE= ACTIVO New disposal schedule applied= Nuevo programa de eliminación aplicadoTime= Tiempo

Figura 8c – Si su cronograma de disposición especifica que un archivo debe ser revisado, entonces un nuevo cronograma de disposición se debe aplicar al archivo para completar e

implementar la decisión de revisión

8.2.7 Ciclo de vida de la transferencia

Un cronograma de disposición puede establecer que el control de un archivo sea transferido a otro sistema de documentos, por ejemplo, un sistema de documentos corporativo más centralizado, instalaciones de almacenamiento secundarias, o a un archivo. La transferencia ocurre en dos fases. Los documentos se deben exportar primero del SDCM e importarlos a otro sistema de archivo. Al confirmar que la transferencia se ha realizado y que el sistema de



destino los ha recibido exitosamente, el SDCM cambia la acción de disposición de los documentos de transferencia a destrucción, y posteriormente son destruidos.

La Figura 8d muestra el ciclo de vida de un archivo al que se le aplica una acción de disposición de transferencia. El archivo no se destruye hasta que un usuario autorizado ha confirmado el éxito de la transferencia. Cuando la disposición del archivo se detiene, la primera fase de la transferencia puede continuar, sin embargo el proceso de disposición se debe detener antes de la segunda fase: la destrucción del archivo.

Disposal due date (TRANSFER) =Fecha de vencimiento de la eliminación (TRANSFERENCIA)Transfer confirmation= Confirmación de la transferenciaTransfer confirmed= Transferencia confirmadaDisposal due (DESTROY)= Eliminación (DESTRUCCIÓN)Destroy confirmation= Confirmación de destrucción Destruction complete= Destrucción completaACTIVE= ACTIVORESIDUAL= RESIDUALDisposal holds will interrupt the process here= Las retenciones de la eliminación interrumpirán el proceso aquí

Figura 8d – Si su cronograma de disposición especifica la transferencia de un archivo entonces éste es destruido en el SDCM, pero solo después de que se ha confirmado que la

transferencia se completó.

MoReq2010® permite que las transferencias se cancelen. Si la transferencia se cancela se le debe dar al archivo un nuevo cronograma de disposición; el resultado por lo tanto deberá ser similar a la revisión que se nuestra en la Figura 8c.

8.2.8 Ciclo de vida de la destrucción

La Figura 8d muestra el ciclo de vida de un archivo al que se le aplica una acción de disposición de destrucción. La destrucción de archivo, ya sea en respuesta a una acción de disposición, o como la segunda fase de una transferencia, está sujeta a restricciones particulares. Si se aplica una disposición retenida al archivo, entonces el SDCM deberá



marcar el archivo como retenido y evitar que sea destruido. En este caso el período de confirmación de la destrucción no deberá empezar hasta que la disposición retenida del archivo se levante. En el capítulo 9. Servicio de Disposición Retenida se puede encontrar más información acerca de las eliminaciones detenidas.

Es importante resaltar que una vez que un proceso de disposición ha entrado en el período de confirmación no es posible imponer una disposición retenida para evitar la destrucción del archivo. Esto es porque se asume que la instrucción de destruir el contenido ya se ha dado y solo se está esperando la confirmación de que esto ha ocurrido. Una vez la instrucción se ha emitido, MoReq2010

® no hace ninguna provisión para retirar la instrucción,

y por lo tanto, evitar la destrucción del archivo está fuera del control del SDCM.

Disposal due date (DESTROY)= Fecha de vencimiento de la eliminación (DESTRUCCIÓN

Figura 8e – Si su programación de eliminación especifica la destrucción de un documento, entonces por lo general existe un período de confirmación después de la fecha de

vencimiento de la eliminación.

Cómo se destruyan los documentos en un SDCM dependerá de la naturaleza del contenido de sus componentes. Esto a su vez dependerá del diseño y propósito del SDCM. Cuando se crean los documentos en un SDCM, sus componentes se crearán con contenidos a los que el SDCM le es posible borrarlos automáticamente o con contenidos que requieren confirmación de la eliminación. Esto está determinado por la Bandera de Eliminación Automática incluida en los metadatos de un componente, y bajo R6.5.19.

Un SDCM que gestiona directamente su propio repositorio de contenidos es más probable que sea capaz de automáticamente borrar el contenido de sus componentes cuando los documentos son destruidos. Es más probable que un SDCM que gestiona los documentos en el sitio, en otros sistemas de negocios, o documentos con contenido físico antes que digital, necesite recibir una confirmación separada de la destrucción del contenido de los documentos cuya destrucción estaba programada.

MoReq2010® no limita la arquitectura de las soluciones de SDCM de forma tal que estos puedan destruir el contenido de un archivo de forma automática. MoReq2010® tampoco



especifica que todas las soluciones de SDCM deban poder soportar los componentes de un archivo que requieran confirmación. Muchas soluciones de SDCM soportarán ambos tipos de contenidos o permitirán que se configuren diferentes tipos de contenidos. Los proveedores deberán poder construir y soportar cualquiera de estas opciones en sus productos.

Por esta razón, el proceso de disposición de MoReq2010® especifica que cuando un archivo debe destruirse, el SDCM debe revisar sus componentes para determinar si pueden destruirse automáticamente o si deben destruirse después de la confirmación. El SDCM entonces esperará la confirmación de la destrucción del contenido de cualquiera de los componentes que no pueden ser destruidos de forma automática, antes de destruir los componentes restantes y el archivo en sí.

Note que este enfoque, donde la destrucción automática no está especificada como un atributo del cronograma de disposición, sino que es una función de la naturaleza del contenido del archivo, así como el diseño y la implementación del SDCM, difiere de las versiones anteriores de MoReq

®.

8.2.9 Eliminación ascendente

Bajo MoReq2010®, los cronogramas de eliminación solo se aplican a los documentos; no se aplican a las agrupaciones. Esto es diferente a las versiones anteriores de la especificación. Las agrupaciones tienen clases pero no tienen cronogramas de eliminación, en su lugar la destrucción de las agrupaciones las gestiona de forma automática el SDCM aplicando el principio de eliminación ascendente.

Bajo este principio, los documentos individuales en una agrupación pueden ser eliminados en diferentes momentos. Cuando esto ocurre el archivo destruido se convierte en un archivo residual pero no tiene impacto sobre los otros documentos, ya sean activos o residuales, en la misma agrupación. Tampoco tiene impacto en la agrupación en sí misma, hasta que el último archivo activo en la agrupación se ha destruido.

La eliminación ascendente significa que cuando el último archivo activo en una agrupación se ha destruido entonces la agrupación en si será destruida de forma automática por el SDCM. Sin embargo, la destrucción automática de una agrupación solo tiene lugar cuando la agrupación está cerrada. Una agrupación abierta no puede ser destruida. Si en el momento de la destrucción del último archivo activo la agrupación ya está cerrada, o si más tarde la agrupación se cierra, entonces esta será destruida de forma automática, siempre y cuando no se le hayan agregado más documentos activos.

También es importante anotar que una agrupación, ya sea que esté abierta o cerrada, no podrá ser destruida de forma automática si nunca ha sido utilizada, aunque, en su lugar, una agrupación que nunca ha sido utilizada puede ser borrada.

La Figura 8f muestra cómo se aplica la destrucción ascendente tanto a agrupaciones abiertas como cerradas cuando el último archivo en la agrupación se ha destruido.



Aggregation remains open= La agrupación se mantiene abiertaOPEN= ABIERTOAggregation= Agrupación Destroy last record= destruir último documentoRecord= Documento Aggregation destroyed= Agrupación destruidaCLOSED= CERRADO

Figura 8f – De acuerdo con el principio ascendente de eliminación, cuando el último archivo en una agrupación es destruido, entonces la agrupación será destruida de forma

automática, pero solo cuando esta ha sido cerrada

La eliminación ascendente no solo afecta a las agrupaciones que contienen documentos, también afecta a las que contienen otras agrupaciones. Una agrupación padre será eliminada de forma automática por un SDCM cuando todas agrupaciones hijas hayan sido eliminadas. Se aplica la misma regla, la agrupación padre debe estar cerrada.

Este efecto acumulativo de la eliminación de agrupaciones en forma de cascada hacia arriba, se muestra en la Figura 8g.

Parent aggregation is distroyed= La agrupación padre es destruidaWhen last aggregation is destroyed= cuando la última agrupación es destruida



Aggregation= AgrupaciónDestruir el último documentoRecord= documento

Figura 8g – Una agrupación cerrada se eliminará de forma automática cuando todas sus entidades hijas, ya sean documentos u otras agrupaciones, hayan sido destruidas; esto

puede activar la destrucción de su agrupación padre, y así sucesivamente

8.2.10 Conflictos en la eliminación

Algunas especificaciones para sistemas de documentos, incluyendo las versiones anteriores de MoReq® permiten que ocurran conflictos en la eliminación cuando dos o más cronogramas de disposición se aplican simultáneamente sobre el mismo archivo. El conflicto de disposición resultante deberá ser gestionado, ya sea por la intervención manual del usuario para resolver la ambigüedad, o mediante la implementación de un algoritmo que determine cuál de los cronogramas de disposición en conflicto es más importante y por lo tanto tener prioridad.

MoReq2010® ha sido deliberadamente diseñada para evitar conflictos de disposición de esta naturaleza al asegurar que a cada archivo se aplica un, y solo un, cronograma de disposición en cualquier momento. El cronograma de eliminación que se aplica inicialmente a cada archivo es el cronograma automático de disposición asociado con la clase del archivo. Este cronograma automático de disposición puede entonces ser reemplazado por un usuario autorizado aplicando un cronograma de disposición diferente directamente al archivo en sí. El nuevo cronograma de disposición puede ser reemplazado, y así sucesivamente, teniendo previsto que el archivo siempre tiene un solo cronograma de eliminación.

La razón más común por la cual un cronograma de eliminación de un archivo será reemplazado es para aplicar un nuevo cronograma de disposición como resultado de una decisión de revisión.

A continuación un ejemplo del ciclo de vida de un archivo:

• Se crea un archivo con un cronograma automático de eliminación heredado de su clase, “Revisar 2 años después de que la agrupación se ha cerrado”;

• La agrupación del archivo se cierra posteriormente;• El archivo se revisa después de dos años y, como resultado se aplica un nuevo

cronograma de disposición, “Revisar 1 año después de la última revisión”;• Un año después se revisa nuevamente el archivo y se aplica un tercer cronograma de

disposición, “Destruir en 6 meses”;• Seis meses después, o en total tres años y medio después de que se ha cerrado la

agrupación del archivo, el SDCM destruye el archivo.

En este ejemplo, el archivo ha sido creado con un cronograma automático de disposición, el cual ha sido reemplazado dos veces durante la vida activa del archivo. Sin embargo, en cualquier momento en el tiempo, el archivo estará sujeto a un solo cronograma de disposición y seguirá solo un proceso de disposición. En esta forma, MoReq2010® garantiza que un SDCM nunca tendrá que manejar conflictos de disposición o ambigüedades.



8.2.11 El proceso de eliminación

Un SDCM debe asegurar que se realice de forma periódica un proceso de eliminación para cada uno de sus documentos activos. Esto puede hacerse en tiempo real o puede hacerse como una actividad programada, pero MoReq2010® especifica que debe hacerse diariamente de forma tal que cada uno de los usuarios autorizados pueda llevar a cabo actividades de gestión de documentos sobre los documentos de los que debe eliminarse.

El diagrama de flujo en la Figura 8h da una visión lógica del proceso de eliminación para cada archivo y muestra los diferentes puntos de decisión y el procesamiento requerido.

Este diagrama está diseñado para representar visualmente los requisitos funcionales contenidos en esta sección y está considerado como una visión lógica. De ninguna manera está optimizado, y no está destinado para ser reproducido en código, siempre que las soluciones de SDCM proporcionen los mismos resultados como los descritos por el proceso para la misma información de entrada.



1 INICIO Para cada documento, revisar su programación de eliminación 2 ¿Conservar de forma permanente?3 ¿Se ha activado la conservación?4 Fijar fecha de inicio, fecha de vencimiento de la eliminación, y acción de eliminación5 ¿Se ha alcanzado la fecha de vencimiento de la disposición?6 FIN7 FIN 8 ¿Es la acción de disposición DESTRUIR?9 Fijar fecha de confirmación de disposición10 ¿Puede destruirse de forma automática todo el contenido?11 ¿Existe una acción de disposición en espera?12 Marque el archivo como detenido/en espera13 FIN14 ¿Se ha confirmado la disposición?15 ¿Se alcanzó la fecha de confirmación?16 ¿Se ha emitido la alerta de vencimiento de la disposición?17 Emita alerta de vencimiento de la disposición18 FIN19 ¿Es la acción de disposición TRANSFERENCIA?20 Transferencia confirmada, cambie la acción de disposición a DESTRUIR21 Destruir archivo, componentes y contenido22 ¿Existen más entidades en la agrupación padre?23 ¿Está cerrada la agrupación padre?24 Destruir la agrupación25 ¿La agrupación tiene un padre?26 FIN27 ¿Es la acción de disposición REVISAR?28 Revisión completa, aplique nuevo cronograma de disposición29 Destrucción confirmada



Figura 8h – El proceso de eliminación integrado que muestra todas las alternativas de eliminación previstas dentro de MoReq2010®

8.2.12 El Cronograma de eliminación como un servicio

MoReq2010® describe la programación de disposición como un servicio usado por un SDCM. La mayoría del software de SDCM tendrá incorporado un servicio de programación de la eliminación, sin embargo también es posible que en el futuro se puedan crear servicios de programación de disposición autónomos que permitan la gestión centralizada de los cronogramas de disposición de una organización a través de múltiples soluciones de SDCM. Un posible uso de dicho servicio podría ser que una autoridad emita y mantenga un conjunto de cronogramas de disposición de una industria en la forma de un servicio de programación de la disposición, el cual esté disponible en Internet, y pueda ser usado por un sector particular.

8.4 Requisitos funcionales

R8.4.1

El SDCM debe permitir a un usuario autorizado crear nuevos cronogramas de disposición (E14.2.6) con los siguientes metadatos del sistema:

• Identificador del sistema (M14.4.100),



• Marca de Tiempo de Creación (M14.4.9),• Fecha/Hora de Creación (M14.4.61),• Marca de tiempo del Primer Uso (M14.4.32),• Título (M14.4.104),• Descripción (M14.4.16),• Mandato (M14.4.51),• Notas de aplicación (M14.4.97),• Código de Acción de Disposición (M14.4.18),• Código del Activador de la Conservación (M14.4.94),• Identificador del Elemento del Activador de Conservación (M14.4.95, o su

equivalente),• Código del Intervalo del Período de Conservación (M14.4.90),• Número de la Duración del Período de Conservación (M14.4.89),• Código del Desplazamiento del Período de Conservación (M14.4.91),• Código del Mes de Desplazamiento del Período de Conservación (M14.4.92),• Código del Intervalo del Período de Confirmación (M14.4.7),• Número de la Duración del Período de Confirmación (M14.4.6), y• Marca de Tiempo de la Destrucción (M14.4.17).

Cada cronograma de disposición también tiene:

• Historia de eventos (ver 2. Servicios del Sistema),• Lista de acceso de control (o su equivalente, ver 4. Servicio de Modelo de Roles),

Y puede tener:

• Metadatos contextuales (o su equivalente, ver 7. Servicio de Modelo de Metadatos)

Note que muchos de los elementos de metadatos del sistema arriba indicados se refieren a códigos, desplazamientos o duración. Estos pueden ser términos poco familiares. El propósito de estos controles en la disposición se explica en detalle en 14.4 Definición de los Elementos de Metadatos del Sistema, y en los requisitos del R8.4.2 al R.8.4.7.

Dependiendo del enfoque que tome el SDCM en la implementación de 4. Servicio de Modelo de Roles, una lista de control de acceso de MoReq2010® puede no estar presente durante la operación del sistema y solo se puede agregar a un cronograma de disposición durante la exportación.

Dependiendo del enfoque que tome el SDCM en la implementación de 7. Servicio de Modelo de Metadatos, el mecanismo mediante el cual los metadatos contextuales se agregan a un cronograma de disposición puede variar.


R8.4.2

El SDCM debe permitir, bajo R.8.4.1, que se asigne para uno de los siguientes valores el Código de Acción de Disposición:

• CONSERVACIÓN PERMANENTE,• REVISIÓN,• TRANSFERENCIA, o • DESTRUCCIÓN.



Siempre que al Código de la Acción de Disposición se le asigne CONSERVACIÓN PERMANENTE, el SDCM deberá garantizar que ninguno de los siguientes elementos de metadatos se incluya en el cronograma de disposición:

• Código del Activador de Conservación,• Elemento Identificador del Activador de Conservación,• Código del Intervalo del Período de Conservación,• Número de la Duración del Período de Conservación,• Código del Desplazamiento del Período de Conservación,• Código del Mes del Desplazamiento del Período de Conservación,• Código del Intervalo del Período de Confirmación, o• Número de la Duración del Período de Confirmación.

Siempre que al Código del Activador de Conservación no se le asigne CONSERVACIÓN PERMANENTE, el SDCM deberá garantizar que al menos los siguientes elementos de metadatos del sistema también están incluidos en el cronograma de disposición:

• Código del Activador de Conservación,• Código del Intervalo del Período de Conservación,• Código del Intervalo del Período de Confirmación, y• Número de la Duración del Período de Confirmación.

Un Código de Acción de Disposición de CONSERVACIÓN PERMANENTE se usa para asegurar que los documentos no se destruyan nunca. Los elementos de metadatos en la lista no son aplicables a los documentos que se deben conservar permanentemente.

Otro Código de Acción de Disposición, MANTENER EN ESPERA, el SDCM lo aplica de forma automática a los documentos, bajo R8.4.21, pero puede no ser usado en los cronogramas de disposición.

R8.4.3

Cuando se incluye en un cronograma de disposición, bajo R8.4.2, el SDCM deberá permitir que se asigne el Código del Activador de Conservación, bajo R8.4.1, a uno de los siguientes valores:

• A PARTIR DE AHORA• A PARTIR DE LA FECHA DE LA ÚLTIMA REVISIÓN• A PARTIR DE LA FECHA DE CREACIÓN DEL ARCHIVO • A PARTIR DE LA FECHA DE CREACIÓN DE LA AGRUPACIÓN• A PARTIR DE LA FECHA EN QUE SE AGREGÓ A LA AGRUPACIÓN• A PARTIR DE LA FECHA DE LA ÚLTIMA ADICIÓN A LA AGRUPACIÓN• A PARTIR DE LA FECHA DE CIERRE DE LA AGRUPACIÓN• A PARTIR DE LA FECHA DE LOS METADATOS DEL ARCHIVO • A PARTIR DE LA FECHA DE LOS METADATOS DE LA AGRUPACIÓN

Siempre que al Código del Activador de la Conservación se le asigne A PATIR DE LA FECHA DE LOS METADATOS DEL ARCHIVO, el SDCM debe asegurar que siempre se incluya en los metadatos de un cronograma de disposición un Identificador del Elemento del Activador de Conservación. Este no se debe incluir en los metadatos de un cronograma de disposición para cualquier otro valor del Código del Activador de la Conservación.

El Identificador del Elemento del Activador de Conservación indica que elemento de los metadatos



asociado con el archivo o con la agrupación padre del archivo se usará para obtener su Fecha de Inicio de Conservación.

Un Código del Activador de Conservación con valor A PARTIR DE AHORA es usado como un medio para iniciar el período de conservación para un archivo inmediatamente, sin esperar un activador específico.

Otros activadores de conservación relacionados con elementos de metadatos específicos, especificados ya sea en R6.5.10 para documentos o en R6.5.1 para agrupaciones, son:

• A PARTIR DE LA FECHA DE LA ÚLTIMA REVISIÓN utiliza una Marca de Tiempo de Última Revisión del archivo,

• A PARTIR DE LA FECHA DE CREACIÓN utiliza una Fecha/Hora de Creación del archivo,

• A PARTIR DE LA FECHA DE CREACIÓN DE LA AGRUPACIÓN utiliza la Fecha/Hora de Creación de la agrupación padre de un archivo,

• A PARTIR DE LA FECHA EN QUE SE AGREGÓ A LA AGRUPACIÓN utiliza una Marca de Tiempo de Agrupación al archivo,

• A PARTIR DE LA FECHA DE LA ÚLTIMA ADICIÓN A LA AGRUPACIÓN utiliza la Marca de Tiempo de Última Adición, y

• A PARTIR DE LA FECHA DE CIERRE DE LA AGRUPACIÓN utiliza la Marca de Tiempo de Cerrado de la agrupación padre de un archivo.

Los activadores de conservación, A PARTIR DE LA FECHA DE LOS METADATOS DEL ARCHIVO y A PARTIR DE LA FECHA DE LOS METADATOS DE LA AGRUPACIÓN utilizan un elemento de metadatos contextual asociado ya sea con el archivo o con su agrupación. Dependiendo del enfoque del SDCM al implementar 7. Servicio de Modelo de Metadatos, un método equivalente para identificar el sistema apropiado o el elemento de metadatos contextual para usar como el activador de la conservación puede ser sustituido.

Sin embargo, independientemente de si se usa el modelo de servicio de metadatos o un equivalente, el SDCM debe asegurar que el elemento de los metadatos indicado siempre:

• Tiene un Tipo de dato (ver R7.5.3) de fecha/hora o marca de tiempo; • Tiene un Máximo de Ocurrencias fijado en uno (ver R7.5.4), para asegurar que el elemento de

metadatos tiene un solo valor inequívoco; • Está asociado al archivo o su agrupación (por ejemplo, mediante la inclusión en una plantilla, o

su equivalente bajo R7.5.17 y R7.5.18); y• Puede ser convertido de forma significativa y exportado como parte de cronograma de

disposición de MoReq® compatible sin importar como está implementado en el SDCM (ver 7.2 Cumpliendo con el Servicio de Modelo de Metadatos).

R8.4.4

El SDCM no debe permitir un cronograma de disposición con un Código de Activador de Conservación de A PARTIR DE LA FECHA DE LA ÚLTIMA REVISIÓN bajo R8.4.3, se asocie a una clase como el cronograma automático de conservación de la clase. De la misma forma, un SDCM no debe permitir que un cronograma de disposición sea aplicado directamente a cualquier archivo que no haya sido previamente revisado, excepto durante la confirmación de una decisión de revisión bajo R8.4.16.



Un cronograma automático de disposición está asociado a cada clase bajo R5.4.2 y R5.4.4. Este cronograma automático de disposición es heredado y adoptado por todos los documentos bajo R6.5.14, a menos que éste sea reemplazado bajo R6.5.15.

Los cronogramas de conservación con un Código de Activador de Conservación de A PARTIR DE LA FECHA DE LA ÚLTIMA REVISIÓN solo son aplicables cuando son usados junto con una revisión, actual o anterior, del archivo. El SDCM debe evitar que estas se asocien a documentos que nunca han sido revisados. Por esta razón no pueden asociarse con una clase porque no pueden convertirse en el cronograma automático de disposición para documentos recientemente creados.

R8.4.5

Cuando esté incluido en un cronograma de disposición bajo R8.4.2, el SDCM debe permitir que al Código del Intervalo del Período de Conservación bajo R8.4.1, se le asigne uno de los siguientes valores:

• SIN PERÍODO DE CONSERVACIÓN,• DÍAS,• SEMANAS,• MESES, o• AÑOS.

Siempre que al Código del Intervalo del Período de Conservación se le asigne SIN PERÍODO DE CONSERVACIÓN, el SDCM debe asegurar que ninguno de los siguientes elementos de metadatos sea incluido en el cronograma de disposición:

• Número de la Duración del Período de Conservación,• Código del Desplazamiento del Período de Conservación, y • Código del Mes del Desplazamiento del Período de Conservación.

Siempre que al Código del Intervalo del Período de Conservación no se le asigne SIN PERÍODO DE CONSERVACIÓN, el SDCM debe asegurar que al menos los siguientes elementos de metadatos del sistema también están incluidos en el cronograma de conservación:

• Número de la Duración del Período de Conservación, y• Código del Desplazamiento del Período de Conservación.

Si al Código del Intervalo del Período de Conservación se le asigna SIN PERÍODO DE CONSERVACIÓN, entonces la Fecha de Vencimiento de la Acción de Disposición será la misma que la Fecha de Inicio de la Conservación. En otras palabras, la duración del período de conservación es de cero días y la acción de disposición vence inmediatamente tan pronto como se activa el período de conservación.

Cuando la Duración del Intervalo del Período de Conservación se incluye en el cronograma de disposición, este deberá ser un número entero mayor a cero. Este es entonces interpretado junto con el Código del Intervalo del Período de Conservación ya sea como un número de días, semanas, meses o años. Por consiguiente el período de conservación más corto, después de SIN PERÍODO DE CONSERVACIÓN, es un día.

R8.4.6

Cuando esté incluido en un cronograma de disposición bajo R8.4.2, el SDCM debe permitir que al Código del Desplazamiento del Período de Conservación bajo R8.4.1 se le asigne uno



de los siguientes valores:

• SIN DESPLAZAMIENTO• INICIO EN EL SIGUIENTE MES • INICIO EN EL SIGUIENTE TRIMESTRE• INICIO DE UN MES ESPECÍFICO

Cuando al Código del Desplazamiento del Período de Conservación se le asigna SIN DESPLAZAMIENTO o INICIO EN EL SIGUIENTE MES, el SDCM debe asegurar que el Código del Mes del Desplazamiento del Período de Conservación no está incluido en el cronograma de disposición. Por el contrario si al Código del Desplazamiento del Período de Conservación se le asigna INICIO EN SIGUIENTE TRIMESTRE o INICIO DE UN MES ESPECÍFICO, el Código del Mes del Desplazamiento del Período de Conservación debe incluirse y se le debe asignar un valor que corresponda a un mes del año.

Un período de desplazamiento de NO DESPLAZAMIENTO significa que el período de conservación terminará exactamente en la Fecha de Vencimiento de la Acción de Disposición calculada. Un período de desplazamiento de INICIO EN EL SIGUIENTE MES significa que el SDCM deberá extender el período de conservación hasta el final del mes en que este cae.

Un período de desplazamiento de INICIO EN EL SIGUIENTE TRIMESTRE extenderá el período de conservación hasta el final del trimestre del año en que este cae. Para esta opción el Código del Mes del Desplazamiento del Período de Conservación se interpreta haciendo referencia al primer mes del primer trimestre del año. Por ejemplo, si el mes se fija en ABRIL, entonces los trimestres irán de abril a junio, de julio a septiembre, de octubre a diciembre y de enero a marzo.

Un período de desplazamiento de INICIO DE UN MES ESPECÍFICO extenderá el período de conservación hasta el final del mes anterior al inicio del mes del desplazamiento del período de conservación. Por ejemplo, para extender el período de conservación hasta el final del año calendario en el cual cae, el usuario autorizado fijará el Código del Mes del Desplazamiento del Período de Conservación a ENERO.

R8.4.7

Cuando se incluye en un cronograma de disposición bajo R8.4.2, el SDCM deberá permitir que al Código del Intervalo del Período de Confirmación bajo R8.4.1 se le asigne uno de los siguientes valores:

• DÍAS, o• SEMANAS.

El Número de la Duración del Período de Confirmación también deberá fijarse como un número entero mayor que cero.

El período de confirmación se refiere al máximo período de tiempo asignado para completar una acción de disposición incluida bajo R8.4.2. El período de confirmación más corto posible para un cronograma de disposición es un día.

Si se sobrepasa el período de confirmación, entonces el SDCM emite una alerta bajo R8.4.14.

Note que los documentos con un Código de Acción de Disposición de TRANSFERENCIA bajo R8.4.2,



tiene dos períodos de confirmación. El primer período de confirmación cubre la transferencia de los documentos a otro sistema de documentos o ubicación. El segundo período de confirmación cubre la destrucción de los documentos. Para mayor simplicidad, estos dos períodos de confirmación se calculan utilizando los mismos valores para el Código del Intervalo del Período de Confirmación y el Número de la Duración del Período de Confirmación. En otras palabras, los dos períodos de confirmación siempre tendrán la misma duración.

R8.4.8

El SDCM deberá permitir a un usuario autorizado modificar los siguientes metadatos de cualquier cronograma de disposición activo:

• Título,• Descripción,• Mandato,• Notas de aplicación, y • Cualesquiera elementos de metadatos contextuales.

El mandato describe la autoridad para el cronograma de disposición. Diferentes períodos de conservación y reglas de disposición para documentos que pertenezcan a ciertas clasificaciones de negocio pueden ser impuestos por la legislación del gobierno, las regulaciones de la industria, estándares nacionales o internacionales, etc.


R8.4.9

Adicionalmente a R8.4.8, el SDCM deberá permitir a un usuario autorizado modificar los siguientes metadatos para cualquier cronograma de disposición que no se haya aplicado nunca a un archivo:

• Código de Acción de Disposición,• Código del Activador de la Conservación,• Identificador del Elemento del Activador de Conservación (o su equivalente),• Código del Intervalo del Período de Conservación,• Número de la Duración del Período de Conservación,• Código del Desplazamiento del Período de Conservación,• Código del Mes de Desplazamiento del Período de Conservación,• Código del Intervalo del Período de Confirmación, y• Número de la Duración del Período de Confirmación.

Una vez un cronograma de disposición ha sido utilizado, al aplicarlo a un archivo, los valores de los metadatos utilizados para calcular el período de conservación y el proceso de disposición se convierte en fijo y ya no puede ser cambiado. Note que en la justificación a R8.4.13 estos son conocidos como los “controles de disposición”.


R8.4.10

El SDCM debe permitir a un usuario autorizado borrar un cronograma de disposición que nunca ha sido aplicado a un archivo, siempre que no esté asociado con una clase activa como



su cronograma de disposición automática.

Una vez un cronograma de disposición ha sido utilizado no se puede borrar, sin embargo, puede ser destruido bajo R8.4.11. Antes de borrar un cronograma de disposición este debe ser reemplazado como el cronograma automático de disposición para cualesquiera clases activas a las que esté asociado, ver R5.4.4.


R8.4.11

El SDCM debe permitir a un usuario autorizado destruir cualquier cronograma de disposición activo, siempre que no esté siendo aplicado a cualquier archivo activo y que no sea el cronograma automático de disposición de cualquier clase.

Cuando se destruye un cronograma de disposición, el SDCM retiene un cronograma de disposición residual. Un cronograma de disposición no puede destruirse mientras se esté aplicando como el cronograma de disposición de cualquier archivo activo, pero puede destruirse si los únicos documentos con los que está asociado son documentos residuales. Antes de destruir un cronograma de disposición este debe ser reemplazado como el cronograma automático de disposición para cualesquiera clases activas a las que esté asociado, ver R5.4.4, esto es debido a que solo cronogramas de disposición activos pueden ser asociados a clases activas.


R8.4.12

Sujeto a R2.4.22, el SDCM debe permitir a un usuario autorizado explorar los cronogramas de disposición en el servicio de cronogramas de disposición e inspeccionar sus metadatos.

Los términos “explorar” e “inspeccionar” están definidos en 13. Glosario de Términos.

Función de referencia: F.14.5.77

R8.4.13

El SDCM debe permitir a un usuario autorizado remplazar un cronograma de disposición activo con otro cronograma de disposición activo para todos los documentos activos al que se aplica, y para todas las clases activas con las que esté asociado como un cronograma automático de disposición.

Esta función permite al usuario autorizado reemplazar un cronograma de disposición activo con otro a lo largo del SDCM.

Note que bajo R8.4.9, los controles en un cronograma de disposición, tales como los determinantes de la duración del período de conservación, no pueden ser modificados una vez se han aplicado a los documentos. Para cambiar estos controles de disposición un usuario autorizado debe crear un nuevo cronograma de disposición definiendo diferentes controles de disposición y reemplazando el cronograma de disposición anterior donde esto ocurra.

Funciones de referencia: F14.5.34, F14.5.138

R8.4.14

El SDCM debe actualizar el estatus de disposición de cualquier archivo cuando sea solicitado



por un usuario autorizado y, ya sea de forma inmediata o periódica, y al menos diariamente, el SDCM debe actualizar el estatus de disposición de todos los documentos activos.

El estatus de disposición de todos los documentos debe ser actualizado en tiempo real o como una actividad programada al menos una vez al día. El SDCM también debe poder actualizar el estatus de disposición de documentos individuales cuando sea solicitado.

La actualización del estatus de disposición de un archivo activo incluye:

• Revisar si el cronograma de disposición para un archivo ha cambiado o no, ver R6.5.14 y R6.5.15, y, si así es, limpiar los metadatos de disposición anteriores;

• Revisar si el valor del elemento de los metadatos del activador de la conservación definido por el cronograma de disposición ha cambiado o no, y si se han cumplido las condiciones del activador de conservación, ver R8.4.3;

• Calcular y definir la Fecha de Inicio de Conservación, el Código de la Acción de Disposición, la Fecha de Vencimiento de la Acción de Disposición, y la Fecha de Vencimiento de Confirmación de Disposición para un archivo, con base en los controles de disposición de su cronograma de disposición;

• Revisar si existe una disposición retenida para un archivo y, donde sea necesario, generar eventos y aplicar el Código de Acción de Disposición MANTENER EN ESPERA al archivo, ver R8.4.21;

• Revisar si la acción de disposición ha sido o no cancelada, ver R8.4.18, o confirmada, ver R8.4.17, R8.4.19 y R8.4.20;

• Emitir una alerta de vencimiento de una disposición en donde la acción de disposición no haya sido confirmada por la Fecha de Vencimiento de Confirmación de Disposición, ver R8.4.15;

• Implementar los resultados de una revisión, incluyendo la aplicación de un nuevo cronograma de disposición al archivo, ver R8.4.17;

• Cambiar el Código de la Acción de Disposición a DESTRUIR una vez se ha confirmado la transferencia, ver R8.4.19;

• Destruir el contenido de los documentos de los componentes en donde el SDCM pueda hacerlo, ver R8.4.20;

• Destruir los documentos y sus metadatos recortando sus metadatos y sus historias de eventos para dejar una entidad residual, ver R8.4.20; y

• Destruir agrupaciones padre cerradas una vez la última hija ha sido destruida, ver R8.4.22 y R8.4.23.

Para una explicación más amplia, ver el diagrama de flujo del proceso de disposición, Figura 8h en la sección 8.2.11 El proceso de disposición. 8.2.11.

Note que aunque MoReq2010® especifica qué debe hacer un SDCM para cumplir con la especificación, no especifica cómo el SDCM debe implementar esta funcionalidad o si esta debe hacerse en tiempo real o como un proceso programado. El nivel de especificación dado aquí es necesario para soportar la interoperabilidad.


R8.4.15

El SDCM debe alertar a todos los usuarios autorizados para que reciban las alertas para una agrupación o archivo siempre que la Fecha de Vencimiento de la Confirmación de Disposición haya transcurrido sin que la acción de disposición se haya llevado a cabo y se haya confirmado.



Dependiendo del enfoque que tome el SDCM en la implementación de 4. Servicio de Modelo de Roles, el mecanismo mediante el cual los usuarios son autorizados para recibir alertas variará. Cuando el servicio de modelo de roles se implementa, se puede asignar la recepción de alertas a un rol como cualquier otra función. Así los usuarios están autorizados para recibir alertas cuando son asignados a dicho rol a través de una lista de control de acceso.

Por ejemplo, una organización especifica define un nuevo rol llamado “funcionario local de documentos” (FLA). La función recibir alertas está incluida en el rol de FLA. A un usuario se le otorga un rol FLA para una agrupación específica. El SDCM ahora enviará al usuario alertas para cualquier archivo que pertenezca a esa agrupación cuya confirmación está vencida.

MoReq2010® no especifica que mecanismo de alerta debe implementar un SDCM. Están disponibles muchas tecnologías diferentes y que pueden ser soportadas. Como regla general un mecanismo de alerta debe ser proactivo y trazable para mostrar que las alertas se han enviado y se han recibido.

Los mecanismos aceptables para emitir alertas pueden incluir:

• Correo electrónico;

• Notificación automática, por ejemplo mensajería SMS (Sistema de Mensajes Cortos);

• Publicado como un formato RSS/Atom;

• A través de un servicio de suscripción, por ejemplo “twitter.com”;

Los mecanismos que no son aceptables sin una infraestructura adicional de soporte incluyen:

• Escribir alertas en un registro de errores (esto no es proactivo en la distribución de alertas a los usuarios autorizados); y

• Mediante mensajes instantáneos (la mensajería instantánea no deja que una conversación fácilmente rastreable muestre que el mensaje ha sido enviado y recibido).

Cuando se envía una alerta, el SDCM debe agregar al archivo una Marca de Tiempo de Disposición Atrasada. Esto asegura que, entre otras cosas, no se continúe enviando alertas para el mismo archivo.

Dependiendo en cómo el SDCM implemente el proceso de disposición bajo R8.4.14, el SDCM puede consolidar las alertas para múltiples documentos atrasados en una sola alerta para cada usuario autorizado si se deben emitir al mismo tiempo. MoReq2010® no especifica cómo se deben consolidar alertas diferentes.


R8.4.16

El SDCM debe permitir que un usuario autorizado explore e inspeccione todos los documentos activos de los que se debe disponer, y ordenarlos y agruparlos de diferentes maneras por su:

• Clase;

• Agrupación, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto;

• Cronograma de disposición;

• Código de Acción de Disposición;

• Fecha de Vencimiento de la Acción de Disposición; y



• Fecha de Vencimiento de la Confirmación de Disposición.

El SDCM debe permitir al usuario autorizado realizar esta función sin tener que construir consultas de búsqueda individuales bajo 12. Servicio de Búsqueda e Informes, y de tal forma que facilite la cancelación o confirmación de acciones de disposición de forma simultánea para los grupos de documentos bajo R8.4.17, R8.4.18, R8.4.19 y R8.4.19.

Note que el SDCM no debe permitir que cualquier usuario, que normalmente no lo puede hacer, explore o inspeccione entidades a través de este requisito, o que encuentre documentos que se deben destruir pero que están sujetos a una disposición retenida, ver R8.4.21.


R8.4.17

El SDCM debe permitir al usuario autorizado completar una revisión para cualquier archivo o documentos con un Código de Acción de Disposición de REVISIÓN que hayan llegado a su fecha de vencimiento, mediante la aplicación de un nuevo cronograma de disposición y proporcionando un comentario de revisión que describa el resultado de esta, ya sea para:

• Un solo archivo que debe ser revisado individualmente;

• Cualquier conjunto de documentos designado que deba ser revisado;

• Todos los documentos que deben ser revisados bajo un cronograma de disposición designado;

• Todos los documentos que deben ser revisados dentro de una agrupación designada, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto; o

• Todos los documentos que deben ser revisados dentro de una clase designada.

El comentario de la revisión debe guardarse como el Comentario de Evento en el correspondiente evento generado para la revisión. El SDCM también debe aplicar un Comentario de Última Revisión y una Marca de Tiempo de Última Revisión a cada archivo, ver R6.5.10.

La capacidad de revisar documentos dentro de agrupaciones y clases designadas es para asegurar que los documentos pueden ser revisados en contexto y el usuario autorizado puede de forma inequívoca aplicar el mismo resultado simultáneamente a toda la agrupación o clase.


R8.4.18

El SDCM debe permitir al usuario autorizado cancelar la transferencia de cualquier archivo o documentos con un Código de Acción de Disposición de TRANSFERENCIA que ha llegado a su Fecha de Vencimiento de la Acción de Disposición, o cancelar la destrucción de cualquier archivo o documentos con un Código de Acción de Disposición de DESTRUIR que necesita confirmación, ya sea para:

• Un solo archivo que debe ser transferido o destruido individualmente;

• Cualquier grupo de documentos designado que deban ser transferidos;

• Cualquier grupo de documentos designado que deban ser destruidos;



• Todos los documentos que deben ser transferidos bajo un cronograma de disposición designado;

• Todos los documentos que deben ser destruidos bajo un cronograma de disposición designado;

• Todos los documentos que deben ser transferidos dentro de una agrupación designada, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto;

• Todos los documentos que deben ser destruidos dentro de una agrupación designada, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto;

• Todos los documentos que deben ser transferidos dentro de una clase designada, o

• Todos los documentos que deben ser destruidos dentro de una clase designada.

El SDCM debe permitir que las transferencias o las destrucciones que requieran confirmación sean canceladas en cualquier momento después de la Fecha de Vencimiento de la Acción de Disposición y antes de la confirmación de estas acciones bajo R8.4.19 y R8.4.20.

Para cancelar la transferencia o destrucción el usuario autorizado debe aplicar un nuevo cronograma de disposición y proporcionar un comentario obligatorio de cancelación, similar a la revisión en R8.4.17. El SDCM no deberá proceder con la acción de disposición anterior y el nuevo cronograma de disposición debe entrar en vigor de forma inmediata.


R8.4.19

El SDCM debe permitir al usuario autorizado confirmar que se ha completado una transferencia para cualquier archivo o documentos con una acción de eliminación de TRANSFERENCIA que han alcanzado su fecha de vencimiento de disposición, ya sea para:

• Un solo archivo que debe ser transferido individualmente;

• Cualquier conjunto de documentos designado que deba ser transferido;

• Todos los documentos que deben ser transferidos bajo un cronograma de disposición designado;

• Todos los documentos que deben ser transferidos dentro de una agrupación designada, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto; o

• Todos los documentos que deben ser transferidos dentro de una clase designada.

En respuesta a la confirmación de que una transferencia se ha completado, el SDCM debe establecer la Marca de Tiempo de Transferido para un archivo, cambiar su Código de Acción de Disposición a DESTRUIR, fijar la Fecha de Vencimiento de la Acción de Disposición a la fecha de confirmación, limpiar la Marca de Tiempo de la Alerta de Vencimiento de la Disposición de un archivo (si se ha fijado), y calcular una nueva Fecha de Vencimiento de Confirmación de Disposición. Note que el cronograma de disposición para el archivo no ha cambiado.



La capacidad para confirmar la transferencia de documentos por sus agrupaciones y clases designadas es para garantizar que la confirmación se puede hacer más fácilmente y en contexto donde las agrupaciones y los clases completas se han exportado para efectuar la transferencia.


R8.4.20

Sujeto a R8.4.21, siempre que la acción de disposición para un archivo sea DESTRUIR y este alcance su fecha de vencimiento, bajo R8.4.14, el SDCM debe revisar si todos sus componentes deben borrarse de forma automática. Si uno o más componentes no están marcados para ser borrados de forma automática, entonces el SDCM debe fijar el período de confirmación y permitir al usuario autorizado confirmar que la destrucción se ha completado. El SDCM debe permitir al usuario autorizado confirmar la eliminación de los componentes para:

• Un solo archivo que debe ser destruido individualmente;

• Cualquier conjunto de documentos designado que deba ser destruido;

• Todos los documentos que deben ser destruidos bajo un cronograma de disposición designado;

• Todos los documentos que deben ser destruidos dentro de una agrupación designada, incluyendo tanto agrupaciones padre como agrupaciones de un nivel más alto; o

• Todos los documentos que deben ser destruidos dentro de una clase designada.

Si el SDCM puede borrar automáticamente todo el contenido de los componentes de un archivo, o en el momento de la confirmación de la eliminación de todos los componentes del archivo, el SDCM debe garantizar que destruye el archivo activo y sus componentes completamente, dejando un archivo residual con sus componentes residuales.

La destrucción del archivo incluye recortar los elementos de los metadatos y sus valores de los metadatos del archivo y sus componentes, recortar los eventos de la historia de eventos del archivo y sus componentes, y borrar el contenido de los componentes del archivo cuando el SDCM es responsable de hacerlo.

La capacidad de confirmar la destrucción de los documentos dentro de sus agrupaciones y clases designadas es para garantizar que la destrucción se puede llevar a cabo en contexto.

Funciones de referencia: F14.5.41, F14.5.119, F14.5.124

R8.4.21

Como parte del proceso de disposición bajo R8.4.14, el SDCM debe determinar si una disposición retenida se aplica a un archivo activo con Código de Acción de Disposición DESTRUIR, que todavía no ha alcanzado su Fecha de Vencimiento de la Acción de Disposición. Donde esto ocurra, el SDCM debe cambiar el Código de Acción de Disposición a MANTENER EN ESPERA y borrar la Fecha de Vencimiento de la Acción de Disposición y la Fecha de Vencimiento de la Confirmación de Disposición, hasta que el archivo no esté sujeto a una disposición retenida, o su cronograma de disposición sea reemplazado.

De acuerdo con R9.4.4, el SDCM nunca debe permitir la destrucción de cualquier archivo bajo R8.4.20



que esté sujeto a una disposición retenida activa. Aún más el SDCM nunca debe indicar que cualquier archivo está listo para su destrucción si está sujeto de una disposición retenida activa, por ejemplo, incluyéndolo en los resultados de R8.4.16.

Cuando la acción de disposición se ha vencido antes de ponerla en espera y se está esperando la confirmación, el SDCM debe permitir que sea confirmada. Note que las eliminacioneses retenidas evitan la destrucción de un archivo, incluyendo su destrucción después de una transferencia exitosa, pero no evita que los usuarios autorizados puedan revisar el archivo o completar la transferencia del archivo a otro sistema de documentos antes de su destrucción.

Siempre que el SDCM cambia el Código de la Acción de Disposición a MANTENER EN ESPERA, o cuando se han levantado todas las eliminacioneses retenidas del archivo, como se especifica en este requisito, el SDCM debe generar los eventos correspondientes, ver F14.5.128 Archivo – Retenido y F14.5.139 Archivo – Liberado.

Para más información sobre las eliminacioneses retenidas revisar los conceptos claves en 9. Servicio de Disposición Retenida.


R8.4.22

Después de la destrucción de documentos bajo R8.4.20, el SDCM debe destruir de forma automática cualquier agrupación que ya no contenga ningún archivo activo, siempre y cuando esté cerrado.

Bajo R6.5.6, las agrupaciones abiertas no se destruyen hasta que no estén cerradas. Bajo R8.4.23, las agrupaciones pueden cerrarse como parte de la confirmación de destrucción de los documentos que contienen.

Note que la destrucción de las agrupaciones bajo este requisito se hace en forma de cascada hacia arriba (ascendente) de forma que cualquier agrupación que contenga agrupaciones hijas será destruida cuando su última agrupación hija es destruida, siempre que la agrupación padre no esté abierta.


R8.4.23

Siempre que un usuario autorizado confirme la destrucción de los documentos listos para su destrucción dentro de una agrupación o agrupaciones designadas bajo R8.4.20, entonces el SDCM debe permitir al usuario cerrar la agrupación, incluyendo todas sus agrupaciones descendientes, como parte de la misma operación.

Bajo R8.4.22, cerrar una agrupación garantiza que la agrupación en sí será destruida si ya no contiene ningún archivo activo. Bajo este requisito, un usuario que está autorizado para cerrar una agrupación, ver R6.5.6, puede elegir cerrarla mientras confirma la destrucción de los documentos en esa agrupación para garantizar la destrucción simultánea de la agrupación bajo R8.4.22.


R8.4.24

El SDCM no debe permitir ningún cambio en el cronograma de disposición aplicado a un archivo residual.



Los cronogramas de disposición se pueden aplicar individualmente a los documentos activos o se heredan de sus clasificaciones. Sin embargo, una vez que un archivo ha sido destruido el SDCM debe preservar la relación con el cronograma de disposición específico bajo el cual se hizo la destrucción, y no permitir que ese cronograma de disposición sea reemplazado por otro.

Es esencial que, para mantener la confianza en la integridad del SDCM, un auditor en una fecha posterior pueda con seguridad confirmar cuándo un archivo ha sido destruido, las reglas y controles de disposición que se aplicaron en ese momento, y todos los otros metadatos contextuales importantes que rodean la disposición.


9. Servicio de Retención de la Eliminación

9.1 Información sobre el Servicio

Nombre del Servicio Servicio de Disposición Retenida



2e4a8618-c4b3-470f-8ccb-03e2d5e07026



9.2 Conceptos claves

9.2.1 Implementación de la retención de la eliminación

Las eliminaciones retenidas son una parte importante y necesaria de la gestión de documentos moderna. Una disposición retenida es una orden legal o administrativa que interrumpe el proceso normal de disposición y evita la destrucción de algunos de los documentos de una organización mientras que estas retenciones están activas.

Bajo MoReq2010® una disposición retenida se crea dentro de un SDCM, como parte del servicio de disposición retenida, y la disposición retenida es después asociada a entidades como documentos, agrupaciones y clases.

Cuando una disposición retenida está asociada con un archivo individual evita la destrucción de dicho archivo mientras la disposición retenida se mantenga activa. Una vez que la disposición retenida se destruye, el proceso de disposición del archivo continúa.

Cuando la disposición retenida está asociada con una agrupación como un todo, este evita que cualquier archivo en la agrupación, o que es un descendiente de la agrupación, sea destruido. Esto también aplica a nuevos documentos que se agregan a la agrupación después que una retención ya ha sido asociada a una agrupación. Sin embargo, los documentos que se han movido fuera de la agrupación retenida no seguirán estando sujetos a la disposición retenida, a menos que también se aplique individualmente a ellos.

Cuando una disposición retenida está asociada con una clase, esta evita que cualquier archivo clasificado por esta clase sea destruido. La disposición retenida no evita que un archivo que esté retenido sea nuevamente clasificado a una clase diferente que no está sujeta a la disposición retenida.

9.2.2 El impacto de la retención de la eliminación

El impacto de una disposición retenida en el servicio de cronogramas de disposición se describe en detalle en 8. Servicio de Cronogramas de Disposición. Una disposición retenida evitará la destrucción de un archivo al interrumpir el proceso de disposición en el punto inmediatamente anterior a su destrucción. Las eliminaciones retenidas no evitan tomar las decisiones de revisión, cambiar el cronograma de disposición de un archivo, o transferir un archivo hasta el punto en que el archivo es destruido del SDCM.

Un archivo o una agrupación pueden estar sujetos a más de una disposición retenida simultáneamente. Todas las eliminaciones retenidas asociadas se deben levantar antes de que el archivo o la agrupación se puedan destruir.

9.2.3 Levantar las retenciones a la eliminación

Las eliminaciones retenidas se mantendrán activas, bloqueando la destrucción de cualesquiera documentos y agrupaciones a los que esté asociado, hasta que este sea destruido. Esto se describe algunas veces como “levantar” la disposición retenida.

Un usuario autorizado también puede desasociar los documentos, agrupaciones y clases que están retenidos de una disposición retenida. Sin embargo, esta operación solo pretende corregir las asociaciones entre estas entidades y la disposición retenida que haya sido aplicada por error, o cuando las partes en una disputa acuerdan reducir el alcance de una



disposición retenida. El proceso normal para levantar una disposición retenida de las entidades que afecta es destruyendo la disposición retenida. Cuando esto ocurre, no es necesario desasociar individualmente las entidades de la disposición retenida cuando esta se levanta, de hecho mantener la asociación dará información histórica útil.

Una vez se ha levantado, la disposición retenida se destruye y se convierte en una disposición retenida residual. No es posible dar marcha atrás a este proceso. Si la disposición retenida se levanta por error, entonces una nueva disposición retenida se debe crear y esta debe ser asociada con las mismas entidades que previamente estaba asociadas con la disposición residual. Note que hasta que esto ocurra cualquier archivo previamente retenido por el cronograma de disposición anterior no se evitará que este sea destruido a través del proceso de eliminación.

9.2.4 Servicio de Retención de la eliminación

Las eliminaciones retenidas normalmente tienen un alcance institucional y con frecuencia llevan consigo multas y responsabilidades legales y financieras. Pueden ser información importante guardada en diferentes sistemas de negocios dentro de una organización.

La arquitectura del MoReq2010® basada en el servicio hace la posible la implementación de un servicio de disposición retenida centralizado compartido por varios sistemas de documentos en una organización, lo que permite que las eliminaciones retenidas se creen, administren y levanten de forma centralizada, mientras se aplican simultáneamente a través de múltiples sistemas compatibles de MoReq2010®


R9.4.1

El SDCM debe permitir a un usuario autorizado crear eliminaciones retenidas activas (E14.2.5) con los siguientes metadatos del sistema:

• Identificador del sistema (M14.4.100),• Marca de Tiempo de Creación (M14.4.9),• Fecha/Hora de Creación (M14.4.61),• Marca de Tiempo del Primer Uso (M14.4.32),• Identificador del Archivo Retenido (M14.4.39),• Identificador de la Agrupación Retenida (M14.4.37),• Identificador de la Clase Retenida (M14.4.38),• Título (M14.4.104),• Descripción (M14.4.16),• Mandato (M14.4.51),• Notas de aplicación (M14.4.97), y• Marca de Tiempo de la Destrucción (M14.4.17).

Cada disposición retenida también tiene:

• Historia de eventos (ver 2. Servicios del Sistema),• Lista de acceso de control (o su equivalente, ver 4. Servicio de Modelo de Roles),

Y puede tener:

• Metadatos contextuales (o su equivalente, ver 7. Servicio de Modelo de Metadatos)



La Fecha/Hora de Creación se puede usar para registrar la fecha en que la orden legal o administrativa fue emitida, en lugar de la marca de tiempo que señala cuándo la disposición retenida se ha creado en el SDCM, ver R2.4.26.

Dependiendo del enfoque que tome el SDCM en la implementación de 4. Servicio de Modelo de Roles, una lista de control de acceso de MoReq2010® puede no estar presente durante la operación del sistema y solo se puede agregar a un cronograma de disposición durante la exportación.

Dependiendo del enfoque que tome el SDCM en la implementación de 7. Servicio de Modelo de Metadatos, el mecanismo mediante el cual los metadatos contextuales se agregan a un cronograma de disposición puede variar.


R9.4.2

El SDCM debe permitir al usuario autorizado cambiar los metadatos de una disposición retenida activa, incluyendo su Título, Descripción, Mandato, Notas de aplicación y cualesquiera metadatos contextuales.

Las eliminaciones retenidas normalmente representan una orden legal o administrativa. El Mandato describe la autoridad y jurisdicción bajo las cuales la disposición retenida opera. Las Notas de aplicación brindan información adicional a los usuarios sobre cómo se debe interpretar y aplicar la disposición retenida.


R9.4.3

El SDCM debe permitir al usuario autorizado asociar y desasociar disposición retenida activa con documentos, agrupaciones y clases activos.

Por ejemplo, debe ser posible buscar documentos, agrupaciones y clases que caen bajo el alcance de la orden legal o administrativa representada por la disposición retenida, y asociarla con las entidades de los resultados de la búsqueda.

Desasociar una disposición retenida de un archivo, agrupación o clase está pensado solo para aquellas ocasiones en que los documentos, agrupaciones y clases se han agregado a la disposición retenida por error. Los documentos, agrupaciones y clases que se han incluido correctamente en la disposición retenida serán liberados para su destrucción cuando la disposición retenida sea levantada bajo R9.4.6 y no deben ser desasociadas de la disposición retenida individualmente.


R9.4.4

El SDCM debe evitar la destrucción de cualquier archivo bajo R8.4.21, que:

• Está directamente asociada con la disposición retenida;

• Es una hija o descendiente de cualquier agrupación que esté asociada con la disposición retenida; o

• Ha sido clasificado con una clase asociada con la disposición retenida.

Ver 8. Servicio de Cronogramas de Disposición para más detalles sobre cómo la disposición retenida



interrumpe el proceso de eliminación y evita la destrucción de las agrupaciones y documentos.

R9.4.5

El SDCM debe permitir al usuario autorizado borrar una disposición retenida siempre que esta nunca haya sido asociada a cualesquiera documentos, agrupaciones o clases.

Una vez que una disposición retenida ha sido utilizado se convierte en parte importante de la historia de los documentos, agrupaciones y clases a las que ha sido asociada y ya no puede ser borrada del SDCM. Sin embargo, la disposición retenida se puede destruir bajo R9.4.6.


R9.4.6

El SDCM debe permitir al usuario autorizado levantar una disposición mediante su destrucción, lo que permite la destrucción de cualesquiera documentos directa o indirectamente sujetos a la disposición retenida.

Cuando se levanta una disposición retenida entonces se reiniciará el proceso de disposición cualesquiera documentos sujetos a la disposición retenida descrita en 8. Servicio de Cronogramas de Disposición, siempre que no estén sujetos a otras eliminaciones retenidas.

Note que bajo R9.4.4 los documentos se pueden retener de varias formas bajo una disposición retenida. La disposición retenida puede estar directamente asociada con ellos, o pueden ser parte de una agrupación a la que está asociada la disposición retenida, o esta puede asociarse con la clase del archivo. Como consecuencia, es posible que los documentos que se han desasociado de una disposición retenida puedan todavía estar sujetos a la disposición retenida por otros medios, por ejemplo, porque su agrupación padre o su clase se mantiene asociada con ella.

Cuando los documentos ya no están asociados con una disposición retenida, el proceso de eliminación descrito en 8. Servicio de Cronogramas de Disposición se reanuda y puede ser destruido, siempre que no estén sujetos a otras eliminaciones retenidas.

R9.4.7

Sujeto a R2.4.22, el SDCM debe permitir al usuario autorizado explorar las eliminaciones retenidas en el servicio de disposición retenida, y las entidades asociadas en otros servicios, e inspeccionar sus metadatos de la siguiente forma:

• Explorar a lo largo de todos las eliminaciones retenidas en el servicio de de disposición retenida e inspeccionar sus metadatos; y

• Explorar desde una disposición retenida hasta cualesquier documentos, agrupaciones o clases asociados e inspeccionar sus metadatos.

Los términos “explorar” e “inspeccionar” están definidos en 13. Glosario de Términos.

Funciones de referencia: F14.5.12, F14.5.30, F14.5.63, F14.5.131



10. Servicio de Búsqueda e Informes


Nombre del Servicio Servicio Búsqueda e Informes





fd05e284-181f-4f5d-bd8c-4bed835c8931


10.2.1 Descubrimiento

Existen dos métodos mediante los cuales los usuarios pueden descubrir entidades en un SDCM: en usuario puede explorar/navegar de una entidad a las entidades relacionadas con ella (por ejemplo, desde las entidades padre a sus hijas, de las agrupaciones a sus clases, desde los usuarios a sus grupos, desde los documentos a sus componentes, y así sucesivamente), o bien un usuario puede buscar entidades que coincidan con consultas de búsqueda particulares.

La experiencia muestra que la búsqueda es una opción más escalable para hacer descubrimientos en los sistemas de documentos que tienen un gran número de entidades. En algunos sistemas de documentos, es también posible encontrar entidades mediante la búsqueda que un usuario no pueda hacer mediante la exploración o navegación debido a la configuración del control de acceso. Esto ocurre, por ejemplo, cuando un usuario puede inspeccionar una entidad hija pero no su padre. En este caso este padre, al que no se tiene acceso, puede bloquear la capacidad que tiene el usuario de descubrir la entidad hija mediante la exploración o navegación.

Con frecuencia los usuarios combinarán los dos métodos, primero buscando aquellas entidades que cumplen con sus criterios generales de búsqueda y después, una vez que el número de entidades en los resultados se ha reducido a un número manejable, refinando esta aún más mediante la exploración o navegación a partir de los resultados de la búsqueda.

MoReq2010® requiere que todos los sistemas de documentos tengan un motor de búsqueda para encontrar las entidades con base en los valores de sus elementos de metadatos. Los requisitos básicos no especifican que el SDCM deba dar a los usuarios la capacidad para buscar dentro del contenido de los documentos, sin embargo muchos proveedores darán está capacidad para ciertos tipos de contenidos de documentos.

Un importante requisito no-funcional para la búsqueda de un SDCM es la coherencia y la integridad de los resultados. Esto es especialmente importante en el entorno de la gestión de documentos. Si el mismo usuario realiza la misma búsqueda varias veces entonces, asumiendo que no existen cambios en sus principales datos, el SDCM debe, de manera confiable, devolver al usuario el mismo grupo de resultados de la búsqueda en el mismo orden.

10.2.2 Métodos de búsqueda

MoReq2010® no especifica cómo los proveedores deben implementar la búsqueda en sus soluciones de SDCM, sin embargo, la especificación si requiere un nivel mínimo de soporte para varios métodos de búsqueda. Estos incluyen:

• El SDCM debe poder buscar cualquier tipo de entidad, incluyendo eventos, mediante cualquiera de sus sistemas o sus metadatos contextuales;

• El SDCM debe poder definir criterios de búsqueda que coincidan con el tipo de dato de



la definición del elemento de los metadatos, incluyendo tanto el sistema como los metadatos contextuales;

• El SDCM debe poder soportar la búsqueda de texto completo utilizando el mismo término de búsqueda, ingresado una vez, a lo largo de todos los elementos de metadatos textuales simultáneamente;

• El SDCM debe poder buscar en una combinación de criterios de búsqueda separados los elementos de metadatos designados; y

• El SDCM debe poder combinar los resultados de las búsquedas para realizar búsquedas complejas.

10.2.3 Búsqueda de texto

MoReq2010® diferencia entre dos tipos de elementos de metadatos basados en texto. Los elementos de metadatos “textuales” son aquellos diseñados para mantener texto informativo o explicativo expresado como un lenguaje natural, como Título, Descripción y Comentario. Bajo R2.4.28, los elementos de metadatos textuales deben siempre ir acompañados por un identificador de idioma.

Otros elementos de metadatos pueden estar basados en textos pero no están diseñados para mantener palabras o frases en el contexto de un idioma particular. En cambio pueden mantener identificadores, o códigos, etc.

MoReq2010® requiere que los elementos de metadatos textuales se puedan buscar mediante la búsqueda de texto completo. La búsqueda de texto completo es hacer la búsqueda por palabra completa, antes que por una secuencia de caracteres dentro de un valor del elemento de los metadatos. Un ejemplo de la búsqueda de texto completo es la que se realiza en un motor moderno de búsqueda en el Internet, como Google.

Las técnicas de búsqueda de texto completo pueden ser muy complejas, por ejemplo, encontrar la palabra basado en las ortografías alternativas, los diferentes tiempos verbales, o en una variedad de sufijos y prefijos con base en el idioma conocido del texto. MoReq2010® no especifica el nivel de sofisticación requerido para la búsqueda de texto completo, pero si requiere que el idioma del elemento de los metadatos con sus contenidos se guarde, para permitir que un motor de búsqueda adecuadamente equipado puedan aplicar estos tipos de técnicas.

El SDCM también debe proveer los medios para buscar en los elementos de metadatos que no son textuales. Estos pueden estar basados en texto o pueden ser números, marcas de tiempo, referencias a otras entidades, y así sucesivamente.

10.2.4 Resultados de la búsqueda

El objetivo de los usuarios que buscan en un SDCM es encontrar entidades que coincidan con su consulta de búsqueda. Por lo tanto los resultados de la búsqueda siempre se expresan como una lista de entidades. MoReq2010® especifica que los resultados de la búsqueda puedan ser configurados por el usuario, de modo que el usuario pueda especificar cómo se ordenan las entidades en la lista de los resultados de la búsqueda y cuáles elementos de los metadatos que pertenecen a las entidades en la lista son entregados.



MoReq2010® aunque no específica ningún diseño en particular para los resultados de la búsqueda, estos pueden conceptualizarse de forma lógica para que se adhieran a una tabla en la que cada entidad ocupa una fila de la tabla y la columnas representan los valores de los diferentes elementos de metadatos que pertenecen a cada entidad. Este diseño conceptual se muestra en la Figura 10a, pero se debe reiterar que MoReq2010® no específica que este sea el diseño que debe usar un SDCM para presentar los resultados de la búsqueda al usuario.

Figura 10a – Sin importar como se presenten, un conjunto de resultados de la búsqueda puede conceptualmente dibujarse como una lista de entidades y sus metadatos

seleccionados en una orden definida por el usuario

Cuando se hace una búsqueda en un SDCM el número total de resultados de la búsqueda que coinciden con la consulta original puede ser un número grande. Debido a esto, MoReq2010®

especifica que un SDCM debe paginar o dividir de otra forma los conjuntos grandes de resultados de la búsqueda, de modo que al usuario solo se le presenta un subconjunto del total de los resultados a la vez, y puede después solicitar la página siguiente de los resultados al SDCM.

10.2.5 Seguridad

Los resultados devueltos por las búsquedas serán específicos de cada usuario y relacionados con la configuración del control de acceso del usuario. Los usuarios que buscan en un SDCM solo encontrarán aquellas entidades a las que tiene acceso para inspeccionarlas. MoReq2010®

no le permite a un SDCM entregar resultados de la búsqueda que incluyan entidades a las que el usuario no se le ha otorgado el acceso para inspeccionarlas.

Entidades Elementos de metadatosIdentificador Creado Título Descripción Inactivo



De vez en cuando se busca y se explora una entidad a la que el usuario tiene acceso completo, en la inspección tiene un identificador de otra entidad a la que el usuario no tiene acceso. Este puede ser un padre, hija, o cualquier otra entidad relacionada, como una disposición retenida asociada con un archivo. Cuando esto ocurre el SDCM debe evitar que el usuario acceda a la segunda entidad, o a cualquiera de sus metadatos, al navegar hacia ella, al buscarla o inspeccionarla.

Cuando sea posible la entidad simplemente no debe aparecer en los resultados de la búsqueda o en las listas de exploración. Cuando la entidad a la que no se tiene acceso normalmente debería aparecer, digamos, en una columna de una tabla de metadatos como la que se muestra en la Figura 10a, o en los metadatos de una entidad bajo inspección, el SDCM debe mantener anónima su presencia dejando un espacio en blanco o reemplazando su título con una fórmula adecuada como “Entidad desconocida”.

10.2.6 Búsquedas guardadas

Los usuarios pueden guardar sus consultas de búsqueda de forma que las puedan utilizar más tarde. Esto permite al usuario correr la misma búsqueda otra vez, o utilizar los criterios de una búsqueda anterior como el punto de partida para construir un nuevo conjunto de criterios de búsqueda.

Una búsqueda guardada no es considerada por MoReq2010® como una entidad administrada. Esta es específica a un SDCM particular. No existe una definición del tipo de entidad o de la lista de los elementos de los metadatos asociados con una búsqueda guardada, y no se requiere que la búsqueda guardada sea exportada o transferida a otro sistema de documentos.

10.2.7 Informes

MoReq2010® requiere que un SDCM soporte dos clases diferentes de informes: informes detallados e informes resumidos. Las dos clases de informes están relacionadas con la búsqueda descrita anteriormente.

Los informes detallados imitan las búsquedas normales y se basan en una única consulta de búsqueda, entregando un subconjunto de metadatos para cada entidad que aparece en los resultados. Los informes detallados usualmente se presentan en una tabla parecida a la de la Figura 10a. Los informes detallados se diferencian de las búsquedas por que entregan todos los resultados juntos como un solo documento y en un formato de informe común, aunque MoReq2010® no específica el formato en el que debe ir el informe.

Por comparación, los informes resumidos se basan en múltiples consultas de búsqueda, pero no devuelven el conjunto de resultados para cada consulta de búsqueda, sino más bien el número total de entidades encontradas que cumplen con cada consulta de búsqueda. Al igual que con los informes detallados, MoReq2010® no específica para los informes resumidos ningún formato de informe en particular.

10.2.8 Informes guardados

Al igual que las búsquedas guardadas, la definición del informe una vez se ha construido también puede guardarse de modo que puede correrse nuevamente en una fecha posterior o ser usado como base para construir un informe posterior. También, al igual que las búsquedas guardadas, no se requiere que los informes guardados se ajusten a la definición de un tipo de entidad o sean transferidos a otros sistemas de documentos.




R10.4.1

El SDCM debe permitir al usuario encontrar, usando una consulta de búsqueda, las entidades a las que tiene acceso autorizado para explorar o inspeccionar.

Para encontrar entidades mediante una búsqueda el usuario construye una consulta de búsqueda. El SDCM entonces encuentra las entidades que coinciden con la consulta, siempre que también sean entidades a las que el usuario está autorizado inspeccionar (ver 4. Servicios de Modelo de Roles). La lista de todas las entidades que coinciden con la consulta de búsqueda constituye el conjunto de los resultados de la búsqueda.

MoReq2010® no especifica ningún formato en particular para las consultas de búsqueda, pueden ser una plantilla, como las sentencias SQL, o visuales, como la consulta por forma, etc.


R10.4.2

El SDCM debe permitir a los usuarios restringir los resultados de la búsqueda, bajo R10.4.1, a entidades de un tipo o tipos en particular.

Por ejemplo, un usuario puede solo buscar entre eventos, o solo para usuarios, grupos y roles que coincidan con la consulta de búsqueda.

R10.4.3

El SDCM debe permitir al usuario especificar una consulta de búsqueda, bajo R10.4.1, que conste de una sola búsqueda de texto completo que se realiza en todos los elementos de los metadatos textuales.

La búsqueda de texto completo involucra buscar una o más palabras o frases completas. Todos los elementos de los metadatos textuales deben incluirse en la búsqueda de texto completo.

R10.4.4

Cuando se realice la búsqueda de texto completo, bajo R10.4.3, el SDCM debe calcular una puntuación de relevancia para cada entidad encontrada.

La puntuación de relevancia debe clasificar los resultados de la búsqueda del mejor al peor de los resultados de la búsqueda comparados con la consulta de búsqueda. MoReq2010® no especifica el algoritmo utilizado por el motor de búsqueda del SDCM para calcular la puntuación de relevancia.

R10.4.5

El SDCM debe permitir al usuario especificar una consulta de búsqueda, bajo R10.4.1, la cual consiste de un criterio de búsqueda o una combinación de estos, donde cada criterio de búsqueda compara un sistema particular o un elemento de metadatos contextual contra el valor dado por el usuario.

Por ejemplo, el usuario puede buscar un grupo de entidades, basándose en el valor de su Título.

R10.4.6



El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, que devuelva una coincidencia para cualquier valor del elemento de metadatos especificado.

Por ejemplo, un usuario debe poder encontrar solo agrupaciones cerradas basándose en un criterio de búsqueda que especifique que la Marca de Tiempo Cerrado existe y tiene un valor; o a la inversa, encontrar solo agrupaciones abiertas buscando agrupaciones en las que la Marca de Tiempo Cerrado no tenga un valor.

R10.4.7

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, que devuelva una coincidencia para metadatos textuales basando en una búsqueda de texto completo.

Este es similar a R10.4.3, excepto que este requisito reduce la búsqueda de texto completo a un solo elemento de metadatos textual especificado en lugar de a través de todos los elementos de metadatos textuales simultáneamente.

R10.4.8

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, que devuelva una coincidencia para fecha, fecha/tiempo y marca de tiempo basado en:

• Valores que ocurren antes de una fecha, fecha/hora o marca de tiempo en particular;

• Valores que ocurren después de una fecha, fecha/hora o marca de tiempo en particular;

• Valores que ocurren en una fecha en particular;

• Valores que ocurren hoy;

• Valores que ocurren ayer;

• Valores que ocurren mañana;

• Valores que ocurren esta semana;

• Valores que ocurre la semana pasada;

• Valores que ocurren la próxima semana;

• Valores que ocurren este mes calendario;

• Valores que ocurren en el último mes calendario;

• Valores que ocurren en el siguiente mes calendario;

• Valores que ocurren en este trimestre organizacional;

• Valores que ocurren en el último trimestre organizacional;

• Valores que ocurren en el próximo trimestre organizacional;

• Valores que ocurren en este año calendario; o

• Valores que ocurren en el último año calendario; o



• Valores que ocurren en el siguiente año calendario.

Vea el ejemplo que se presenta en la explicación de R10.4.5. Poder definir un rango de fecha/hora con un relativo sentido, como “este mes calendario”, es especialmente importante para las búsquedas guardadas y los informes.

R10.4.9

El SDCM debe permitir a un usuario autorizado establecer para el servicio de búsqueda e informes el primer día de la semana y el primer mes del primer trimestre del año organizacional.

Estos valores se piden cuando se hace una búsqueda bajo R10.4.8, para determinar criterios como “última semana”, “este trimestre organizacional”, y “siguiente año organizacional”.

Para muchas organizaciones el año organizacional no coincide con el año calendario, el cual va de enero a diciembre. Por ejemplo, un año organizacional va de abril a marzo.

R10.4.10

Cuando se haga una búsqueda utilizando como criterio la marca de tiempo, bajo R10.4.8 el SDCM debe poder incluir y tener en cuenta la zona horaria local del usuario para encontrar con precisión los valores de metadatos que caen dentro del período especificado o en el día especificado.

Por ejemplo, todos los siguientes criterios pueden representar la misma hora durante los meses de verano en el hemisferio norte:

• 0030, miércoles, Hora de verano de Europa Central (UTC + 0300)

• 0130, miércoles, Hora de verano de Europa Oriental (UTC+0200)

• 2330, martes, Hora de verano de Europa Occidental (UTC+0100)

• 2230, martes, Hora universal coordinada (UTC)

Note que este requisito aplica solo a las marcas de tiempo (que incluyen información sobre la zona horaria) y no aplica para elementos de metadatos basados en fecha y fecha/hora.

Por ejemplo, no sería apropiado incluir como un factor la diferencia de la zona horaria cuando se busca una agrupación de personal utilizando como criterio de búsqueda la fecha de nacimiento del empleado.

R10.4.11

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, para metadatos numéricos que coincidan con el valor dado por el usuario y basado en:

• Igual;

• Mayor que; o

• Menor que.

Note que combinando los criterios de búsqueda, bajo R10.4.15, es posible obtener más comparaciones numéricas que solo las mencionadas. Por ejemplo, “mayor que O igual a”, “menor que O igual a”, “mayor que [min] Y menor que [max]”, y así sucesivamente.



R10.4.12

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, para las banderas de metadatos booleanos que verifican si el valor del elemento es verdadero (fijado) o falso (borrado).

MoReq2010® se refiere a los elementos de metadatos booleanos como banderas.

R10.4.13

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, para elementos de metadatos que contienen identificadores del sistema sobre la base de una coincidencia con la entidad entregada por el usuario.

Por ejemplo, encontrar todas las entidades que han sido clasificadas bajo una clase en particular.

R10.4.14

El SDCM debe permitir al usuario especificar un criterio de búsqueda, bajo R10.4.5, agrupaciones y componentes que sean descendientes de una agrupación.

Los descendientes no tienen que ser las hijas inmediatas de la agrupación.

R10.4.15

El SDCM debe permitir a los usuarios combinar diferentes criterios de búsqueda, bajo R10.4.5, utilizando los operadores booleanos Y, O y NO en cualquier combinación, y cambiar el orden de precedencia mediante el cual se han evaluado los criterios utilizando paréntesis o un método equivalente.

Estos operadores provienen del algebra booleana. El operador Y se refiere a la intersección entre dos conjuntos, el operador O a la unión de dos conjuntos y NO al complemento de un conjunto. Bajo las convenciones de la lógica booleana, NO tiene la mayor precedencia, seguido por Y, y O con la precedencia más baja. Los paréntesis se pueden usar para cambiar la precedencia de los operadores (las operaciones dentro de los paréntesis siempre se realizan primero).

R10.4.16

El SDCM debe permitir al usuario combinar, encadenar o unir los resultados de varias consultas de búsquedas con el fin de responder a consultas de búsqueda más complejas.

MoReq2010® no especifica cómo un SDCM debe combinar diferentes conjuntos de búsqueda para brindar una capacidad de búsqueda compleja. Esto puede, por ejemplo, ser el equivalente a un SQL unido entre dos tablas de bases de datos o mediante el uso de una técnica diferente.

Los siguientes son ejemplos comunes de los tipos de resultados de búsquedas complejas que los usuarios esperan que un SDCM le brinden:

• Encontrar todas las agrupaciones abiertas que no contienen documentos activos;

• Construir una “historia de actividad” para una agrupación al encontrar y combinar todos los eventos de una agrupación y de cada una de sus entidades descendientes;

• Encontrar todas las agrupaciones, o todos los documentos, que tienen una clase en particular, sin importar si heredaron su clasificación de su agrupación padre o si se aplica directamente a ellas;



• Encontrar todos los documentos que tienen un cronograma de disposición, sin importar si lo heredaron de su clase o si se aplica directamente a ellos;

• Encontrar todos los documentos que están sujetos a una disposición retenida, sin importar si se agregaron a la disposición retenida individualmente o porque estos pertenecen a una clase o agrupación en particular que se ha agregado a la disposición retenida;

• Monitorear las actividades de un grupo en particular encontrando todos los eventos generados por los usuarios de ese grupo en un determinado período de tiempo;

• Encontrar todas las entidades que tienen una definición de un elemento de metadatos contextual específica asociada a ellas en donde el elemento de metadatos contiene un valor específico o un rango de valores;

• Encontrar todas las entidades creadas por un usuario en particular en la última semana, rastreando la función de creación a través del evento de creación; y

• Encontrar todos los documentos transferidos por los miembros de un grupo en particular en el último mes.

R10.4.17

El SDCM debe, por defecto, entregar solo las entidades activas en los resultados de la búsqueda, bajo R10.4.1, a menos que el usuario que está realizando la búsqueda especifique que se incluyan en los resultados de la búsqueda tanto entidades activas como residuales.

Por defecto, las entidades residuales no se incluirán en los resultados de la búsqueda. Cuando el usuario incluye tanto entidades activas como residuales el estatus de estas debe estar claramente indicado en los resultados de la búsqueda.

R10.4.18

El SDCM debe permitir a un usuario que inicia una búsqueda, bajo R10.4.1, especificar:

• Qué elementos de metadatos incluir en los resultados de la búsqueda;

• Si se incluye o no el tipo de entidad para cada entidad en los resultados de la búsqueda;

• Si se incluye o no la puntuación de relevancia calculada bajo R10.4.4;

• Si se incluyen o no tanto entidades activas como residuales, bajo R10.4.17;

• Si se ordenan o no los resultados de la búsqueda según la puntuación de relevancia (si está incluida); y si no está

• Qué elemento(s) de metadatos usar para ordenar los resultados de la búsqueda.

El usuario puede elegir incluir en los resultados de la búsqueda, por ejemplo, el título y la descripción de cada entidad, el tipo de entidad, y su Marca de Tiempo de Creación, y ordenar los resultados según la Marca de Tiempo de Creación.

Note que cuando se ordenan los resultados de la búsqueda según una marca de tiempo, el SDCM deberá incluir y tener en cuenta la zona horaria cuando determine el orden de las entidades, ver también R10.4.10.

R10.4.19



El SDCM debe, para conjuntos grandes de resultados de la búsqueda, implementar un método de paginación, u otra alternativa, en donde solo un subconjunto del total de los resultados de la búsqueda se entregue al usuario y los subconjuntos adicionales se entreguen a medida que se solicitan.

MoReq® no define un conjunto “grande” de resultados de la búsqueda o cómo el SDCM debe implementar la paginación o cualquier otro método de entregar secuencialmente al usuario los subconjuntos de los resultados de una búsqueda completa, sin embargo, la paginación (o una alternativa) se debe poder demostrar en el SDCM durante la prueba. El tamaño de las páginas en diferentes implementaciones normalmente varían entre 10 y 100 elemento por página.

R10.4.20

El SDCM debe entregar, como parte de los resultados de la búsqueda, el número total de entidades que coinciden con la consulta de búsqueda, este total no debe incluir las entidades que están excluidas de los resultados de la búsqueda bajo R10.4.21.

Cuando se paginan conjuntos grandes de resultados de búsqueda, bajo R10.4.19, el número total de resultados de búsqueda coincidentes debe entregarse en la primera y en todos los siguientes subconjuntos.

El número total de resultados de la búsqueda es, de forma inmediata, una indicación valiosa para el usuario y, más tarde lo es estadísticamente, cuando se guarde en un evento coincidente, de la actividad de búsqueda y los patrones de uso a lo largo de SDCM. Dependiendo del motor de búsqueda utilizado por el SDCM, este número puede ser una aproximación.

R10.4.21

El SDCM nunca debe permitir al usuario, ya sea mediante la búsqueda, exploración (navegación) o cualquier otro método, acceder a entidades, o sus metadatos, a los que no está autorizado inspeccionar. Todas estas entidades deben excluirse de los resultados de la búsqueda.

Ver también R10.4.1. Los resultados de la búsqueda no deben incluir ninguna entidad a la que el usuario no tenga acceso. Estas entidades también se deben excluir de los totales de los resultados de búsqueda bajo R10.4.20.

R10.4.22

Siempre que un usuario realice una búsqueda bajo R10.4.1, el SDCM debe generar un evento e incluirlo en la historia de eventos de la entidad del usuario. El evento debe incluir una descripción de la consulta de búsqueda realizada y el número total de entidades encontradas, ver R10.4.20.

MoReq2010® no especifica cómo se deben describir las consultas de búsqueda en Consulta de Búsqueda. Puede ser en un lenguaje de expresión estructurada o en un lenguaje natural.

Note que MoReq2010® no requiere que el evento de búsqueda generado se deba vincular a cada uno de los resultados de la búsqueda como entidades participantes, pero el evento debe contener el número total de resultados de la búsqueda que se entrega.


R10.4.23



El SDCM debe permitir a los usuarios autorizados guardar, modificar, borrar y compartir las consultas de búsqueda.

Note que estas se conocen normalmente como “búsquedas guardadas”, aunque solo se guarda la consulta de búsqueda que se salva, en lugar de los resultados de la búsqueda.

MoReq2010® no especifica cómo se deben guardar las consultas de búsqueda o en qué formato. Este detalle es específico a cada SDCM y su motor de búsqueda. Por esta razón, las búsquedas guardadas no se pueden exportar del SDCM e importar a otro sistema de documentos, bajo 11. Servicio de Exportación, y esta funcionalidad no está incluida en las definiciones de las funciones en 14.5 Definición de las Funciones.

R10.4.24

El SDCM debe permitir a los usuarios autorizados generar informes detalladas sobre cualquier consulta de búsqueda, en un formato de informe común, con los siguientes elementos configurables:

• Un encabezado del informe dado por el usuario;

• La fecha y hora en que el informe fue generado;

• Numeración de las páginas;

• Detalles del SDCM y del servicio de búsqueda e informes que genera el informe, ver R2.4.2;

• Detalles del usuario que genera el informe, ver R3.4.1;

• Una descripción de la consulta de búsqueda para el informe, ver R10.4.22;

• El número total de los resultados de la búsqueda en el informe, ver R10.4.20;

• Las columnas y el encabezado de las columnas según los elementos de metadatos seleccionados para el informe, ver R10.4.18.

Cuando certifican su producto, los proveedores deben entregar una lista de los formatos de informes que soportan. Los formatos de informes más comunes son:

• Valores separados por una coma o un tabulador;

• Formatos de hoja de cálculo, como OOXML y ODF;

• Formatos XML y HTML; y

• Formatos PDF u otros formatos de documentos.


R10.4.25

El SDCM debe permitir a los usuarios autorizados generar informes resumidos sobre múltiples consultas de búsqueda, en un formato de informe común, con los siguientes elementos configurables:



• Un encabezado del informe dado por el usuario;

• La fecha y hora en que el informe fue generado;

• Numeración de las páginas;

• Detalles del SDCM y del servicio de búsqueda e informes que genera el informe, ver R2.4.2;

• Detalles del usuario que genera el informe, ver R3.4.1;

• Una descripción de cada consulta de búsqueda utilizada para el informe, ver R10.4.22; y

• El número total de los resultados de la búsqueda encontrados para cada consulta de búsqueda, ver R10.4.20;

Un informe resumido solo da el número total de entidades que cumplen con cada conjunto de consultas de búsqueda especificado. Solo se da el número total de entidades que coinciden. A diferencia de un informe detallado, el informe resumido no tiene un cuerpo en el que se indiquen la lista de entidades o sus metadatos.

Los formatos de informes más comunes se indican en la explicación de R10.4.24.


R10.4.26

Siempre que un usuario genere un informe detallado bajo R10.4.24, o un informe resumido bajo R10.4.25, el SDCM debe generar un evento e incluirlo en la historia de eventos del usuario de la entidad. El comentario al evento debe incluir una descripción de la(s) búsqueda(s) realizada(s) al generar el informe, y el número total de entidades encontradas.

Ver también R10.4.22.


R10.4.27

El SDCM debe permitir al usuario autorizado guardar, modificar, borrar o compartir las definiciones del informe para los informes detallados y resumidos.

Ver también: R10.4.23.

11. Servicio de Exportación




Nombre del Servicio Servicio de Exportación



fd05e284-181f-4f5d-bd8c-4bed835c8931


11.2.1 Objetivo de la exportación

La exportación en MoReq2010® es una operación mediante la cual las entidades en una SDCM se pueden describir con suficiente detalle en un formato de datos XML común, el cual pertenece a la especificación, de forma que los valores de sus metadatos, las historias de eventos, los controles de acceso y el contenido se pueden conservar y transferir a otro SDCM.

La operación complementaria de la exportación es la importación. El objetivo de la importación es tomar los datos con formato XML de MoReq2010® que han sido exportados de un SDCM, y utilizarlos para crear nuevas entidades en un SDCM diferente de forma tal que se pueda acceder a ellos y gestionarlos de la misma forma en que estaban anteriormente.

El ideal es que tanto la exportación como la importación sean operaciones “sin pérdidas”; no deben despojar a la entidad de nada de su significado, contenido o contexto. La capacidad para exportar entidades de un SDCM e importarla de forma útil hacia otro SDCM, sin perder el

contexto del negocio, se conoce en MoReq2010® como alcanzando la “interoperabilidad”.

Algunas de las razones más comunes para exportar entidades desde un SDCM incluyen:

• Transferencia – en donde las entidades son trasladadas a la gestión de un sistema, una organización o un archivo diferente. La mayoría de las veces la transferencia se lleva a cabo como consecuencia de seguir un cronograma de disposición que es parte del proceso de disposición descrito en 8. Servicio de Cronogramas de Disposición.

• Migración – en donde las entidades dentro de una organización son movidas de la administración o gestión de un SDCM a otro SDCM. Esto puede hacerse como parte del reemplazo, actualización o desactivación del SDCM original.

• Hospedaje secundario – en donde las entidades son periódicamente copiadas a uno o más sistemas secundarios y de solo lectura. Si el hospedaje secundario se actualiza regularmente en esta forma, entonces solo las diferencias entre las entidades que mantiene y aquellas en el sistema de origen necesitarán ser importadas; y

• Replicación - para poder entregar una copia para referencia o para la custodia de los contenidos de un SDCM en un formato de uso común (formato abierto sin derechos de propiedad) y de fácil comprensión que se puede transportar a otros sistemas de documentos compatibles. Note que el servicio de exportación de MoReq2010® no está diseñado ni optimizado para ofrecer copias de seguridad o respaldos operativos de rutina como parte de las previsiones generales de los servicios de recuperación de desastres. Sin embargo, a diferencia de un sistema de



copias de seguridad o respaldo de datos que se realiza en el formato de datos propiedad del proveedor y que solo se puede utilizar para restablecer el sistema a partir del cual se hizo, el servicio de exportación permite que se haga una copia de todo o parte de un SDCM en el formato XML de MoReq2010

® ampliamente

comprendido.

11.2.2 Exportación parcial

El servicio de exportación de MoReq2010®

está diseñado para exportar entidades completas con sus metadatos, historias de eventos, controles de acceso y contenido intactos. Cuando se exportan las entidades desde el servicio de exportación de MoReq2010

®, otras entidades

relacionadas que le dan contexto a la entidad deben ser exportadas con ellas, algunas como marcadores de posición, como se describe a continuación. Esto garantiza que el contexto completo de las entidades se transfiere de un sistema a otro. Sin embargo, para asegurar esto también se requiere que se exporten suficientes datos.

Adicionalmente, algunos sistemas de documentos pueden permitir otras formas de exportación en las que solo algunos de los requisitos del servicio de exportación de MoReq2010

® están

soportados. Estas pueden incluir:

• Solo algunos metadatos,

• Solo algunos eventos de la historia de eventos,

• Solo alguna información de los controles de acceso, y/o

• Solo algunas entidades relacionadas.

MoReq2010®

describe estos enfoques como la implementación de una “exportación parcial” debido a que la integridad de los datos que se exportan está incompleta. Una exportación parcial es, por definición, “con pérdidas” en lugar de “sin pérdidas”.

Aunque la exportación parcial puede tener alguna aplicación en ciertas situaciones de negocio, por ejemplo como medio para entregar una copia temporal, o un resumen del conjunto de documentos a una autoridad externa, en general no es adecuada para la práctica de una buena gestión de documentos. Las transferencias con pérdidas de entidades pueden dar como resultado la pérdida imprevista de atributos importantes y del contexto del negocio que se pueden necesitar después. La consistencia interna dentro del sistema de documentos no se puede garantizar, especialmente en el largo plazo.

Por esta razón, no se requiere la exportación parcial y no se ha probado para que cumpla con la especificación MoReq2010® , aunque un proveedor puede ofrecer alguna forma o algunas formas de exportación parcial como una característica adicional del producto. Note también que debido a que el formato de los datos de exportación facilitados por MoReq2010® se basa en XML, debe ser igualmente posible para un organización generar cualquier exportación parcial a partir de una exportación completa mediante la posterior aplicación de una transformación XML.

La implementación del servicio de exportación de MoReq2010®

, como la definen estos requisitos, es un mandato de calidad esencial para cumplir con los servicios básicos.

11.2.3 El uso de XML



A MoReq2010® la acompaña un esquema XML, publicado y mantenido por DLM Forum®, que define cómo los datos deben ser descritos como una condición posterior a la exportación y una condición anterior a la importación. Cada SDCM debe brindar una implementación completa de este esquema, la cual se puede extender para permitir la definición y captura de elementos de metadatos contextuales y las variaciones introducidas por los módulos de extensión y los complementos (plug-ins) de MoReq2010®.

MoReq2010® define el servicio de exportación como el escribir las entidades exportadas a un archivo de datos XML. Sin embargo, reconoce que escribir los datos exportados a un archivo de datos XML, aunque práctica para pequeñas cantidades de datos, no se puede considerar una solución escalable a entornos de SDCM medianos o grandes. Esto es debido a:

• Los sistemas operativos establecen límites al tamaño de los documentos de datos y también existen límites prácticos impuestos por los medios de almacenamiento. Por esta razón, no se pueden escribir grandes cantidades de datos en un único archivo de datos, sino que se deben dividir en muchos documentos de datos. La industria no tiene un estándar para esto.

• Para un almacenamiento más eficiente, con frecuencia los documentos de datos XML se comprimen, y mientras que XML está estandarizado, diferentes algoritmos de compresión no lo están.

• Los documentos de datos XML se deben almacenar en alguna parte, aunque sea temporalmente, dejándolos vulnerables a amenazas de seguridad como accesos no autorizados, eliminación accidental e incluso falsificación.

En el futuro, las soluciones de SDCM más grandes tendrán que transferir miles, decenas de miles, cientos de miles e incluso millones de documentos y entidades relacionadas como parte de una sola operación segura de exportación/importación.

11.2.4 Flujo continuo de datos XML

Por las razones dadas anteriormente, la exportación a documentos de datos XML se ve como una solución temporal al problema de la exportación e importación de datos desde un SDCM. La Fundación de DLM Forum, la Junta de Gobierno de MoReq tienen la intención de investigar y explorar opciones para soportar el flujo de datos exportados en una futura versión de MoReq2010®.

Los flujos de datos XML tienen las siguientes ventajas sobre los documentos de datos XML:

• Los flujos de datos no están limitados por tamaños fijos de documentos de datos o por la capacidad de almacenamiento de un medio físico, aunque, si se requiere, los flujos de datos se pueden capturar en uno o más documentos de datos;

• Un flujo de datos se puede interrumpir en cualquier punto durante la transferencia y reiniciarse más tarde, por lo tanto son un medio robusto de transferencia;

• Los flujos de datos se pueden enviar a través de canales encriptados, lo que permite un sistema seguro para la comunicación del sistema;

• Durante la transferencia, el flujo de datos no requiere ningún almacenamiento físico intermedio, como DVDs, los cuales se pueden perder, dañar o ser copiados ilegalmente durante el tránsito; y



• El flujo de datos continuo permite la transferencia directa de datos en tiempo real.

En consecuencia, puede ser más difícil interceptar o interferir un flujo de datos y junto con la inmediatez de la comunicación en tiempo real, en el futuro, se contribuirá a mejorar la autenticidad de los documentos transferidos. Un posible estándar que se le puede introducir en el futuro al servicio de exportación de MoReq2010® es el uso del estándar de Intercambio Eficiente de XML del World Wide Web Consortium - W3C EXI (por sus siglas en inglés). En el momento de la publicación de MoReq2010® , EXI no era una “recomendación” del World Wide Web Consortium (W3C), pero ha sido candidato a ser recomendado desde diciembre del 2009.

11.2.5 Importación de entidades

MoReq2010® está diseñada para que su uso sea adecuado tanto para implementaciones de sistemas de documentos de múltiples propósitos a gran escala como para implementaciones de un solo propósito y a pequeña escala. Mientras que la exportación es una parte necesaria de los servicios básicos ofrecidos por un SDCM, la importación complementaria no es requisito básico de la especificación. Esto refleja la complejidad del proceso de importación. Implementar un servicio de importación que pueda importar datos de todos los otros SDCM con éxito, necesariamente requiere una solución más sofisticada que solo la que es necesaria para exportar datos. El resultado de construir soluciones más sofisticadas es más tiempo para desarrollar con un costo potencialmente más alto para el consumidor final, al menos hasta que dichos sistemas sean un lugar común, y la respectiva reducción en el número de sistemas de documentos compatibles.

Por lo tanto, mientras que MoReq2010® especifica que cada SDCM debe soportar la exportación de modo que los sistemas de documentos no se conviertan en una trampa para los datos y que un vez se han ingresado en el sistema estos no se puedan recuperar, esta no especifica que cada SDCM deba necesariamente hacer una provisión para un servicio de importación. Algunos sistemas de negocios de primera línea dedicados puede que nunca soporten la importación, mientras que otros proveedores de SDCM solo incluirán la importación en la segunda generación de sus productos compatibles con MoReq2010® . Por lo general, serán los sistemas de documentos más grandes y más genéricos, implementados como plataformas empresariales de capa intermedia (enterprise middleware), con la capacidad de integrarse con y soportar múltiples sistemas de negocios de primera línea, los que necesitarán la funcionalidad de la importación antes que otros tipos de SDCM.

El servicio de importación se ofrecerá como un módulo de extensión de MoReq2010® y las organizaciones clientes pueden, en caso de que así lo requieran, especificar esta funcionalidad.

11.2.6 Exportación desde sistemas no compatibles

A medida que los sistemas compatibles con MoReq2010® son más comunes, se prevé que los proveedores querrán construir adaptadores que permitan que los documentos y otras entidades en sistemas de información heredados se puedan exportar al formato XML de MoReq2010® . Estos sistemas viejos y no compatibles puede que nunca sean actualizados a nuevas versiones que puedan llegar a ser compatibles con MoReq2010® . Sin embargo, las organizaciones querrán que, ya sea el proveedor original o un tercer proveedor, le brinde una solución de migración de forma tal que los contenidos de estos sistemas de documentos puedan ser transferidos a un SDCM.



Una vez que los documentos y entidades se han migrado exitosamente a, o sean han recreado en, un SDCM se pueden mantener indefinidamente, ya que todas las soluciones de SDCM soportan un servicio de exportación y por lo tanto pueden transferirlos al siguiente sistema de documentos.

Además de proporcionar un formato de datos XML, MoReq2010® no define ningún requisito para la transferencia de documentos y entidades desde los sistemas de documentos no compatibles. Cada organización debe, de forma independiente, estar satisfecha con la integridad y exactitud de cualquier herramienta de migración de la que tenga licencia o que desarrolle para extraer los documentos y entidades de los sistemas heredados.

11.2.7 Contexto de exportación y marcadores de posición (placeholders)

Todas las entidades en un SDCM están fuertemente interrelacionadas y MoReq2010® requiere que cada entidad se exporte con su contexto. Esto significa que cuando una entidad se exporta, la información sobre la entidad, y otras entidades relacionadas se exportan con ella.

Para propósitos de la exportación, el contexto completo de cada entidad está formado por:

1. Elementos de metadatos del sistema y sus valores;

2. Elementos de metadatos contextuales y sus valores;

3. Entidades relacionadas a las que se refieren los identificadores del sistema mantenidos en estos elementos de metadatos;

4. Entidades importantes, como un cronograma de disposición de un archivo, ya sea que estén o no referidos directamente por un identificador del sistema mantenido en un elemento de metadatos;

5. Entidades incluidas, como los componentes de un archivo, los usuarios en un grupo o los documentos en una agrupación;

6. La lista de control de acceso de la entidad y sus entradas de control de acceso;

7. Las listas de control de acceso de las entidades relacionadas y significativas, y sus entradas de control de acceso,

8. Los usuarios, grupos y roles a los que se refieren estas entradas de control de acceso;

9. Los eventos en la historia de eventos de la entidad; y

10. Las entidades a las que se refieren los sistemas de identificadores mantenidos en los elementos de metadatos que pertenecen a cada evento.

Para exportar una entidad completa con su contexto desde un SDCM, todos los elementos indicados en la lista anterior se deben exportar con ella. Sin embargo note que algunos elementos en la lista, en particular 3, 4, 6, 7 y 8, necesitan que se exporten entidades adicionales. Si estas entidades relacionadas también se exportan según estas reglas, esto puede, potencialmente, resultar en una piscina de entidades para exportar cada vez mayor.

En lugar de esto, cualquier entidad relacionada que no está directamente incluida en el conjunto de entidades para exportar, se exporta con un contexto reducido. Específicamente estas entidades tienen solo los siguientes elementos de la lista anterior:



1. Elementos de metadatos del sistema y sus valores;

4. Entidades significativas, como un cronograma de disposición de un archivo, ya sea que estén o no referidos directamente por un identificador del sistema mantenido en un elemento de metadatos;

6. La lista de control de acceso de la entidad y sus entradas de control de acceso;

7. Las listas de control de acceso de las entidades relacionadas y significativas, y sus entradas de control de acceso,

8. Los usuarios, grupos y roles a los que se refieren estas entradas de control de acceso;

Las entidades que se exportan con su contexto completo se describen como “exportadas completas”. Las entidades que se exportan con un contexto reducido se describen como “exportadas como marcadores de posición”. Los marcadores de posición no incluyen metadatos contextuales, ni otras entidades relacionadas que no sean entidades significativas o cualquier historia de eventos.

Aunque los marcadores de posición de exportación son útiles para dar contexto a otras entidades, estos no son considerados como entidades completas, ya que falta parte de su propio contexto. Ellos representan una instantánea en dos dimensiones tomada en un momento particular antes que una entidad en “vivo”.

Las entidades que se han exportado completas pueden ser importadas por otros SDCM y gestionadas como entidades activas. Por comparación, cuando un SDCM importa un marcador de posición crea a partir de él una entidad “inactiva”, la cual no es ni activa ni residual. Las entidades inactivas solo son importantes en el contexto de 501. Servicio de importación de MoReq2010®, no son parte de los servicios básicos de MoReq2010® ni es necesario implementarlas para cumplir con los requisitos básicos.

11.2.8 Exportación de metadatos

Cada entidad tiene asociado a ella un conjunto de elementos de metadatos, algunos son elementos de metadatos del sistema y algunos pueden ser elementos de metadatos contextuales. Cada metadato tiene dos partes importantes:

• La definición de su elemento de metadatos relacionado, y

• Su valor (o valores).

Cuando se exportan elementos de metadatos, no se incluyen las definiciones del elemento de metadatos del sistema en los datos exportados. Se puede suponer de forma segura que el SDCM de importación ya conoce estas definiciones, ya que MoReq2010® las especifica. Por lo tanto, los elementos de metadatos del sistema se exportan solo como un valor.

Cuando se exportan los elementos de metadatos contextuales es necesario exportar, junto con el valor, las correspondientes definiciones del elemento de metadatos contextual. Esto le permite al SDCM de importación “reconocer” el elemento de metadatos. Cuando sea necesario, las definiciones del elemento de metadatos contextual relevante se deben exportar como marcadores de posición.

Cuando se exporta una entidad completa, entonces los valores de los metadatos de su sistema



y sus valores de metadatos contextuales, y todas las definiciones del elemento de metadatos contextual que corresponda, se exportan con ella. Cuando una entidad se exporta como un marcador de posición, entonces solo los valores de los metadatos de su sistema se exportan.

Cada elemento de metadatos, incluso para el sistema y los metadatos contextuales, es o bien:

• El valor de un tipo de dato en particular, como un valor de texto, un número o una bandera; o

• Un identificador del sistema que hace referencia a otra entidad en el SDCM.

Si un elemento de metadatos contiene un tipo de dato, entonces su valor simplemente se exporta. Sin embargo, si un elemento de metadatos contiene un identificador de sistema, entonces la entidad a la que hace referencia se describe como una “entidad relacionada”. Son las relaciones entre las entidades relacionadas lo que les da contexto.

Cuando un entidad se exportada completa, todas las entidades relacionadas a las que hace referencia su sistema o sus metadatos o sus metadatos contextuales, se exportan como marcadores de posición. Cuando una entidad se exporta como un marcador de posición, entonces solo los valores de metadatos de su sistema se exportan, no se exporta ninguna entidad relacionada a la que estos valores puedan hacer referencia.

11.2.9 Exportación de entidades importantes

Algunas entidades son más significativas brindando el contexto de una entidad que otras. En MoReq2010®, no todas las entidades relacionadas son entidades significativas y no todas las entidades significativas son entidades relacionadas. Por ejemplo, el cronograma de disposición de un archivo es muy significativo. Sin embargo, el archivo puede heredar su clase de su agrupación padre y su cronograma de disposición de su clase. Por lo tanto, el cronograma de disposición no es inmediatamente una entidad relacionada para el archivo, aunque es una muy significativa.

Para las clases, las siguientes entidades son significativas:

• El cronograma de disposición de la clase; y

• Cualquier disposición retenida asociada con la clase.

Para agrupaciones, las siguientes entidades son significativas:

• Las agrupaciones de la clase, ya sean heredadas o aplicadas directamente a la agrupación;

• La agrupación padre de la agrupación, y cualquier agrupación antecesora, hasta e incluyendo la agrupación raíz; y

• Cualquier disposición retenida asociada con la agrupación.

Para los documentos, las siguientes entidades son significativas:

• La clase del archivo, ya sean heredadas o aplicadas directamente al archivo;

• El cronograma de disposición del archivo, ya sea heredado de su clase o directamente aplicado al archivo;



• La agrupación padre del archivo, y cualquier agrupación antecesora, hasta e incluyendo la agrupación raíz; y

• Cualquier disposición retenida asociada al archivo.

Para los usuarios, las siguientes entidades son significativas:

• Los grupos a los que pertenecen los usuarios.

La Figura 11a muestra algunas entidades significativas para un archivo.

Figura 11a – Las entidades significativas, como la clase, el cronograma de disposición y las agrupaciones ancestrales para un archivo se deben exportar como marcadores de posición

Las entidades significativas son tan importantes que aún cuando una entidad se exporta como un marcador de posición, sus entidades significativas también se deben exportar con ella como marcadores de posición.

11.2.10 Exportación de entidades incluidas

Se puede considerar que algunas entidades contienen a otras; estas son sus entidades “incluidas”. Esta es una lista de entidades incluidas:



• Las entidades incluidas de los documentos son componentes;

• Las entidades incluidas de las agrupaciones son agrupaciones hijas y documentos;

• Las entidades incluidas de los grupos son usuarios;

• Las entidades incluidas de las plantillas son definiciones del elemento de metadatos contextual.

Cuando las entidades con entidades incluidas se exportan completas, entonces sus entidades incluidas también se exportan completas. Esto se muestra en las Figuras 11b y 11c. Las entidades incluidas nunca se exportan como marcadores de posición.

Cuando las entidades se exportan como marcadores de posición, sus entidades incluidas no se exportan.

Figura 11b – Un ejemplo de entidades incluidas son los componentes de un archivo; cuando el archivo se exporta completo, los componentes también se exportan completos.

Todas las entidades incluidas se deben exportar completas, en cascada hasta cualquier profundidad. Por ejemplo, si la agrupación raíz se exporta completa, entonces todas las agrupaciones hijas se exportan completas, todos los documentos en estas agrupaciones hijas se exportan completas y los componentes de estos documentos se exportan completos, y así



sucesivamente.

Figura 11c – Otro ejemplo de entidades incluidas son las agrupaciones hijas; todas las entidades incluidas se exportan completas, por lo que las entidades incluidas de

entidades incluidas se exportarán completas.

Cuando una entidad se exporta completa porque es una entidad incluida, entonces esta tiene el mismo efecto como si la entidad incluida hubiera sido originalmente nominada para la exportación. Todas las entidades se exportan completas y cualquier entidad relacionada significativa de cualquiera de las entidades incluidas también se exporta como marcador de posición, como se muestra en la Figura 11d.



Figura 11d – Se muestran las dos entidades incluidas que se exportan completas, y las entidades significativas que se exportan como marcadores de posición

11.2.11 Exportación de listas de control de acceso

Las listas de control de acceso contienen las entradas de control de acceso que asocian a un usuario o grupo en particular con uno o más roles. La Figura 11e muestra una lista de control de acceso típica para una entidad.

Cuando las entidades se exportan como marcadores de posición sigue siendo importante que el acceso a la información que contienen esté controlado. Por esta razón, el SDCM debe exportar las listas de control de acceso de las entidades que se exportan completas y de las entidades que se exportan como marcadores de posición.

Debido a que el servicio de modelo de roles soporta la herencia de las listas de control de acceso de los servicios, los padres y las clases, bajo R4.5.11, el SDCM debe también exportar las listas de control de acceso de los servicios relevantes para las entidades y los marcadores de posición que se están exportando. De esta forma, la lista de control de acceso completa para una entidad en una importación se puede ensamblar a partir de una combinación del servicio, de las entidades significativas como los padres y las clases exportadas como marcadores de posición, y la entidad exportada en sí.

Cuando una lista de control de acceso se exporta, ya sea para una entidad que se exporta completa o para una entidad marcador de posición (placeholders entities) , cada una de las entidades a las que hace referencia la lista de control de acceso también deben exportarse como marcadores de posición, incluyendo usuarios, grupos y roles. Esto se muestra en la Figura 11f.



Figura 11e – Una lista de control de acceso típica; cada entrada de control de acceso asocia a un usuario o un grupo con uno o más roles

Figura 11f – Todas las entradas a las que hace referencia la lista de control de acceso deben exportarse como marcadores de posición



11.2.12 Exportación de eventos

Cada historia de eventos de una entidad está compuesta por un conjunto de eventos en los que una entidad ha participado. Para cada uno de estos eventos pudo haber habido otras entidades que participaron, y los metadatos asociados con el evento harán referencia a varias entidades relacionadas.

Cuando una entidad se exporta completa, entonces su historia de eventos se exporta con ella. Esto significa todos los eventos en los que la entidad ha participado. Además, para exportar los metadatos de los eventos, todas las entidades relacionadas a los eventos también se deben exportar como entidad marcador de posición (placeholders entities).

Cuando una entidad se exporta como un marcador de posición, entonces su historia de eventos no se exporta. Ninguno de los eventos en que la entidad ha participado se exportan con una entidad marcadora de posición (placeholders entities).

11.2.13 Tabla de resumen de la exportación

La descripción dada desde 11.2.7 hasta 11.2.12 indica qué debe hacer un SDCM para compilar un conjunto de datos para exportación. Comenzando por las entidades indicadas por el usuario, el SDCM debe seguir todas sus entidades relacionadas y decidir que entidades exportar completas y cuáles como marcadores de posición. El SDCM debe entonces compilar estos datos por servicio, eliminar los datos duplicados o redundantes, y exportarla como un conjunto coherente de datos.

La siguiente tabla resume las decisiones de exportación del SDCM:

¿Qué exportar? Para entidades que se exportan completas

Para marcadores de posición

Elementos de metadatos del sistema

Exportar valores Exportar valores

Elementos de metadatos contextuales

Exportar valores No exportar

Definiciones del elemento de metadatos contextual

Exportar como marcadores de posición

No exportar

Entidades relacionadas (a las que hacen referencia los elementos de metadatos)


No exportar

Entidades significativas (por ejemplo, la clase de un archivo)



Entidades incluidas (por ejemplo, las entidades hijas de una agrupación)

Exportar completas No exportar

Listas de control de acceso Exportar valores No exportar



Entidades a las que hacen referencia las entradas de control de acceso



Eventos y sus metadatos Exportar valores No exportar

Entidades relacionadas con los eventos (a las que hacen referencia los metadatos)


No exportar

11.2.14 Entidades que no se exportan

Por defecto, solo las entidades activas se exportan de una SDCM. Las entidades residuales normalmente se excluyen de la exportación, pero el usuario tiene la opción de incluirlas al hacer la exportación.

Note que las búsqueda e informes guardados, a los que se hace referencia en 10. Servicio de Búsqueda e Informes son considerados como objetos específicos de la aplicación, antes que entidades de MoReq2010® , y la especificación no hace ninguna previsión para su exportación.

11.2.15 Seguridad de la exportación

Un usuario no puede exportar completa o como un marcador de posición cualquier entidad a la que el usuario no está autorizado inspeccionar, y el SDCM no debe permitir que el usuario exporte entidades a las que normalmente no se puede acceder.

El SDCM no debe llevar a cabo una exportación si el usuario no tiene acceso completo para exportar las entidades solicitadas y sus marcadores de posición.

11.2.16 Integridad de la exportación

Las soluciones de SDCM se pueden construir alrededor de diferentes arquitecturas. La especificación permite a los diferentes productos implementar sus propios controles de acceso (ver 4. Servicio de Modelo de Roles) y sus propias definiciones de metadatos contextuales (ver 7. Servicio de Modelo de Metadatos). MoReq2010® también presenta un enfoque basado en el servicio, en el que entidades de diferentes tipos son administradas por servicios discretos, pero MoReq2010® no obliga a que se use este enfoque, permitiendo a cada proveedor elegir su propio método de implementar un SDCM, incluso como una sola aplicación no modular.

Estas libertades deben estar equilibradas por la necesidad de exportar todos los datos a un formato común que pueda ser entendido y usado por cualquier SDCM que implemente los requisitos del servicio de importación. Esto significa que las siguientes condiciones posteriores deben ser verdaderas cuando se exporta cualquier dato:

• Al menos en los datos que son exportados, las soluciones de SDCM deben exportar los controles de acceso como listas de control de acceso, entidades de control de acceso, y roles de MoReq2010

®;

• Al menos en los datos que son exportados, las soluciones de SDCM deben exportar los metadatos del sistema y los contextuales como definiciones del elemento de metadatos y plantillas de MoReq2010®;



• Al menos en los datos que son exportados, las soluciones de SDCM no deben exportar ninguna entidad personalizada o que tengan derechos de propiedad, o metadatos que no están descritos por una definición de un elemento de metadatos contextual que también sea exportada; y

• Al menos en los datos que son exportados, las soluciones de SDCM deben exportar las entidades agrupadas por tipo a sus servicios discretos.

El último de estos requisitos, que las entidades del mismo tipo se agrupen y se exporten como servicios, es necesario porque las soluciones de SDCM que soportan el servicio de importación deben también poder soportar múltiples servicios del mismo tipo. Por ejemplo, un SDCM con su propio servicio de clasificación puede entonces importar un servicio de clasificación desde otro SDCM. El servicio de clasificación importado puede incluso representar una estructura del esquema de clasificación diferente (ver 200. Módulo de Clasificación de Series).

Cuando un SDCM importa un servicio, como la clasificación, de otro sistema de documentos entonces las clases en ese servicio de clasificación o se pueden asignar a clases en su propio servicio de clasificación, o pueden ser importadas y gestionadas por el SDCM como clases inactivas que reflejan la estructura bajo la cual se mantuvieron en el sistema de origen de los documentos. La capacidad para elegir cualquiera de estos métodos de importación implica que los datos importados identifiquen las entidades como pertenecientes a un servicio discreto, aún si no estaban organizadas en esta forma en el sistema de documentos original.

11.2.17 El proceso de exportación

Cada vez que un SDCM lleva a cabo una exportación debe crear un Identificador de Exportación para esta. Este Identificador de Exportación está incluido en los datos XML así como el evento de exportación generado para cada entidad (ver R2.4.16). El mismo Identificador de Exportación se utiliza para todas las entidades y marcadores de posición que se exportan juntos como parte de una sola operación de exportación. El Identificador de Exportación permite a un usuario encontrar para cualquier evento de exportación, mediante una búsqueda, qué entidades fueron exportadas juntas. También permite al servicio de importación rastrear que entidades provienen de una sola fuente de SDCM, como una instantánea de un momento particular en el tiempo.

Cuando se exportan entidades, todas las soluciones de SDCM debe seguir el mismo proceso de exportación. A continuación se da una visión general del proceso de exportación.

1. Crear un Identificador de la Exportación, como se describió anteriormente;

2. Para cada entidad que se va a exportar completa, construir listas de entidades relacionadas que se deben exportar completas y los marcadores de posición relacionados que se deben exportar como marcadores de posición;

3. Iniciar la exportación y escribir el encabezado de la información incluyendo la información sobre el SDCM y con qué servicios es compatible, el Identificador de la Exportación, y así sucesivamente;

4. Exportar cada servicio correspondiente a la vez, y dentro de cada servicio realizar la exportación de cada entidad, exportando un bloque de marcadores de posición seguido por un bloque de entidades completas para cada tipo de entidad;

5. A medida que cada entidad se exporta, generar un evento de exportación y agregarlo



a la historia de eventos de la entidad;

6. Completar la exportación; o

7. En el evento en que haya una falla o una interrupción de la exportación, escribir los errores en el registro de errores externo (ver R2.4.7).

El formato de los datos a exportar y el orden en que las entidades y sus elementos de metadatos se exportan, está determinado por el esquema para el formato XML de MoReq2010®.

11.2.18 Eliminación de duplicados

Cuando se exportan entidades, el SDCM debe garantizar que cada entidad relevante se incluye una sola vez en cualquier proceso de exportación. Si una entidad se exporta completa entonces esta no deberá también exportarse como un marcador de posición en la misma exportación. Si muchas entidades se refieren a la misma entidad, entonces deberá exportarse una vez sin importar cuántas veces se le hace referencia.

11.2.19 Limitar el acceso a los datos una vez han sido exportados

Cuando se exportan entidades desde un SDCM, las entidades exportadas se traducen en un flujo de datos XML, los cuales no presentan ninguno de los controles habituales que son implementados por un SDCM. Esto plantea una serie de consideraciones de seguridad que deben ser tenidas en cuenta por cualquier organización que utilice el servicio de exportación:

• Cuidar que el usuario que emprende la exportación tenga acceso a todas las entidades que se deben incluir en la exportación – los usuarios no pueden exportar entidades en el SDCM a las que ellos no tienen acceso ni pueden inspeccionar;

• Los procedimientos operativos deben estar implementados para proteger la exportación y su contenido informativo – una vez que han sido exportados del SDCM los datos descritos por la exportación no están ya protegidos por el sistema y son solo un simple formato XML, las organizaciones deben considerar el cifrado o protegerlos de otra forma;

• Si los datos XML están en una forma legible se deben guardar de forma segura y el acceso se debe limitar solo a aquellos usuarios a los que se les autorice su acceso dentro del SDCM.

• Cuando los datos son sensibles, estos deben importarse al sistema de documentos de destino de tal forma que el SDCM que los importa, simultáneamente los asegure de modo que otros usuarios de los sistemas de documentos de destino no puedan automáticamente acceder a ellos. Esto es especialmente importante ya que las listas de control de acceso, que incluyen los usuarios, los grupos y los roles, del sistema de documentos de origen pueden no ser respetadas por el sistema de documentos de destino.

Se pueden requerir medidas adicionales si los datos se guardan fuera del SDCM por un período de tiempo largo. De preferencia, y en especial para datos sensibles, una exportación XML solo se debe conservar temporalmente y debe ser destruida, tan pronto como sea posible, después que se ha confirmado el éxito de la transferencia.



11.4 Requisitos Funcionales

R11.4.1

El SDCM debe permitir a un usuario autorizado exportar entidades a un archivo de datos XML que pueda validarse utilizando el esquema XML de MoReq2010® .

El SDCM debe permitir al usuario exportar cualquiera de los siguientes:

• Todos los usuarios y grupos, de forma colectiva, de un usuario y un servicio de grupos;

• Cualquier grupo nominado de forma individual con las entidades del usuario que pertenecen a estos grupos;

• Cualquier usuario nominado de forma individual;

• Todos los roles, de forma colectiva, de un servicio de roles;

• Cualquier rol nominado de forma individual;

• Todas las clases, de forma colectiva, de un servicio de clasificación:

• Cualquier clase nominada de forma individual;

• Todas las agrupaciones y documentos, con sus componentes, de un servicio de documentos;

• Cualquier agrupación nominada de forma individual y los documentos, con sus componentes, que ella contiene;

• Cualquier archivo nominado de forma individual, con sus componentes;

• Todas las definiciones de un elemento y las plantillas, de forma colectiva, de un servicio de metadatos;

• Cualquier plantilla nominada de forma individual con las definiciones del elemento de metadatos contextual que forma parte de la plantilla;

• Cualquier definición del elemento de metadatos contextual de forma individual;

• Todos los cronogramas de disposición, de forma colectiva, de un servicio de cronogramas de disposición;

• Cualquier cronograma de disposición nominado de forma individual;

• Todas las eliminacioneses retenidas, de forma colectiva, de un servicio de eliminacioneses retenidas; o

• Cualquier disposición retenida nominada de forma individual.

Ver 11.2.4 Flujo continuo de datos XML, la Junta de Gobierno de MoReq está estudiando el reemplazo de la exportación de entidades a un archivo de datos con la exportación de entidades a un flujo de datos estandarizado.

Esta futura iniciativa tiene el objetivo de resolver las actuales limitaciones técnicas y de derechos de propiedad durante la exportación, por ejemplo cómo brindar un mecanismo estandarizado para romper las



grandes exportaciones a lo largo de múltiples documentos de datos y qué tecnologías de compresión debe soportar un SDCM.


R11.4.2

Siempre que un SDCM exporte entidades, bajo R11.4.1 o R11.4.3, este, por defecto, no debe exportar entidades residuales a menos que el usuario autorizado de forma específica las incluya. Sin embargo, cuando el usuario decide hacerlo, el SDCM debe exportar todas las entidades, incluidas las activas y las residuales.

Por ejemplo, si el usuario exporta una agrupación, normalmente solo los documentos activos en la agrupación serían incluidos en la exportación. Sin embargo, el SDCM también debe darle al usuario la opción de exportar la agrupación e incluir tanto las entidades activas como las residuales.

R11.4.3

Cuando se prepara la exportación bajo R11.4.1, el SDCM debe primero determinar que entidades exportar completas, estas serían:

• Las entidades nominadas por el usuario autorizado bajo R11.4.1;

• Las entidades incluidas de cualquier entidad que se debe exportar completa (ver 11.2.10 para la definición de inclusión); y

• Los eventos de cualquier entidad que se debe exportar completa.

El SDCM debe entonces determinar que entidades exportar como marcadores de posición, estas serían:

• Todas las entidades a las que hacen referencia los elementos de metadatos de la entidades que se deben exportar completas, incluyendo sus eventos;

• Las definiciones del elemento de metadatos contextual para todos los elementos de metadatos contextuales de las entidades que debe exportar completas;

• Todas las entidades que son significativas para las entidades que se deben exportar completas o como marcadores de posición (ver 11.2.9 para una definición de significativa); y

• Todas las entidades a las que hacen referencia las listas de control de acceso de las entidades que deben ser exportadas completas o como marcadores de posición.

Estas reglas se deben aplicar repetidamente hasta que todas las entidades que deben ser exportadas completas y todas las entidades que deben ser exportadas como marcadores de posición se identifiquen; sujeto a R11.4.2, esto significa que, por defecto, solo las entidades activas deben ser incluidas a menos que el usuario también incluya las entidades residuales. No se debe incluir dos veces ninguna entidad y ninguna entidad debe exportarse como marcador de posición si, de forma simultánea, está siendo exportada completa.

R11.4.4

Cuando un usuario autorizado exporta una o más entidades bajo R11.4.1, entonces el SDCM



debe generar un identificador universal único para la exportación.

Ver R2.4.24. Cada exportación separada de un SDCM representa una instantánea de una parte del SDCM. Identificar cada exportación claramente y de forma única a medida que se hace, permite a otro SDCM importar una serie de exportaciones en el tiempo y de forma más fácil y precisa unir nuevamente la información.

El Identificador de Exportación se guarda como parte del evento de exportación para cada entidad incluida en la exportación, ver R11.4.7.

R11.4.5

Cuando un usuario autorizado exporta entidades bajo R11.4.1, entonces el SDCM debe permitir que el usuario haga un comentario de texto que se debe incluir en los datos de exportación bajo R11.4.6, y el evento de exportación bajo R11.4.9.

El comentario de texto es una explicación que hace el usuario que inicia la exportación de por qué se hizo la exportación y qué contiene.



R11.4.6

Una vez se ha iniciado una exportación bajo R11.4.1, el SDCM debe exportar lo siguiente:

• Una Marca de Tiempo de Inicio de la Exportación;

• El Identificador de la Exportación generado bajo R11.4.4;

• Los comentarios de la exportación incluidos bajo R11.4.5;

• Un encabezado de la exportación que contenga la identificación completa y la información de los servicios que soporta el SDCM, ver R2.4.5;

• Los metadatos y las listas de control de acceso para cada servicio, ver 11.2.11 Exportación de listas de control de acceso;

• Para cada servicio las entidades que se deben exportar, agrupadas en marcadores de posición o entidades exportadas completas, ver R11.4.3; y

• Una Marca de Tiempo de Exportación Terminada.

El esquema XML de MoReq2010® especifica el formato de exportación completo y detallado que se debe cumplir.

R11.4.7

Para cada entidad que debe ser exportada completa, bajo R11.4.3, el SDCM debe exportar los valores de cada uno de sus elementos de metadatos, incluyendo tanto los del sistema como los elementos de metadatos contextuales, y su lista de control de acceso.

El SDCM debe exportar tanto los elementos de metadatos del sistema como los elementos de metadatos contextuales para las entidades que se deben exportar completas, incluyendo sus eventos. Todos los metadatos en la lista de control de acceso de la entidad y sus entradas de control de acceso también se deben exportar.

R11.4.8

Para cada componente a ser exportado completo, bajo R11.4.7, el SDCM debe exportar el contenido del componente, sujeto a las disposiciones especiales especificadas por el MoReq2010® aplicable, 300. Módulo de Series de Componentes para el sub tipo del componente de la entidad.

El contenido de diferentes tipos de componentes serán exportados en diferentes formas, como lo especifica el módulo de complementos (plug-in) para el tipo de componente apropiado. En general, el contenido de los componentes será o incluido en la exportación XML, o exportado por separado pero referenciado por la exportación XML, o exportado por separado y sin ser referenciado por la exportación XML.

R11.4.9

Para cada entidad exportada como un marcador de posición, bajo R11.4.3, el SDCM debe exportar los valores de cada uno de sus elementos de metadatos del sistema, y su lista de control de acceso.

Para las entidades marcadores de posición los valores de los elementos de metadatos contextuales no se



exportan. Todos los metadatos en la lista de control de acceso de un marcador de posición y sus entradas de control de acceso se deben exportar.

R11.4.10

Para cada entidad exportada completa, bajo R11.4.7, y para cada entidad exportada como un marcador de posición, bajo R11.4.9, el SDCM debe agregar a la historia de eventos de la entidad un evento que incluye:

• El Identificador de Exportación, ver R11.4.4;

• Una Bandera de Exportada Completa; y

• El comentario de la exportación, como el Comentario del Evento, ver R11.4.5.

Si una exportación solo se completa parcialmente, ya sea porque fue cancelada, o porque fallo, o por cualquier razón, entonces solo se deberán generar los eventos para aquellas entidades que fueron exportadas con éxito antes de la terminación del proceso de exportación.

La Bandera de Exportada Completa indica si una entidad fue exportada completa o por el contrario como un marcador de posición.

Note que con cada exportación bajo R11.4. se exporta la información de un servicio, y los servicios no son exportados como entidades, entonces no se genera un evento de exportación cuando un servicio es exportado.

Funciones de referencia: F14.5.10, F14.5.29, F14.5.43, F14.5.52, F14.5.62, F14.5.76, F14.5.100, F14.5.127, F14.5.148, F14.5.170, F14.5.185, F14.5.186



12. Requerimientos no funcionales.12.1 Conceptos Clave

12.1.1 Requerimientos no funcionales en MoReq®

Los requerimientos no funcionales siempre han sido una parte importante de la especificación

MoReq® desde la publicación original MoReq® en 2001. Éstos especifican los aspectos cualitativos que no son necesariamente explícitos solamente a través de los sistemas funcionales en los sistemas de archivo. Los requerimientos funcionales tienden a enfocarse en los comportamientos específicos que son requeridos por el sistema, sin enfocar factores ambientales, operacionales, de infraestructura y confort que están estrechamente relacionados.

Por su naturaleza, los requerimientos no funcionales son menos definitivos y mas subjetivos que los requerimientos funcionales. Son más difíciles de especificar de forma en que puedan ser aplicados universalmente, son mas abiertos a interpretaciones y son mas difíciles de cuantificar, medir y probar.

Sin embargo, la experiencia adquirida con las versiones anteriores de MoReq® muestran que tanto las organizaciones de proveedores como de consumidores obtienen información práctica e importante de los requerimientos no funcionales de la especificación. Esto ha ayudado a los proveedores a elevar la calidad de sus productos, y a las organizaciones de consumidores a seleccionar los sistemas de archivo que son afines a las necesidades y ambientes de su empresa. Es interesante notar que durante la fase de consulta que llevó al desarrollo de

MoReq2010® los contribuidores demostraron una clara preferencia por retener y aumentar la parte de la especificación que cubrió los requerimientos no funcionales.

12.1.2 Requerimientos funcionales y no funcionales de MoReq2010®

Dentro de una declaración de requerimientos, los limites entre los aspectos puramente funcionales y los no funcionales de la especificación, son usualmente subjetivos y difíciles de

definir con claridad. MoReq2010® ha sido diseñado con el propósito de que sus requerimientos no funcionales puedan suplir una capacidad diferente y separada de los requerimientos funcionales.

Las características de estos dos tipos de requerimientos dentro de MoReq2010® pueden ser expresados de la siguiente manera:

Requerimientos Funcionales

• Los requerimientos funcionales en MoReq2010® son expresados en enunciaciones cerradas, por ejemplo: “El SDCM debe…” o “ El SDCM no debe…”;



• Cada requerimiento funcional se relacional directamente con una (en algunos casos más de una) función explícita que debe ser llevada a cabo por un SDCM;

• Cada uno de los requerimientos funcionales en MoReq2010® están acompañados por una razón fundamental que provee una aclaración adicional del requerimiento;

• Las funciones explícitas descritas por el requerimiento funcional son identificables de manera individual, son listadas bajo 14.5 Definiciones Funcionales, y son utilizadas

y referidas por la arquitectura de MoReq2010®, tanto en el modelo de control de acceso (ver 4. Servicio de Modelo de Rol) y el evento modelo (ver 2. Servicios de sistemas); y

• Los requerimientos funcionales de MoReq2010® son verificables por casos de prueba y guiones dentro del marco de referencia que acompaña la especificación. La prueba de un producto o instalación por un centro acreditado de prueba sobre estos requerimientos funcionales, puede llevar posteriormente a un certificado de cumplimiento por parte de DLM Forum.

Requerimientos no funcionales.

• Un requerimiento no funcional en MoReq2010® se relaciona con una característica deseada o calidad de SDCM;

• Por cada uno de los requerimientos no funcionales en MoReq2010® la razón fundamental, razón, o premisa está listada primero y luego es seguida por el requerimiento no funcional;

• Cada requerimiento no funcional es expresado como una pregunta abierta o cerrada que es dirigida al proveedor, una de una solución SDCM, por ejemplo: “ ¿Cómo puede este sistema de archivo asegurar…” o “¿Qué previsión hace este sistema de archivo para…”;

• MoReq2010® No requiere que los productos o instalaciones sean puestos a prueba por conformidad contra los requerimientos no funcionales, y no tiene una disposición

para esto en el marco de prueba MoReq2010®, aunque requerimientos no funcionales pueden ser evaluados por una organización individual fuera del marco de prueba;

• Sin embargo, para ser certificado por MoReq2010® cada proveedor debe documentar y presentar, como parte de la fase de pre calificación de prueba y certificación, sus respuestas a los requerimientos no funcionales, como son relacionados específicamente al producto o servicio que se desea evaluar (este proceso es descrito bajo 12.2.4 Acerca de los requerimientos no funcionales).

12.1.3 Lo que está cubierto por los requerimientos no funcionales.

Los requerimientos no funcionales tienen en consideración los siguientes aspectos de un SDCM, y son descritos en mayor detalle en 12.3 los aspectos no funcionales de un sistema de archivo. Estos sistemas de archivo deben tener las siguientes cualidades:

• Rendimiento, • Escalabilidad,• Manejabilidad,• Portabilidad,• Seguridad,• Privacidad,• Usabilidad



• Accesibilidad,• Confiabilidad,• Recobrabilidad,• Mantenimiento, • Soporte,• Garantía y • Cumplimiento.

MoReq2010® no provee necesariamente una lista comprensiva o exhaustiva de requerimientos no funcionales, para sistemas de archivo cubriendo todos estos aspectos. En muchos casos este será específico para una organización, industria, tipo de sistema, ambiente, legislación o régimen regulador particular. La importancia que esta puesta en requerimientos no funcionales particulares también será distinta para las diferentes partes interesadas.

12.1.4 Acerca de los requerimientos no funcionales

Los procedimientos del Foro DLM para certificar productos e instalaciones contra la

especificación MoReq2010® requieren un número de pasos. Antes de empezar a hacer la prueba formal de un producto o instalación el proveedor debe completar el proceso de pre-calificación. Como parte de éste proceso el proveedor debe describir el producto o instalación que esta presentándose para la certificación. Esto incluye proporcionar respuestas escritas detalladas para cada uno de los requerimientos, tanto funcionales como no funcionales, para

los servicios nucleares y módulos de MoReq2010® que están siendo probados.

Por esta razón los requerimientos no funcionales de MoReq2010® son expresados como preguntas, y los proveedores deben documentar sus respuestas a cada una de éstas preguntas con respecto a su particular producto o instalación, contra los requerimientos funcionales

(solamente) de MoReq2010® usando el marco de prueba de evaluación.

Al completar con éxito la fase funcional, y siguiendo cualquier corrección a las respuestas originales del proveedor, las repuestas del proveedor a los requerimientos funcionales y no funcionales serán incorporadas al reporte de verificación de la evaluación completa junto con los resultados de la prueba y las recomendaciones del centro de prueba. Bajo varios términos y condiciones legales, especificados de manera separada y manejados por la Mesa Directiva de MoReq, la verificación de los reportes de la prueba, para productos certificados será puesta a disposición para ser vista y tener admisión por los miembros del DLM Forum.

De ésta manera, mientras que los productos e instalaciones de un proveedor nunca son examinados formalmente contra los requerimientos no funcionales, al ser incluidos en el reporte del examen de verificación, las respuestas del proveedor a las preguntas dadas por los requerimientos no funcionales se convierten en parte importante del recurso de referencia. Las respuestas del proveedor pueden convertirse en parte instrumental para ayudar a las organizaciones de consumidores a encontrar el mejor ajuste entre las necesidades locales

organizacionales y el rango de soluciones certificadas de MoReq2010® que están disponibles en el mercado.



Ésta inclusión de los requerimientos no funcionales es parte del proceso de certificación, aunque no son evaluados formalmente le da importancia adicional a su consideración bajo

MoReq2010® en contraste con la que tuvo en las versiones anteriores de la especificación.

12.1.5 Evaluación de los requerimientos no funcionales.

Mientras que el marco de prueba de evaluación de MoReq2010® no tiene la previsión de una prueba formal con respecto a los aspectos no funcionales del sistema de registro, esto no debería ser interpretado como si los requerimientos no funcionales nunca podrán ser evaluados o medidos de manera empírica. Muchas organizaciones pueden desear hacer esto como parte de su proceso de evaluación contra su propio criterio de evaluación.

A diferencia de la evaluación de los requerimientos funcionales, donde un sistema de archivo es aprobado o eliminado en cada uno de los criterios, evaluar el cumplimiento o no cumplimiento en los requerimientos no funcionales es un ejercicio más subjetivo. Usualmente esto tendrá como consecuencia que el sistema de archivo reciba un puntaje contra una escala o una extensión continua.

Por ejemplo, un requerimiento no funcional puede aseverar que un sistema de archivo debe estar proveído por una adecuada documentación de usuario. ¿Cómo puede ser esto evaluado? y ¿Cuál es el significado de la palabra adecuada? Cada organización debe juzgar por si misma.

Una forma de evaluar la calidad de la documentación del usuario puede ser el de darla un grupo de prueba de usuarios de una organización que ha pedido evaluarla, y usar la información bajo variadas condiciones de evaluación para luego contrastarla con diferentes criterios, por ejemplo:

• ¿Fue indexada y organizada lógicamente?• ¿Cuánto tiempo tomó encontrar la sección relevante?• ¿Cuánta asistencia se presto al llevar a cabo la tarea?• ¿Usó lenguaje adecuado y entendió Ud. Cualquier tipo de jerga?• Etc.

Posteriormente se puede pedir a los usuarios evaluar su experiencia con la documentación del usuario en una escala de Likert de cinco puntos, por ejemplo:

1. No se puede usar, ininteligible o faltante;2. Documentación pobre o irregular;3. Una vez la sección fue encontrada fue aceptable y entendible;4. Buena calidad, buena diagramación e índice, o5. Excelente, relevante, fácil de encontrar y extremadamente útil.

Este proceso de hacer un ensayo del sistema con un grupo piloto de usuarios de una organización y cotejar sus respuestas es usualmente conocido como “Prueba de aceptación del usuario” de un sistema de archivo, y es uno de un número de evaluaciones que incluyen, pero no están limitadas por los siguientes ejemplos:



• Prueba de aceptación del usuario;• Prueba de seguridad/penetración;• Prueba de carga;• Prueba de estrés;• Prueba de instalación y configuración;• Prueba de recuperación de desastres;• Prueba de interoperabilidad; y• Prueba de ambiente.

Los aspectos no funcionales de un sistema de archivo también pueden ser evaluados al ser contrastados con estándares y especificaciones externas cuando sea posible. Por ejemplo: evaluación frente a las series ISO/IEC 27000, estándares de seguridad de la información. Pueden haber también requerimientos locales que pueden ser aplicables a una jurisdicción en particular. Por ejemplo en el Reino Unido, el estándar británico BSI DISC PD0008 que tiene que ver con “La admisibilidad y el peso de la evidencia de la información guardada electrónicamente” (2009), y que viene acompañada de un libro de trabajo que permite a una organización llevar a cabo una evaluación independiente en relación con una instalación en particular.

Dónde hay estándares relevantes, como los descritos previamente, éstos ofrecen un punto de referencia con el que productos individuales e instalaciones pueden ser juzgados. De otra manera la evaluación de los requerimientos no funcionales necesita ser relativa en vez de absoluta, requiriendo la evaluación de dos o más sistemas de archivo uno contra el otro, para descubrir por comparación directa cual es el más adecuado al juzgar un requerimiento no funcional en particular.

Fuera de la observación directa y la evaluación, las organizaciones pueden utilizar la verificación, y adjudicar las respuestas de los proveedores a los requerimientos no funcionales para las soluciones SDCM, como están contenidas en el reporte de la evaluación de verificación, al tomar chequeos de referencia y visitas a instalaciones que ya han desarrollado y están usando la solución de un proveedor. Otras organizaciones que sean comparables pueden ofrecer datos empíricos contrastando los requerimientos no funcionales, como por ejemplo:

• El numero de problemas de soporte que han sido expuestos;• La respuesta de los proveedores a problemas críticos;• La cantidad de capacitación para el usuario que sea requerida;• El porcentaje de tiempo de funcionamiento de un sistema en un período de tiempo

determinado;• La frecuencia de actualizaciones de un producto;• El nivel general de satisfacción en la comunidad de usuarios;• Etc.

Es importante, al valorar y evaluar un requerimiento no funcional tener en cuenta las necesidades de todas las diferentes partes interesadas dentro de la organización. Las organizaciones pueden desear formalizar un nivel aceptable de funcionamiento contrastándolo

con los requerimientos no funcionales de MoReq2010® al entrar a un acuerdo de nivel de servicio del proveedor.



12.2 Los aspectos no funcionales de un sistema de archivo.

12.2.1. Funcionamiento

El funcionamiento se relaciona con las repuesta, eficiencia y rendimiento de un sistema de archivo al estar cargado. Es difícil evaluar adecuadamente en una demostración del sistema, o en un estudio piloto, o en un modelo de oficina y que puede cambiar considerablemente cuando la organización completa esta usando el sistema de archivo. El desempeño suele ser muy dependiente en el hardware, como es el ancho de banda de una red, núcleos de una CPU y ciclos, capacidad de la memoria, la cantidad de espacio de almacenamiento, etc. Un cuello de botella puede ser la causa de que todo el sistema se vuelva mas lento.

La organización y el proveedor pueden poner en marcha un acuerdo de nivel de servicio sobre el funcionamiento que estipule, por ejemplo, cuanto tiempo debe tomar el crear un archivo, cuanto tiempo debe tomar el encontrar y recobrar un archivo, etc.

12.2.2 Escalabilidad

La escalabilidad se relaciona con el funcionamiento y la capacidad de un sistema en el tiempo y bajo una carga que aumenta. Al aumentar el número de documentos al mismo tiempo que el número de usuarios y la consecuente carga al sistema, ¿Es fácil para el sistema de archivo mantener el mismo nivel de funcionamiento estipulado bajo 12.3.1?Usualmente los proveedores buscan preveer la escalabilidad ya sea:

• Ampliando – aumentando el tamaño y la capacidad del sistema de archivo; o• Prever la cantidad – balancear el aumento de carga entre diferentes sistemas, o a través

de servicios múltiples.

Las organizaciones pueden desear evaluar el sistema bajo estrés antes de desplegarlo para evaluar tanto su funcionamiento como su escalabilidad.

12.2.3 Capacidad de gestión

Un sistema de archivo debe tener una previsión para su propio manejo y administración. Hay dos aspectos frente a esto:La administración técnica de un sistema de archivo incluye;

• Instalación y configuración;• El monitoreo del uso de los recursos del sistema;• Aumentar espacio de almacenamiento adicional y otras capacidades al ser requeridos;• Acceder y manejar el registro de errores;• Actualizar el sistema de archivo; y• Solucionar problemas y resolver conflictos técnicos.



La administración de sistemas de archivo desde la perspectiva del administrador de archivo, incluye:• Administración de reportes;• Usar estadísticas en el uso del sistema por los usuarios, por ejemplo, el número y tipo

de búsquedas hechas;• Cotejar y monitorear las estadísticas de un número de documentos y entidades

relacionadas con varios tipos que estén siendo administrados; • Suministro de facilidades que permitan la auditoria de el sistema de archivo;• Etc.

12.2.4 Portabilidad

La portabilidad ser refiere a la habilidad de un sistema de archivo para operar exitosamente en diferentes ambientes. Un sistema de archivo puede estar diseñado para ejecutarse solamente dentro de un solo tipo de tecnología que es proveída por el vendedor de un solo sistema operativo, como en el servidor de Windows de Microsoft y ambientes de cliente, o un sistema de archivo puede funcionar a través de diferentes plataformas.

Algunos sistemas de documentos pueden tener un componente de servidor, que esta unido a un ambiente de operación particular, y darle soporte a un componente de cliente que no lo esta. En el interés de la portabilidad, un proveedor puede elegir el proporcionar un rango de diferentes clientes para la red o para plataformas específicas, sistemas operativos y dispositivos móviles.

Para los sistemas de archivo que están diseñados para hacer una interface con otros sistemas de negocios, la portabilidad depende del soporte para la resolución de la interconexión de un rango de diferentes estándares y tecnologías. Por ejemplo, una interface de Java, o servicios de red, o REST basado en las IAP (Interface de Aplicación de Programación)

Donde el sistema de archivo no es solamente un componente especializado de un más amplio sistema de negocios, puede haber poca opción sobre cuales tecnologías puede soportar. Por ejemplo, un sistema de archivo puede estar diseñado para soportar y ser parte de una solución para la gestión de la relación específica con el cliente.

La portabilidad también se extiende al grado con el que una solución puede ser personalizada para diferentes ambientes, a pesar de que la personalización y las opciones de instalación, aunque son útiles, pueden ser también problemáticas para el sistema de archivo como está explicado bajo 12.2.15 Conformidad.

12.2.5 Seguridad.

La seguridad se relaciona con la integridad externa del sistema de archivo y su habilidad para resistir acceso no autorizado, piratería o manipulación, virus de computadora, y otras formas accidentales o maliciosas de daño. Pruebas de penetración y evaluaciones de seguridad bajo los estándares de información de seguridad de ISO 27000 son recomendables. Idealmente un sistema de archivo debería ser:



• Físicamente seguro – Con acceso restringido a su hardware, equipo e instalación de software integral para su operación;

• Seguro en sus datos – Asegurando que la información guardada en un servidor o en dispositivos de clientes no es accesible excepto a través de la aplicación misma;

• Seguro frente al acceso no autorizado – Requiriendo uno o mas factores de autenticación;

• Seguro en sus comunicaciones – Usando certificados digitales y encriptación cuando sea posible para asegurar que la información sea intercambiada solamente con el destinatario proyectado; y

• Seguro internamente – Ejecutando controles de acceso que no permitan que diferentes usuarios ejecuten funciones y accedan a entidades cuando no han tenido permiso explicito para hacerlo.

12.5.6 Privacidad

Relacionado muy cercanamente con la seguridad, es importante que cualquier sistema de archivo respete la información y datos privados. Esto es particularmente importante para sistemas de archivo que tengan como fin guardar información sensible, como los documentos médicos.

Muchos países, tanto adentro y afuera de Europa, tienen disposiciones acerca de la privacidad de la información personal. Cada sistema de archivo debe obedecer estas regulaciones y así proteger el derecho de los ciudadanos en la jurisdicción local donde esta desplegado. Por ejemplo, la directiva europea de privacidad de datos, Directiva 95/46/EC de el parlamento europeo y el consejo (Directive 95/46/EC of the European Parliament and of hte Council) regula el procesamiento de los datos personales; tiene medidas para notificar a los sujetos cuando sus datos personales están siendo tomados, incluyendo la garantía del derecho a acceder y a objetar, también presenta restricciones al transferir datos personales a países en tercera instancia.

Esto tiene directa relevancia en los sistemas de archivo, por ejemplo, donde las entidades en éste pueden ser guardados, particularmente en relación con el almacenamiento internacional o basado en una nube previsto por un SDCM.

12.2.7. Facilidad de uso.

La facilidad de uso es una consideración importante en un sistema de archivo, especialmente por la aceptación del usuario. La experiencia demuestra que los usuarios dejarán de lado un sistema que sea demasiado complejo o que su uso requiera de mucho tiempo. Esto tiene serias consecuencias para los sistemas de archivo en organizaciones, si documentos importantes no están siendo obtenidos o si los empleados no están tomando ventaja del conocimiento corporativo acumulado que estos contienen.

Algunas de las características de un sistema de archivo que más contribuyen al fácil uso incluyen:

• Interfases limpias, despejadas y familiares;• Consistencia durante la aplicación y dentro del ambiente operativo;



• Capacidad de respuesta del sistema;• Mensajes de error o diálogos informativos;• Procesamiento automático, proporcionando configuraciones por defecto útiles, y otras

formas de minimizar el número de decisiones que los usuarios deben tomar;• Minimizar el número de acciones necesarias por parte del usuario para llevar a cabo

una operación.• Proporcionando vías alternativas para ejecutar funciones comunes, como por medio de

combinaciones de teclas del teclado, botones en la barra de herramientas, etc;• Activar procesamiento de volumen;• Soporte para la internacionalización;• Soporte para la personalización y localización;• Facilidades de ayuda sensibles al contexto;• Documentación de usuario de alta calidad;• Preguntas frecuentes; y • Videos y tutoriales en línea.

Programas de capacitación y educación son usualmente esenciales para el consumo y aceptación de un nuevo sistema y los sistemas de archivo no son diferentes en este respecto.

12.2.8 Accesibilidad

Cercanamente relacionado con la facilidad de uso, los sistemas de archivo deberían idealmente ser asequibles a todo tipo de usuario, con diferentes capacidades, incluyendo aquellos con discapacidades específicas. Dichos usuarios juegan un papel importante en todas las áreas de actividad humana donde interactúan regularmente con los sistemas de archivo. Muchas organizaciones y empresas ejemplares protegen los derechos de sus empleados a acceder cualquiera de sus sistemas técnicos, y como consecuencia solo comprarán soluciones que incorporan amplias disposiciones para la accesibilidad.

Uno de los principales proponentes para la evaluación activa de los requerimientos no funcionales para la accesibilidad es el World Wide Web Consoritum (W3C) Web Accessibility Initiative (WAI). El W3C WAI provee las guías para el acceso al contenido en la red, las cuales cubren recomendaciones para hacer el contenido de la red mas accesible.

“Siguiendo estas guías hará que el contenido sea más accesible a un mayor rango de personas con discapacidades, incluyendo la ceguera o falta de visión, sordera o perdida de la escucha, dificultades de aprendizaje, limitaciones cognitivas, movimiento limitado, problemas de habla, fotosensibilidad y la combinación de éstas. El seguimiento de estas guías también hará que el contenido de la red sea más usado por los usuarios en general.” (WCAG 2.0:2008, Abstract) A cambio de cada guía, las guías para el acceso del contenido en la red (WCAG por sus siglas en Inglés Web Content Accessibility Guidelines) proveen criterios exitosos que puede ser probados y evaluados. Estas pruebas de los criterios permiten tres niveles de conformidad:

• A – La solución satisface los puntos de control necesarios; • AA – La solución satisface los puntos de control obligatorios así como los altamente

deseables; y



• AAA – La solución satisface los puntos de control obligatorios, los deseables y los altamente deseables dentro de la especificación de la WCAG.

Aunque la especificación WCAG es necesaria para aplicaciones de la red, la accesibilidad es una consideración importante para todos los sistemas de archivo, y estos mismos principios deberían ser adoptados en todas las plataformas.

12.2.9 Disponibilidad

Los requerimientos de disponibilidad son consideraciones importantes al evaluar cuales de las implementaciones de sistemas de archivo serán adecuadas para las prácticas de negocio de una organización y son usualmente expresadas como un porcentaje o radio del tiempo de actividad comparado con el tiempo de inactividad.

Dependiendo de la naturaleza de la organización, algunas organizaciones requieren acceso a los sistemas de archivo durante las horas de trabajo de Lunes a Viernes, mientras que otras organizaciones requieren acceso y soporte 24X7 (24 horas al día 7 días de la semana). No todos los sistemas de archivo son capaces de correr indefinidamente sin necesitar mantenimiento regularmente planeado, actualizaciones y ventanas de reserva cuando tienen que quedar fuera de línea. Sin embargo, cada empresa tiene ciertos períodos críticos donde la disponibilidad del sistema es esencial.

El nivel de disponibilidad que una solución en particular puede proporcionar debe estar claramente establecido por el proveedor en respuesta a los requerimientos no funcionales. Esto debería también estar incluido en todos los acuerdos sobre niveles de servicio entre el proveedor y la organización. Cuado un sistema de archivo esta alojado con un tercer proveedor, un acuerdo de nivel de servicio separado que cubra la disposición del servicio de alojamiento puede ser también necesario. De la misma manera, la organización debe ser realista acerca de sus necesidades para usar el sistema de archivo, si es a toda hora, día o noche, pues un sistema de servicio y soporte de 24 horas por parte del proveedor, o el integrador del servicio vendrá necesariamente con un costo mayor para la organización.

Si una organización ha estado de acuerdo con un nivel particular de disponibilidad del sistema de archivo en un acuerdo de nivel de servicio, entonces la disponibilidad del sistema deberá estar constantemente monitoreada para observar si las metas del servicio están siendo alcanzadas o si han sido sobrepasadas. Aparte de cualquier penalidad establecida en el acuerdo de nivel de servicio, el monitoreo del tiempo de actividad, especialmente frente al uso, dará una útil retroalimentación tanto al proveedor como a la organización, al ayudar a establecer el nivel de expectativas acerca de la disponibilidad de sus sistemas de archivo.

12.2.10 Confiabilidad.

La confiabilidad esta descrita como la integridad interna de un sistema, la precisión y exactitud de su software, y su resistencia a los defectos, problemas de funcionamiento o inesperadas condiciones de operación. Es posible aplicar algoritmos de prueba de corrección a los sistemas de archivo, así como se puede evaluar su tolerancia a datos inválidos y otras ocurrencias no



esperadas como la repentina falta de comunicación. Sistemas de archivo realmente robustos serán capaces de manejar condiciones de error, sin quiebra o falla repentina.

La confiabilidad esta también cercanamente relacionada con disponibilidad del sistema, la confiabilidad es usualmente medida como “el tiempo entre fallas”. Sistemas que sean mas confiables tendrán mas tiempo de activad del sistema y mucho menos tiempo de inactividad no planeado, haciéndolos más disponibles. De la misma manera un sistema de archivo más confiable generalmente será más fácil de mantener y soportar activamente por el proveedor.

La evaluación a la estructura de MoReq2010® puede ser usada por centros acreditados de prueba para probar los requerimientos de funcionamiento de sistemas de archivo dóciles, y esto provee una medida de confiabilidad de un sistema de archivo al desempeñar tareas esenciales para la administración de documentos. Sin embargo la evaluación de la estructura por si misma no evalúa todas las posibles entradas y salidas del sistema de archivo, y una organización puede desear no confiar solamente en esta única medida al comparar la confiabilidad y la calidad de diferentes sistemas de archivo.

12.2.11 Capacidad de recuperación.

Si un sistema de archivo falla por cualquier razón, es importante que la organización sea capas de recobrarlo con la mayoría de los datos intactos. Puede ser que las operaciones que estaban sucediendo en el momento de la falla no puedan ser recuperadas, sin embargo, la organización debe asegurarse de la misma manera de no ser dependiente de información que ha sido guardada y que sea más antigua de un día, especialmente en ambientes de alto volumen.

No solo deben los sistemas de archivo ser recuperados o reconstruidos, sino que también esto debe ser hecho en una manera oportuna, para evitar un impacto innecesario en los negocios críticos de una organización. Un proceso de recuperación de un desastre que quiera decir que los sistemas de archivo deban estar fuera de línea por varios días o semanas puede no ser apropiado para muchas empresas. Para otras empresas, tiempo de inactividad no planeado aún si es por pocas horas, puede ser demasiado largo. Como con otros requerimientos no funcionales, los requerimientos alrededor de una recuperación de desastre variarán substancialmente entre las diferentes organizaciones. Es esencial que las necesidades de la organización seas evaluadas antes de que ocurra cualquier desastre, y que se tenga un completo y comprensivo plan de continuidad de negocios en toda la organización.

La experiencia demuestra que los requerimientos de continuidad de empresa deben ser planeados transversalmente en todos los sistemas críticos de la empresa, y no para sistemas individuales, como el sistema de archivo solamente. Esto se da porque el sistema de archivo es solo una parte de la infraestructura corporativa. Si los sistemas de archivo, por ejemplo, dependen un hardware particular, entonces la organización debe tener acceso a un hardware de reemplazo en un tiempo límite para que alcance las metas puestas para la recuperación del sistema de archivo.



Es también buena práctica el hacer pruebas constantes de recuperación de desastre para que el personal sepa el proceso y procedimiento para restaurar el sistema de archivo de cualquier falla del sistema, y para que se sepan los tiempos reales de recuperación completa del sistema. Al crecer la cantidad de datos administrados por un sistema de archivo en el tiempo, las expectativas de la organización sobre el período de tiempo requerido para recuperar el sistema de archivo, pueden no seguir el paso con el tiempo real necesario para transferir físicamente los datos de la organización en un nuevo sistema recientemente reconstruido.

Algunas organizaciones que tienen misiones críticas no pueden permitir horas o minutos de tiempo de inactividad para una recuperación de desastre. Estas organizaciones deben considerar el correr múltiples sistemas de manera paralela con imagen de espejo, que les permita cambiar entre sus documentos en vivo, y que sus reservas de archivo estén en espera activa, espera secundaria o en espera fría. Alternativamente, una organización puede correr un único sistema pero con muchas capas de componentes de hardware y software como los computadores, routers y discos duros mientras que el sistema en su totalidad se mantiene operacional.

La capacidad de recuperación, como la disponibilidad, le costará más a la organización por un mayor nivel de redundancia y inmediatez especificada. En cuyo caso, las organizaciones deben cuidarse de entender las necesidades de su propio sistema de recuperación de desastre, y de especificar metas realistas dentro de su plan de continuidad. En dónde el alcanzar las metas es una misión crítica, la organización debe buscar una evaluación de recuperación y poner en práctica un acuerdo de nivel de servicio con el proveedor, para asegurarse de que su sistema de archivo cumpla con los requerimientos operacionales de la organización.

12.2.12 Mantenimiento

Un sistema de archivo debe poder ser mantenido. Esto quiere decir que debe ser relativamente fácil de reparar y actualizar. La mayoría de los proveedores tendrán un sistema de mantenimiento con versiones mayores y menores, que pueden ser llamadas de variadas maneras, como por ejemplo: nuevas versiones, paquetes de servicios o parches. Cada uno de éstos tendrá un costo asociado con su despliegue en termino de los recursos y el tiempo que toma el despliegue transversal en la organización, y en el caso de que incluyan nuevas características y funciones, puede que necesiten una nueva capacitación y costos de educación para los usuarios. Como una regla general entre mas grande el lanzamiento es más posible que haya un impacto en la organización, incluyendo la posible migración de datos desde una versión anterior.

Los sistemas de archivo no son siempre construidos a partir de los componentes de un solo proveedor. Usualmente los proveedores licencian (o “OEM”) los componentes como los motores de búsqueda o las bases de datos de otros proveedores, o el desplegar el equivalente a un código abierto con sus aplicaciones. El reutilizar o unir diferentes tecnologías puede llegar a ser mucho más eficiente que un solo proveedor reinventando cada componente de cada sistema de archivo. Sin embargo, las organizaciones deben estar conscientes de las uniones de diferentes tecnologías dentro de su sistema de archivo pues éstas pueden requerir actualizaciones individuales en momentos y por razones diferentes.



Por ejemplo, un sistema de archivo puede usar un muy conocido motor de base de datos hecho por un proveedor individual de bases de datos. Cuando este proveedor actualice o cree un parche para el software de la base de datos, estos cambios deben ser probados para ver su compatibilidad con la solución del sistema de archivo. En ese orden de ideas, las actualizaciones al sistema de archivo deben estar al paso con el motor de búsqueda, la solución de almacenamiento, y otras partes del sistema de archivo.

12.2.13 Soporte

Sin tener en cuenta el tipo de mantenimiento que un sistema, el proveedor debe mantenerlo activamente. La experiencia demuestra que muchas organizaciones poseen sistemas en herencia en los que el proveedor ha desaparecido del comercio, o ha decidido mantener pero no actualizar una solución en particular para un sistema de archivo.

Por esto, antes de comprar un sistema de archivo, la organización debe pedir los detalles del nivel de mantenimiento y soporte que se le da a un producto, cada cuanto se actualiza, cuando fue liberada la última versión, y cual es la hoja de ruta del proveedor para el sistema de archivo.

Las organizaciones deben entender que el mercado de la información tecnológica moderna es altamente volátil y aún con estas precauciones no se puede prevenir que un sistema de archivo en el futuro no sea soportado, aún por parte de los grandes proveedores.

Afortunadamente, MoReq2010® ofrece alguna consolación a través de su soporte y interoperabilidad. En el peor de los casos, la organización deberá migrar sus documentos desde su antiguo SDCM a un una nueva solución de SDCM.

El soporte también se refiere al nivel de soporte día a día dado por el proveedor o un tercero en representación del proveedor. Las Organizaciones deben buscar aprender como pedir ayuda del proveedor, como reportar errores, problemas del software, y que tipo de nivel de ayuda in situ y asistencia pueden esperar. Muchos proveedores tiene grupos activos de usuarios donde las diferentes organizaciones se reúnen y comparten experiencias, consejos y recomendaciones, así como otro tipo de información sobre cómo usar mejor un sistema de archivo en particular.

12.2.14 Garantía

La organización debe estar perfectamente al corriente de las licencias y otros términos y condiciones relacionados con la instalación y uso de un sistema de archivo de su proveedor en particular. Aún las soluciones de código abierto tienen derechos de propiedad intelectual y condiciones de uso asociadas a éstos.

Al estar de acuerdo con los términos y condiciones de un proveedor para implementar un sistema de archivo, una organización debe asegurarse de recibir la garantía del proveedor cubriendo el uso del sistema de archivo y aceptar el arreglar cualquier problema encontrado durante su despliegue y uso dentro de la organización.



Muchas organizaciones requieren que el código fuente de un sistema de archivo sea puesto en almacenamiento, en caso de que le pase algo al proveedor de el sistema de archivo, éste pueda

seguir siendo soportado. De nuevo, como en la sección anterior, MoReq2010® busca activamente el remover la posibilidad de que los datos se pierdan por causa de un sistema de archivo no soportado al asegurar que cada SDCM incluya una funcionalidad básica de la exportación del sistema completo, de esta manera se habilita una migración sin pérdidas de documentos y entidades a otro SDCM.

12.2.15 ConformidadEl aspecto no funcional final de un sistema de archivo es el de conformidad. Esto ha sido mencionado previamente en otros criterios. Los sistemas de archivo pueden necesitar estar en conformidad con los estándares de la industria y con las regulaciones locales de la siguiente manera:

• Deben estar en conformidad con la especificación MoReq2010®;• Deben estar en conformidad con todos los estándares legislativos y regulatorios que

se apliquen en la organización, en la industria y bajo la jurisdicción en donde están siendo desplegados, como las regulaciones de salud y seguridad o de libertad de información;

• Deben estar en conformidad con estándares Industriales generalmente aceptados en tecnología, y en las plataformas en donde son desplegados, como es HTML y HTML5 para las aplicaciones basadas en los buscadores de red;

• Cómo es requerido por la organización, ellos deben buscar estar en conformidad con los formatos de documentos populares, como es el PDF, habilitando los sistemas de archivo para examinar la estructura de estos documentos, extraer sus metadatos, e indexar su contenido para fines de búsqueda; especialmente con organizaciones en las que el propósito del sistema de archivo sea el de administrar y mantener los documentos en estos formatos.

Como en los sistemas de documentos los requerimientos de conformidad pueden ser tan amplios y pueden depender de las condiciones locales, muchos proveedores incluyen un nivel de nueva configuración en sus soluciones. Aunque la posibilidad de hacer una nueva configuración puede ser un aspecto muy positivo en una aplicación, también puede ser una amenaza para su conformidad cuando es aplicada a un sistema de archivo. Esto es especialmente cierto si las opciones de configuración e instalación permiten la manipulación o apagado de funcionalidades esenciales del sistema de archivo.

Los requerimientos no funcionales de MoReq2010® requieren que el proveedor indique si sus sistemas permiten la personalización de opciones que pueden invalidar los requerimientos

funcionales de MoReq2010®. Cuando esto ocurre, es esencial que la organización compruebe

que el sistema de archivo siga en conformidad con MoReq2010® después de haber sido instalado y estar operacional. Esto se puede llevar a cabo usando las características de

MoReq2010® que reportan sobre conformidad, ver requerimientos funcionales R2.4.5

12.3 Requerimientos no funcionales para el funcionamiento.



N12.3.1

Al evaluar el funcionamiento de un sistema de archivo, es importante el entender el propósito de éste y la naturaleza de los documentos que pueden ser creados y guardados.

¿Para qué es diseñado un sistema de archivo? y ¿Qué tipos de archivo puede administrar?

N.12.3.2

También es necesario entender el tamaño y la complejidad del despliegue. Usualmente esto es descrito en los siguientes términos:

• Número de usuarios que estén trabajando simultáneamente; • El porcentaje de uso del sistema por usuario;• Número de documentos que estén siendo administrados;• El espacio usado por el archivo promedio;• Cantidad y tipo de espacio de almacenamiento requerido, incluyendo los índices de búsqueda y

otros requerimientos del sistema; y• Numeró de servidores y tipos de servidores requeridos.

¿Cómo es un despliegue típicamente pequeño, mediano y grande de un sistema de archivo?

(De ejemplos dónde sea posible)

N12.3.3

Los sistemas de archivo tienen diferentes ciclos de uso. Es importante entender si un sistema de documentos específico se podrá ajustar al nivel de trabajo de la organización. Para cada despliegue típico descrito en N12.3.2, describa su uso típico del sistema de archivo durante una operación normal e indique cuales pueden ser considerados los períodos donde hay picos de trabajo.

(De ejemplos dónde sea posible)

N12.3.4

El rendimiento puede ser medido por el número de documentos que pueden ser capturados por un sistema de archivo.

Por cada despliegue típico descrito en N12.3.2, ¿Cuántos documentos pueden ser capturados y simultáneamente obtenidos por hora en promedio durante una operación normal y en picos de trabajo como esta descrito en N12.3.3?

N12.3.5



Una medida importante del funcionamiento de un sistema es saber el tiempo promedio de búsqueda de los usuarios.

Por cada despliegue típico descrito en N12.3.2, ¿Cuánto dura una búsqueda a través de tres elementos de metadatos como Título, Clase, y, Fecha y Hora de creación, que recupera 100 documentos, en promedio, durante periodos normales y picos de operación, como esta descrito en N12.3.3?

N12.3.6

Algunos sistemas de archivo implementan periódicamente un periodo de espera si la búsqueda toma mucho tiempo.

En una búsqueda ¿Cuál es el tiempo más largo de espera para que cualquier búsqueda, y puede esto ser configurado?

N12.3.7

Otra medida del funcionamiento del sistema es que tan regularmente es evaluado cada archivo para ser desechado. Algunos sistemas de archivo pueden hacer esto en tiempo real o periódicamente en intervalos programados.

MoReq2010® permite que el proceso de deshecho descrito en R8.4.14 se ejecute periódicamente, y debe ser ejecutado por lo menos diariamente, ¿Qué tan regularmente deben los sistemas de archivo ejecutar este proceso para cada uno de los despliegues descritos en N12.3.2?

(En los casos en los que un sistema de archivo adopte un acercamiento alternativo al diseño, dé una explicación de sus efectos, tanto beneficiosos como perjudiciales, en funcionalidad, escalabilidad y otros factores.)

12.4 Requerimientos no funcionales para la escalabilidad.

N12.4.1

Algunos sistemas están restringidos por limitaciones técnicas o de otra índole como el tamaño de la base de datos, sistema de segmentación de documentos, utilización de un solo servidor, etc. Estas limitaciones pueden aplicarse a:

• El número máximo de usuarios simultáneos;• El número máximo de usuarios concurrentes;• El número máximo de entidades, incluyendo documentos;• El espacio de almacenamiento usado por el sistema de archivo; y• El hardware que puede ser desplegado para soportar el sistema de archivo.



En particular, las organizaciones quieren lograr escalabilidad mientras que al mismo tiempo protegen su inversión en hardware y otros recursos. Los sistemas de archivo deberían, en consecuencia, proveer los medios por los que se pueda adicionar capacidad a un sistema ya existente sin tener que migrar a un nuevo ambiente.

¿Cuáles son los limites máximos de escalabilidad para los despliegues típicos descritos en N12.3.2, sin tener que reemplazar el hardware existente?

N.12.4.2

La especificación MoReq2010® no impone un límite máximo en la cantidad de entidades, cuantos metadatos, cuantos usuarios y cuanto contenido puede soportar un SDCM. Sin embargo, puede haber consideraciones prácticas con cualquier sistema de archivo.

Para cada respuesta de N12.4.1, ¿Qué estrategias debe poner en pie una organización para expandir el despliegue de un sistema de archivo más allá de los límites técnicos, asumiendo que el número de usuarios se duplica, y el número de documentos se quintuplica en un período de tres años?

N12.4.3

Al escalar un sistema de archivo arriba y afuera, el rendimiento de cada una de sus funciones se puede ver afectado.

Para cada respuesta del N12.4.2, cuál será el impacto en:

• El rendimiento del sistema descrito en N12.3.3?• ¿Cuál es el tiempo promedio de búsqueda en N12.3.4?• ¿El tiempo fuera de búsqueda descrito en N12.3.5?• ¿ La regularidad de los procesos de deshecho descritos en N12.3.6?

N12.4.4

Los sistemas de archivo pueden imponer también limitaciones internas en los números, tipos y relaciones entre entidades. Por ejemplo, la clasificación del servicio puede tener un límite máximo en el número de clases que puede contener.

Cuáles son los límites técnicos de un sistema de archivo en cada uno de los siguientes ejemplos

• El número de entidades que pueden ser administradas por cualquier servicio, o un grupo de servicios bajo R2.4.1?

• El número de agrupacioneses raíz que pueden ser adicionados a un sistema de archivo?

• El número de entidades, ya sean agrupaciones hijo o documentos, que pueden ser adicionados a una agrupacion?



• La profundidad o número de niveles de una agrupacion bajo una agrupacion raíz?• El número de componentes de un archivo?

N12.4.6

Al crecer el número de entidades en sistema de archivo, no solo los tiempos de búsqueda sino también el número de resultados recuperados por una búsqueda también crecerán. Algunos motores de búsqueda aproximan el número total de entidades en vez de calcularlo para las búsquedas que recuperan un gran número de entidades. Los motores de búsqueda también tienen diferentes formas de determinar la relevancia de las búsquedas.

¿Cuál es el máximo número de resultados de búsquedas que un sistema de archivo va a encontrar y recuperar?, y , ¿Qué estrategias de mitigación usan los motores de búsqueda para hacer los primeros resultados de búsqueda más relevantes?

N12.4.7

El requerimiento R10.4.16 requiere que un SDCM permita a los usuarios encadenar o unir varias consultas de búsqueda para poder responder consultas de búsqueda complejas.

Qué limita el número de cadenas o uniones que un sistemas de archivo puede incluir en una búsqueda bajo R10.4.16, y cuál es el impacto de encadenar o unir búsquedas en:

• El tiempo de respuesta?• La relevancia de los resultados de la búsqueda?

12.5 Requerimientos no funcionales para la capacidad de gestión. N12.5.1

Es importante entender como una organización puede instalar y configurar un sistema de archivo. Usualmente esto se hace como parte de un proyecto más amplio.

¿Cómo es instalada y configurada una nueva instancia de un sistema de archivo, y quién debería realizar este trabajo?

N.12.5.2

Mientras que los sistemas de archivo están operando, su uso de recursos debe ser monitoreado para asegurar que el sistema tenga reservas adecuadas. Medir el uso de recursos puede extenderse hasta:

• Número de usuarios con acceso al sistema, a que horas y en que días;• La cantidad de almacenamiento que esta siendo usada y el ritmo de aumento;• Promedio de tiempo de búsqueda y ritmo en incremento o disminución;• Tiempo de respuesta promedio a todas las funciones; y• Utilización de CPU y memoria.

¿Qué medios son utilizados por un sistema de archivo para medir el uso de recursos?



N12.5.3

El uso de recursos puede llegar aun punto crítico cuando más recursos son dados al sistema. Es importante que el personal técnico administrativo anticipe esto y añada más recursos cuando sean necesarios, por ejemplo, aumentando el espacio de almacenamiento disponible antes de que el espacio de almacenamiento existente se acabe. ¿Cómo pueden los sistemas de archivo, mientras monitorean el uso de recursos bajo N12.5.2, prevenir a los administradores técnicos sobre recortes en los recursos previstos, y pueden preestablecerse límites de los recursos?

N12.5.4

Los recursos que están a disposición del sistema de archivo pueden ser disminuidos, pero esto puede afectar una tarea difícil, y para algunos sistemas de archivo significará requerir una ventana de mantenimiento en el que el sistema este fuera de uso.

¿Qué capacidad existe para aumentar los recursos disponible para un sistema de archivo? ¿Cómo se hace esto?

N12.5.5

Adicionalmente a monitorear y advertir acerca del uso de recursos, es útil cotejar reportes y estadísticas en el tiempo, de esta manera aparecen las tendencias.

¿Qué facilidades de reporte estadístico a largo plazo existe para los sistemas de archivo para el análisis de la utilización de los recursos bajo N12.5.2?

N12.5.6

El requerimiento R2.4.7 estipula el uso de un registro de errores externos. Diferentes tipos de sistemas de archivo usan diferentes registros de errores.

Describa el registro de error usado por el sistema de archivo bajo R2.4.15. ¿Cómo es acezado y usado? Y ¿Qué mecanismo existe para advertir los administradores técnicos cuando un sistema de archivo falla al realizar una función?

N12.5.7

El requerimiento R8.4.15 requiere que los usuarios autorizados para recibir alertas para un agregado o un archivo cuando un acción de deshecho no se ha llevado a cabo y confirmado para una fecha límite. Diferentes tipos de sistemas de archivo usan diferentes mecanismos de alerta.

Describa el mecanismo de alerta usado por los sistemas de archivo bajo R8.4.15 ¿Cómo pueden usuarios autorizados recibir la alerta, y que mecanismo existe para consolidar las alertas como esta descrito en la lógica R8.4.15?



N12.5.8

De tiempo en tiempo los sistemas de archivo deben ser auditados. Los auditores pueden desear revisar (esta lista no es exhaustiva):

• Que solo los usuarios y grupos apropiados tengan acceso al sistema de archivo;• Que todos los usuarios y grupos apropiados tengan acceso al sistema de archivo;• Que los controles de seguridad y acceso apropiados estén funcionando;• Que los usuarios no estén accediendo a documentos y otras entidades a las que no tengan

permitido el acceso;• Que la clasificación del servicio de configuración sea apropiado para la empresa;• Que los horarios de configuración de servicio de deshecho es apropiado para la empresa;• Que todos los documentos relevantes sean capturados por el sistema de archivo;• Que los documentos estén siendo puestos en las agrupacioneses apropiadas;• Que los documentos estén siendo clasificados correctamente;• Que los usuarios no estén invalidando inapropiadamente los horarios de servicio de deshecho

por defecto;• Que ningún archivo u otra entidad estén siendo eliminados del sistema de archivo, fuera del

proceso de desecho;• Que los períodos de desecho estén siendo monitoreados y las fechas límites estén siendo

cumplidas;• Que las confirmaciones ocurran dentro de las fechas límite de desecho y que no haya atraso en

los documentos que deben eliminarse;• Que el contenido de los documentos está siendo eliminado correctamente; y• Que las copias de los contenidos de los documentos estén siendo eliminadas de fuentes

secundarias dentro de la organización inmediatamente después o al tiempo con la eliminación formal del archivo.

¿Qué facilidades existen para auditar los sistemas de archivo y cómo debe esto llevarse a cabo?

12.6 Requerimientos no funcionales para portabilidad.

N12.6.1

Los sistemas de archivo pueden operar en una o varias plataformas. Puede tener un número limitado de configuraciones de servidor pero soportar diferentes clientes.

¿Qué sistemas operativos y plataformas usan los sistemas de archivo?, y, ¿En qué partes del sistema de archivo, incluyendo módulos de sistemas basados en servidores y clientes?, ¿En qué tecnologías son desplegados?

N12.6.2

Cómo fue descrito en 3. Usuario y grupos de servicio, una SDCM puede utilizar un sistema de directorio popular, como un directorio LDAP, y proveer una forma de envolver para capturar datos históricos acerca de usuarios y grupos, o puede proveer su propio servicio de administración de usuarios y grupos.



¿A qué servicios de directorio hace interface el sistema de archivo?, si lo hace, y ¿Cómo esta preservada la información histórica acerca de usuarios y grupos como entidades dentro del servicio de usuario y grupo?

N12.6.3

Muchos sistemas de archivo utilizan componentes de software de terceros como tecnologías de bases de datos y motores de búsqueda. Dónde estos están integrados al producto, tienen la ventaja de poder ser rehusados, pero también los problemas asociados con administrar ciclos de desarrollo independiente.

¿Qué OEM, terceros o sistema de código abierto son incorporados a los sistemas?

N12.6.4

Muchos sistemas de archivo proveen interfaces y conjuntos IAP para otras aplicaciones. ¿A qué otros sistemas de empresa pueden integrarse los sistemas de archivo, si los hay, qué grupos de IAP están disponibles y que tecnologías soportan?

N12.6.5

El soporte de plataforma puede crear limitaciones en los metadatos y las plantillas. Por ejemplo,

MoReq2010® no restringe la máxima longitud del campo de texto, sin embargo, esto puede estar restringido por el tamaño de las bases de datos.

Los sistemas de archivo pueden adoptar el modelo del servicio de metadatos (ver 7. Modelo del servicio de Metadatos) o puede implementar su propio acercamiento a la metadatos.

¿Qué acercamiento es usado por los sistemas de archivo para administrar los metadatos? y ¿Cuál es el impacto de este acercamiento sobre:

• ¿Cuál es el número de elementos de metadatos de contexto que pueden ser aplicados a una entidad de cualquier tipo de entidad?

• ¿Cuál es el número de elementos de metadatos de contexto que pueden ser incluidos en una plantilla?

• ¿Cuál es el uso de las plantillas?• ¿Cuál es la longitud máxima de un campo de metadatos?• ¿Cuáles son los tipos de datos soportados por el sistema de archivo?

12.7 Requerimientos no funcionales de seguridad.

N12.7.1

R3.4.1 especifica que el SDCM solo debe acezado por un usuario autenticado. El SDCM puede soportar uno o un número de servicios de autenticación comercial o de propiedad, o el de servicio de autenticación puede estar ya construido en él.



En cada una de las plataformas listadas en N12.6.1 y por cada uno de los directorios de implementaciones listados en N12.6.2 ¿Qué tecnologías de autenticación son soportadas por el sistema de archivo?

N12.7.2

Dependiendo de la implementación de los sistemas de archivo del modelo de servicio de rol, puede haber restricciones particulares que apliquen a roles y controles de acceso.

Los sistemas de archivo pueden adoptar un modelo de servicio de rol (ver 4. Modelo de Servicio de Rol) o puede implementar su propia aproximación al control de acceso. Si los sistemas de archivo requieren su propio acercamiento para el control de acceso, entonces puede no tener el mismo nivel de

granularidad que el modelo de servicio de MoReq2010®.

¿Cómo implementa un sistema de archivo control de acceso interno y que limitaciones impone en:

• Los roles que están predefinidos y fijados por el sistema de archivo?• El número de roles adicionales que pueden ser definidos?• Las definiciones de las funciones que pueden ser incluidas en los roles?• Las entidades que tienen acceso a las listas de control?• La herencia y otras características de acceso del control de entrada?

N12.7.3

La autenticación y control de acceso tienen muy poco valor si la información guardada en el sistema de archivo puede ser acezada directamente.

¿En qué mecanismos puede confiar un sistema de archivo para restringir el acceso a sus datos almacenados?

N12.7.4

Similarmente, cuando componentes diferentes del sistema de archivo se comunican el uno con el otro ya sea internamente, por ejemplo entre cliente y servidor, o externamente, por ejemplo con los sistemas de otras empresas, sus comunicaciones deben estar aseguradas para evitar ataques como el de un registro furtivo o un “man in the middle”.

¿Qué tecnologías son usadas para asegurar que la comunicación entre los componentes listados en N12.6.1, N12.6.2, N12.6.3 y los sistemas externos listados en N12.6.4 sean seguros?

N12.7.5

Los controles adecuados deben ser integrados al sistema de archivo, y/o su ambiente operativo para prevenir que sea explotado por virus, caballos troyanos, y otro tipo de código malicioso. Por ejemplo, un sistema de archivo puede ser vulnerable a un ataque al SQL por medio de los elementos de metadatos de las entidades.



¿Qué antivirus y otras estrategias de seguridad están integradas a los sistemas de archivo o son recomendados como parte normal del ambiente operacional del sistema de archivo?

N12.7.6

El sistema de archivo puede estar diseñado e implementado para satisfacer varios estándares de seguridad bien conocidos así como pruebas de penetración. Estándares como ISO 27000 no evalúan productos individuales solamente, sino que están hechos en relación a una sola estrategia y práctica de seguridad para una organización.

¿Para qué tipos de ambientes seguros esta diseñado el sistema de archivo, que regulaciones nacionales o internacionales y bajo que jurisdicciones?

(El producto o una instalación in situ pueden haber recibido una evaluación o clasificación de seguridad independiente)

12.8 Requerimientos no funcionales para privacidad.

N12.8.1

Los sistemas de archivo pueden haber sido evaluados por su relevancia, en particular leyes de privacidad, como la Directiva Europea de privacidad de datos (European data privacy directive) (95/46/EC). Donde esto ha ocurrido el sistema de archivo puede haber incorporado diferentes características, como restricciones sobre los datos que son movidos entre diferentes almacenamientos de datos internos. Esto es particularmente relevante si el despliegue de un sistema de archivo cruzó límites internacionales.

¿Ha sido un sistema de archivo diseñado específicamente en conformidad con alguna guía o regulación nacional, internacional o de buenas prácticas?

(El producto, o una instalación de sitio ya existente puede haber recibido una evaluación o clasificación independiente sobre una regulación específica en una jurisdicción en particular.)

12.9 Requerimientos no funcionales para uso.

N12.9.1

Los sistemas de archivo deben estar acompañados por un usuario y la documentación técnica para

facilitar su evaluación por un centro acreditado de MoReq2010®. ¿Qué usuario y documentación técnica esta disponible a los usuarios y administradores técnicos de un sistema de archivo?N12.9.2

Los usuarios generalmente necesitan entrenamiento y educación para utilizar eficientemente un sistema de archivo. Esto es especialmente verdadero en usuarios especializados como los administradores técnicos, administradores de seguridad, auditores y, sobretodo, los administradores de archivo.



¿Qué tipo de entrenamiento necesitan los usuarios con diferentes niveles de especialización para usar el sistema de archivo eficientemente, y qué cursos de entrenamiento, tutoriales y otros recursos de educación y aprendizaje están disponibles para los usuarios generales y especializados?

Otros requerimientos no funcionales para uso están dirigidos para los requerimientos no

funcionales para módulos de conexión en la serie de Interface de MoReq2010®.

12.10 Requerimientos no funcionales para Accesibilidad.

N12.10.1

El sistema de archivo puede haber sido evaluado por W3C, WAI Guías para la accesibilidad del contenido de la red (WCAG por sus siglas en Inglés Web Content Accessibility Guidelines). Éstas guías proveen una clasificación de A (la más baja) o AAA (la más alta).

¿Ha sido evaluado el sistema de archivo de manera independiente y clasificado en conformidad con las WCAG?

(¿Incluye detalles de la evaluación, quien la hizo, y la clasificación obtenida?)

Otros requerimientos no funcionales de accesibilidad están dirigidos por requerimientos no

funcionales para módulos de conexión en la serie de Interface de MoReq2010®.

12.11 Requerimientos no funcionales para disponibilidad.

N12.11.1

La disponibilidad de los sistemas de archivo depende de si los sistemas de archivo y otros sistemas de soporte necesarios están funcionando. Algunas veces estos sistemas deben estar fuera de línea para realizar mantenimientos planeados o para realizar actualizaciones. En algunas otras ocasiones éstos fallan. Para cada uno de los despliegues típicos descritos en N12.3.2, ¿Cuál es la disponibilidad anticipada de los sistemas de archivo en porcentaje o radio al comparar el tiempo de actividad y el de inactividad durante el curso de un año calendario?

N12.11.2

Cuando existe un acuerdo del nivel de servicio que cubra la disponibilidad del sistema de archivo, debe proporcionarse o sugerirse algún mecanismo que permita que esto sea medido.



Al recomendarse incluir esto en un acuerdo de nivel de servicio, ¿Cómo deben medirse y los porcentajes o radios bajo N12.11.1 para un sistema de archivo? ¿Qué herramientas deberían ser usadas, y ¿Están estas disponibles en el sistema de archivo o por medio de un tercero?

(De una descripción dónde una forma distinta del acuerdo del nivel de servicio sea recomendada para asegurar una disponibilidad mínima del sistema de archivo.)

N12.11.3

Algunas operaciones administrativas, como hacer una copia de seguridad requieren que el sistema de archivo este fuera de línea.

¿Qué operaciones administrativas requieren que el sistema de archivo sea puesto fuera de línea?

N12.11.4

Al crecer los sistemas, estos toman más tiempo para ejecutar sus funciones, como por ejemplo la copia de seguridad.

¿Cuánto tiempo tomaría hacer una copia de seguridad típica para cada una de las tecnologías disponibles (ver N12.13.1) dados los típicos despliegues descritos en N12.3.2, y cómo esta variará dado los escenarios de crecimiento en N12.4.2?

(Tenga en cuenta copias de seguridad completas y copias de seguridad incremental)

N12.11.5

Las organizaciones deben trabajar con un horario cuando estén administrando sus sistemas de archivo. Vea también N12.14.4

Para cada una de las respuestas a N12.11.1 ¿Cuáles son las ventanas de tiempo para hacer copias de seguridad, mantenimiento o actualizaciones que deben ser reservadas cada día, semana y mes durante el año?

N12.11.6

Sistemas de archivo hospedados requieren consideración adicional al estar limitados por la disponibilidad de su anfitrión.

Si el sistema de archivo es un sistema hospedado, ¿Qué limitaciones adicionales de disponibilidad y garantías deben ser proporcionadas por el sistema anfitrión?

12.12 Requerimientos no funcionales para la Confiabilidad.



N12.12.1

R2.4.7 Requiere que las funciones que son realizadas atómicamente y que no funcionan deberían ser exitosas solo parcialmente. Funciones atómicas son requeridas para asegurar la integridad de los datos si el SDCM falla durante la operación. Si la función no es exitosa entonces debería ser deshecha.

¿Cómo puede un sistema de archivo soportar operaciones atómicas? Y ¿Cómo se puede asegurar la integridad del sistema de archivo si una transacción falla o el sistema de archivo falla antes de su terminación?

N12.12.2

El diseño de los sistemas de archivo juega un rol significativo en su confiabilidad y su habilidad para soportar condiciones de error.

¿Cómo afecta la arquitectura de un sistema de archivo su confiabilidad?

N12.12.3

Adicionalmente a su arquitectura bajo N12.12.2, la metodología usada para desarrollar un sistema de archivo, incluyendo diseño, comprobación y evaluación de las unidades, juegan un papel en la calidad consecuente del producto final.

¿Qué controles de calidad son usados en la manufactura de un sistema de archivo para asegurar su exactitud?

N12.12.4

El sistema de archivo puede haber sido evaluado anteriormente y obtenido una calificación mientras tanto entre fracasos o pudo haber sido evaluado sobre otro instrumento de confiabilidad o disponibilidad.

¿Ha sido evaluado, puesto como punto de referencia o calificado, el sistema de archivo de manera independiente en una instalación previa para su ver su confiabilidad o disponibilidad?

(Incluya detalles de la evaluación, quién la hizo y las calificaciones obtenidas.)

N12.12.5

Muchos sistemas de archivo son construidos usando una arquitectura orientada al servicio (u otro tipo de arquitectura resistente) y otras partes del sistema de archivo pueden ser redundantes, permitiendo que servicios individuales fallen y sean reiniciados mientras el sistema de archivo se mantenga operacional.

¿Qué partes del sistema, listadas en las respuestas a N12.6.1 y N12.6.3 pueden fallar o parar y ser reiniciadas mientras que el resto del sistema operativo se mantiene operacional?



N12.12.6

Manejar una falla del sistema graciosamente quiere decir que todos los procesos son apagados en el orden correcto para preservar la integridad del sistema y permitirle ser reiniciado y continuar operando una vez las condiciones de operación normal sean logradas.

¿Qué hardware, software y otros sistemas de soporte son requeridos dentro de un sistema de ambiente operativo de un sistema de archivo para permitirle apagarse por si solo con gracia en el evento de una falla de electricidad o en respuesta a otra amenaza externa?

12.13 Requerimientos no funcionales para la capacidad de recuperación.

N12.13.1

Diferentes sistemas de archivo puede adoptar diferentes estrategias para hacer copias de seguridad para la redundancia de datos y asegurar la continuidad de la empresa en el evento en el que se pierdan datos, hardware, software o falla del sistema. Diferentes estrategias tienen diferentes ventajas, como la velocidad, o desventajas como el costo. Estrategias para hacer copias de seguridad pueden también ser dependientes de los medios usados para hacer la copia. Hay muchos medios para crear copias de seguridad disponibles, por ejemplo, discos y cintas magnéticas, medios ópticos, almacenamiento en la nube, etc.

¿Qué estrategias para desarrollar copias de seguridad son soportadas por el sistema de archivo? ¿Cuáles son sus ventajas y desventajas relativas, y cuales son recomendadas para ser usadas bajo el escenario planteado en N12.11.4?

N12.13.2

Todas las organizaciones deberían desarrollar un plan de continuidad. Esto debería incluir el tiempo que se necesita para restaurar el sistema, incluyendo los sistemas de archivo, en el evento de una falla del sistema.

Para cada una de las estrategias listadas en N12.13.1 y para cada uno de los escenarios de uso en N12.11.4 ¿Cuánto tiempo se recomienda para restaurar los sistemas de archivo si:

• Solo se necesita recuperar los datos?• El sistema de archivo necesita ser reconstruido y los datos recuperados?

N12.13.3

El plan de continuidad de la empresa debería contener instrucciones paso a paso sobre como recuperar los sistemas de archivo, y por lo menos una copia debería estar guardada fuera del sistema de archivo.

Para recuperar los datos del sistema de archivo bajo N12.13.2 ¿Qué aproximaciones son requeridas para cada una de las estrategias para crear una copia de seguridad bajo N.12.13.1? y ¿Qué consideraciones importantes deben generar o a cuales deben dirigirse?



N12.13.4

N12.12.1 Indica que un sistema de archivo debería soportar transacciones atómicas. Si estos son soportados y guardados en un diario de transacciones, puede ser posible que se restaure el sistema hasta llegar al punto donde falló.

Al restaurar desde la copia de seguridad bajo N12.13.2 ¿Puede el sistema de archivo soportar un aumento en la creación de copias de seguridad y durante la recuperación de datos, puede adelantarse hasta la transacción que sucedió justo antes de la falla?

(Describa cualquier diseño alternativo adoptado.)

N12.13.5

No todos los sistemas de archivo confían en copias de seguridad y la recuperación que se logra a partir de la redundancia. Algunos pueden ser configurados para reflejar datos y para fallar sobre un sistema en espera o sitio. Otros confían en la redundancia hasta llegar al punto de crear unidades individuales que pueden ser cambiadas rápidamente mientras que el sistema de archivo permanece en línea.

Fuera de hacer copias de seguridad y recuperación, ¿ Qué otros mecanismos puede usar un sistema de archivo para asegurar la continuidad de la empresa?

N12.13.6

Al construir sistemas de archivo usando diferentes componentes de un sistema integrado, algunos proporcionados por diferentes proveedores, se puede afectar la forma en la que el sistema de archivo es administrado, como se crean las copias de seguridad y de recuperación. Por ejemplo, la base de datos puede estar en una copia de seguridad a través de una tecnología mientras que el contenido puede estar almacenado usando una tecnología distinta. Pueden haber sido guardadas en diferentes momentos, lo cual puede crear problemas de sincronización al unirlas si ambas deben ser restauradas por una falla del sistema.

¿Cuál es el impacto del OEM, terceros y servicios de sistemas con códigos abiertos listados bajo N12.6.3 sobre hacer copias de seguridad y restaurando un sistema de archivo o, proporcionando de otra manera para los datos, redundancia del sistema y conmutación por error?

(Explique, particularmente como problemas de sincronización son administrados si las copias de seguridad de las diferentes partes del sistema de archivo así como las restauraciones se llevan a cabo separadamente)

12.14 Requerimientos no funcionales para mantenimiento.

N12.14.1

La mayoría de sistemas de archivo soportan versiones mayores, menores y de mantenimiento (también llamadas nuevas versiones, paquetes de servicios, parches o construcciones). Nuevas funciones son



usualmente introducidas al tiempo con lanzamientos grandes, mejoras con lanzamientos menores y arreglos a errores con los lanzamientos de mantenimiento.

¿Cómo se denotan las diferentes versiones del sistema de archivo? ¿Qué tipo de actualizaciones son cubiertas por las diferentes versiones? Y ¿Cuales son los ciclos de lanzamientos del proveedor para cada tipo de versión?

N12.14.2

Aún cuando una actualización es gratis, habrá costos asociados al moverse de una versión del producto a la siguiente. Usando la información de N12.14.1 y N12.11.5 debería ser posible para una organización programar actualizaciones para su sistema de archivo.

Para cada uno de los lanzamientos listados en N12.14.1, ¿Qué planeación de actualizaciones debería ser puesta en práctica por la organización usando el sistema de archivo?

N12.14.3

De vez en cuando es necesario arreglar algunos errores y otros problemas fuera de los mantenimientos planeados y actualizar ventanas, por ejemplo, si un problema de seguridad inmediato es descubierto y publicitado, lo cual causa una seria amenaza para el sistema de archivo de la organización, o si el sistema se vuelve inestable durante la operación por cualquier razón.

¿Cuál es la política del proveedor con respecto al soporte de un producto en caso de emergencia para generar arreglos rápidos o parches para errores críticos?

N12.14.4

Cuando los sistemas de archivo incorporan diferentes partes con origen diferentes proveedores, esto puede tener un impacto sobre como los lanzamientos de los productos son hechos. Esto es especialmente cierto si un tercero de componentes de sistema están originados independientemente por la organización y no vienen directamente del proveedor del sistema de archivo. Aún los sistemas de archivo que están construidos substancialmente por un mismo proveedor, pueden ser dependientes de diferentes ambientes de operación de diferentes fuentes.

¿Cómo están las diferentes OEM, terceros y servicios de código abierto, listados bajo N12.6.3 administrados con relación a los diferentes lanzamientos del sistema de archivo listado bajo N12.14.1, sus propios y separados desarrollos de producto así como sus lanzamientos de ciclo?

N12.14.5

No todos los sistemas de archivo están mantenidos por la organización, algunos están hospedados por el proveedor o un tercero. Cuando esto ocurre, actualizaciones regulares puede ser hechas al sistema de archivo en horarios programados sobre los que la organización tiene poco control, especialmente cuando la organización comparte un sistema anfitrión.



Si el sistema de archivo es hospedado, ¿Cuáles son los acuerdos típicos hechos con el fin de actualizar el sistema de archivo, cómo y cuando son notificados, y cual es el impacto potencial en las organizaciones con clientes, para cada uno de los diferentes tipos de actualizaciones listadas bajo N12.14.1?

N12.14.6

Actualizar los sistemas de archivo y adicionar características también requiere educación adicional al usuario, para aprender acerca de las nuevas características incluidas en el lanzamiento y cambiar viejos hábitos.

¿Qué notas son creadas con cada lanzamiento? Y ¿Cuáles son los requerimientos de educación y re entrenamiento usualmente asociados con los diferentes lanzamientos de los sistemas de archivo listados en N12.14.1?

12.15 Requerimientos no funcionales para el soporte.

N12.15.1

Un sistema de archivo debe ser mantenible actualmente por el proveedor.

¿Cuándo fueron anotados los últimos lanzamientos de cada uno de las versiones de los sistemas de archivo bajo N12.14.1? y ¿Cuáles fueron las fechas de las versiones y los lanzamientos?

N12.15.2

También es importante saber lo más que se pueda acerca de los planes del proveedor para el futuro del sistema de archivo, aunque algunos de éstos pueden ser secretos del oficio y puede que cambien como respuesta a nuevas tecnologías y prioridades.

¿Hay algún mapa de ruta de productos para el sistema de archivo? ¿Qué períodos cubre (por ejemplo, los próximos 18 meses, 3 y 5 años)?¿ Qué tan seguido son actualizados? y ¿Cómo es el mapa de ruta de producto compartido con los clientes y clientes probables?

N12.15.3

La organización puede también desear saber cómo se puede solicitar nuevas características para un producto e influenciar su prioridad y desarrollo en el sistema de archivo.

¿Cómo están involucrados los clientes al solicitar y priorizar nuevas características?

(Proporcione un ejemplo de una característica desarrollada como resultado de la solicitud de un cliente.)



N12.15.4

Problemas de cualquier tipo deben poder ser reportados al proveedor y arreglados dentro de una cantidad de tiempo previamente acordada. La política del proveedor en relación con la creación de parches para soporte de emergencia ya ha sido listada en N12.14.3

¿Qué niveles de soporte están disponibles para el sistema de archivo? ¿Pueden incluir una línea de soporte 24X7 (24 horas al día 7 días a la semana) para reportar problemas críticos? Y ¿Cómo pueden clientes y posibles clientes aprender acerca del proceso de soporte disponible y como usarlo?

N12.15.5

El proveedor debe tener suministros para etiquetar y seguir, especialmente cuando los problemas que se están presentando por las organizaciones a través del proceso de soporte.

¿Tienen las organizaciones una visión de los problemas que se pueden presentar a través del servicio de recepción del proveedor para poder monitorear el progreso de sus problemas?

N12.15.6

Las organizaciones deberán tratar de entender que tan rápido pueden esperar un para que un problema sea resuelto.

¿Son usadas las categorías para los problemas, bajo N12.15.5? y ¿Está disponible el promedio de tiempo de respuesta para cada categoría en el último año para los clientes y posibles clientes?

N12.15.7

Muchos proveedores ahora suportan grupos de usuarios activos, foros en línea, incluyendo foros de soporte y conferencias.

Aparte de la información y a nombrada en esta sección, ¿Qué otro tipo de oportunidades existen para que las organizaciones participen la una con la otra y con el proveedor del sistema de archivo?

12.16 Requerimientos no funcionales para la garantía.

N12.16.1

Es importante entender el tipo de garantía que da el proveedor en términos de cualidad y funcionamiento en relación con el sistema de archivo.

¿Garantiza el proveedor el sistema de archivo? Y si lo hace, ¿Qué partes del sistema de archivo están cubiertas y que tipo de problemas?



N12.16.2

La organización puede también desear acordar un acuerdo de nivel de servicio que cubra el sistema de archivo y aspectos como funcionalidad, disponibilidad, etc.

¿Entra el proveedor en un acuerdo de nivel de servicio con sus clientes? Y si lo hace ¿ Qué aspectos de los requerimientos no funcionales del sistema de archivo cubre? Y ¿Son los mismos, o son individuales para cada acuerdo?

N12.16.3

El proveedor puede tener términos y condiciones estándar para los clientes del sistema de archivo. Debe notarse que aún el software de código abierto tiene condiciones de licencia asociadas a él.

¿Están los estándares de términos y condiciones disponibles para los usuarios o posibles usuarios?, o ¿Son éstos negociados individualmente con cada contrato?

N12.16.4

Debe ser posible para una organización, el obtener acceso al código fuente para el sistema de archivo, en caso de que el proveedor salga del negocio.

¿Es el sistema de archivo una aplicación de software de código abierto? Y si no, ¿Qué otros medios pueden usarse para proteger el acceso del cliente?, como por ejemplo alojar una copia del código fuente en garantía con un tercero neutral.

N12.16.5

También es posible colocar los datos en garantía, especialmente para servicios hospedados.

¿Soporta el sistema de archivo datos en garantía?

N12.16.6

Cuando un sistema de archivo es hospedado o cuando las diferentes partes del sistema son proporcionadas por diferentes proveedores, puede haber consecuencias inesperadas con relación a los términos y condiciones del proveedor principal, además del acuerdo de licencia, acuerdos de nivel de servicio, etc.

¿Cuál es el impacto de que las diferentes partes del sistemas sean proporcionadas por diferentes proveedores bajo N12.6.3, o hospedados bajo N12.11.6 y N12.14.5, a las respuestas a N12.16.1,N12.16.2, N12.16.3, N12.16.4 y N12.15.5 anteriormente?

12.17 Requerimientos no funcionales para conformidad.

N12.17.1



Los sistemas de archivo pueden estar ya en conformidad con los estándares nacionales o internacionales en cuanto a la administración de documentos, o relacionado con disciplinas como la administración de contenido, de documentos, etc.

Aparte de MoReq2010®, ¿Qué otra administración de archivo, o relacionado, estándares y especificaciones esta en conformidad con el sistema? Y ¿Ha sido esto verificado independientemente?

(Para cada verificación independiente, incluya detalles de la evaluación, quién la realizó, y cual fue la calificación obtenida.)N12.17.2

El sistema de archivo debe estar en conformidad con otros marcos regulatorios, y legislativos fuera del campo inmediato del sistema de archivo, a un nivel nacional o internacional. Por ejemplo, el sistema de archivo puede estar en conformidad con los Mercados Europeos en la Directiva de Instrumentos Financieros. (European Markets in Financial Instruments Directive (2004/39/EC) también conocido como “MiFID”(Por sus siglas en Inglés).

Aparte de los estándares listados en N12.17.1, ¿Con qué otros estándares o regulaciones nacionales o internacionales debe estar en conformidad el sistema de archivo?, y ¿Ha sido esto verificado independientemente?

(Para cada verificación independiente, incluya los detalles de la evaluación, quien la realizó y la calificación obtenida.)

N12.17.4

¿Es útil para un SDCM el proveer un alto nivel de precisión para las marcas de tiempo generadas bajo R2.4.27? Precisión de milisegundo, o mejor, puede ser usada para mantener el orden exacto en el que los eventos ocurren en sistemas de alto rendimiento.

¿Qué precisión necesita un sistema de archivo para las marcas de tiempo?

N12.17.5

Es importante que, bajo R2.4.24, un SDCM no genere los mismos identificadores de sistema para entidades, como otras soluciones SDCM. El algoritmo usado para general identificadores únicos universales debe ser adecuado para crear grandes números de UUIDs sin repetición, patrón o superposición con otros sistemas.

¿Qué algoritmo usan los sistemas de archivo para generar UUIDs?

N12.17.6

Algunos sistemas de archivo tienen opciones de configuración que permiten a algunos o todas sus

funcionalidades compatibles con MoReq2010® el ser apagadas o reemplazadas por funcionalidades no compatibles.



Cuando previsiones con respecto a esto han sido incluidas en las opciones de configuración del sistema

de archivo, especialmente para un producto cerificado por MoReq2010®, es importante que protecciones sean incluidas para asegurar que esto no pase de manera inadvertida. Aunque las consecuencias de unas opciones de instalación particulares pueden ser claramente explicadas en la documentación técnica cuando el sistema de archivo es instalado, un administrador técnico diferente puede, sin darse cuenta, cambiar la configuración del sistema de archivo posteriormente con consecuencias no deseadas.

Por esta razón, MoReq2010® incluye una opción para reportes de conformidad bajo R2.4.5 que

permite a los usuarios revisar el estatus de conformidad en ese momento de MoReq2010® del sistema de archivo en cualquier momento durante una operación de rutina.

¿Cómo soporta un sistema de archivo el reporte de conformidad MoReq2010® bajo R2.4.5? Y ¿Cómo revisa el estatus actual del sistema de archivo cuando hace el reporte, para asegurar que no ha sido reconfigurado de manera no conforme?



13. Glosario de Términos

Término Explicación y relación con los conceptos generales

Acceder (verbo) Interactuar con un sistema de información para desempeñar funciones, visualizar e inspeccionar sus entidades.

(sustantivo) El grado de funcionalidad que se le permite tener al usuario con un sistema de información descrito como “nivel de acceso”.

Control de Acceso (concepto) El concepto de administración de acceso de los usuarios a las entidades y a las funciones en un sistema de información.

Entrada de Control de Acceso

(estructura de datos) Entrada individual dentro de una lista de control de acceso que otorga una o más funciones a un solo usuario o a un grupo de usuarios.

Véase también Lista de Control de Acceso.

Lista de Control de Acceso

(estructura de datos) Una lista de entrada de control de acceso asociada con una entidad que define los usuarios que pueden realizar funciones en la entidad mediante la asignación de roles a los usuarios y grupos de usuarios.

Véase también Entrada de Control de Acceso.

Principio de Accesibilidad

(concepto) Una característica No Funcional de un sistema de información que describe hasta qué punto le brinda soporte a usuarios con capacidades y ritmos de aprendizaje diferentes, incluyendo aquellos con discapacidades específicas.

(ambigüedad) El término “accesibilidad” se deriva del significado más amplio de la palabra “acceso” que es utilizada por MoReq2010®.

ACE (sigla) Una entrada de control de acceso

ACL (sigla) Una Lista de control de acceso.

Entidad activa (sustantivo) Una entidad creada en un SDCM y que nunca ha sido borrada ni destruida.

Véase también entidad residual.



Actividad (sustantivo) Un proceso organizado diseñado con el fin de producir un resultado. Las actividades realizadas por las personas y por las computadoras son comunes dentro de los sistemas de información.

Véase actividad comercial y actividad programada.



TérminoExplicación y relación con los conceptos generales

Adicionar (operación) La función de incluir una entidad dentro de un grupo de entidades, por lo general trasladándola de otra parte. Por ejemplo, agregar un registro a una agrupación.

Véase también transferencia y eliminación.

Rol Administrativo (sustantivo) Un rol que aplica de manera uniforme, a través de la herencia, a todos los descendientes de una entidad, o si se aplica a un servicio entonces a todas las entidades del servicio. Haciendo una comparación, la herencia de los roles no administrativos es selectivo.

Véase también roles no administrativos.

Administrador (sustantivo) Un administrador técnico de un SDCM es la persona encargada de gestionar la infraestructura y el entorno técnico que soporta su funcionamiento. El administrador técnico tendrá acceso e influencia sobre los aspectos externos del SDCM como sus áreas físicas de almacenamiento de datos y el registro de errores, aunque no necesariamente es un usuario del SDCM.

(ambigüedad) El término “administrador” también se puede utilizar de una manera no específica (aunque no en MoReq2010®) para describir un usuario de SDCM con:

• Un alto nivel de acceso en general a las entidades y funciones. •La tarea de configurar entidades como clases, definición de

elementos de metadatos, planillas o roles. • Responsabilidades específicas en la gestión de documentos como transferencia, o destrucción de documentos, o• Uno o más roles administrativos que se le han otorgado al usuario.

Véase Role Administrativo

Agrupar (verbo) La actividad de integrar las entidades que tienen características compartidas, específicamente dentro de MoReq2010® para crear o transferir documentos dentro de una agrupación

Véase también adicionar

Agrupación (entidad) La agrupación de documentos es la acumulación de entidades de documentos relacionados que, cuando se combinan, pueden existir en un nivel superior al de un documento individual.

La agrupación de registros puede reflejar relaciones como características o atributos compartidos, o la existencia de relaciones secuenciales entre documentos relacionados.

(Adaptado de la Norma ISO 16175-3:2010, 2.3.1)




Véase también agrupación hijo, agrupación padre y agrupación raíz.

Alarma (sustantivo) Una alarma de eliminación que activa automáticamente el SDCM y que se envía para que la reciban los usuarios autorizados, cada vez que un documento caduca para su eliminación, y ha superado su periodo de confirmación posterior sin recibir la confirmación de eliminación necesaria. MoReq2010® permite que cada SDCM implemente sus propias soluciones y tecnologías de alarma.

(verbo) La acción de activar una alarma y enviarla a los usuarios autorizados para que la reciban.

Antecesor (sustantivo) En una estructura jerárquica, a partir de una entidad determinada, las demás entidades que se pueden contactar solo mediante el trazado de una ruta unidireccional, desde las entidades hijo a las de sus padres.

Véase también hijo, descendiente y padre.

Anonimato (verbo) Se denomina al proceso de oscurecer u ocultar información sensible de manera que no se pueda identificar la Fuente. Véase también proteger.

Aplicaciones informáticas

(sustantivo) Las aplicaciones informáticas hacen referencia a los programas informáticos que incluyen pero no se limitan a productos o sistemas de información.

Arquitectura (sustantivo) El diseño y la estructura de un sistema de información que destaca especialmente la intención del diseño de cada parte, sus diferentes estructuras y las relaciones entre ellos.

Véase Arquitectura con base en el servicio.

Asignar (funcionamiento) Asignar un valor a un elemento de metadato con el fin de utilizarlo, en particular, para asociar una entidad con otra.

Véase también asociación y modificación.

Asociación (funcionamiento) Establecer una relación entre dos entidades, como por ejemplo, asociar un documento con una agrupación, proceso que se realiza normalmente al modificar el metadato de uno o de ambos, para conservar una referencia a la otra.

Véase también asignar, modificar y eliminar.




Atómico (concepto) El concepto de que una unidad de información en particular se debe manejar de manera integral. Por ejemplo, se considera que un documento es atómico incluso si está compuesto por varias entidades, como componentes. El documento debe estar está completamente activo o destruido en su totalidad, pero no se puede destruir parcialmente.

La atomicidad en el MoReq2010® también aplica a la ejecución de funciones en el SDCM, las cuales se deben realizar completamente, y nunca de manera parcial. Este proceso es importante para mantener la coherencia y la estabilidad interna y cuando se restaura el SDCM luego de hacer una copia de seguridad.

Pista de Auditoría (sustantivo) En el marco de un sistema comercial de tradición, se refiere al registro centralizado de todas las actividades o de una actividad importante del sistema. Un SDCM conserva la pista de sus actividades como una secuencia de eventos, que se pueden ver a través del sistema como un conjunto, pero a las que se tiene acceso más comúnmente como un historial de eventos en una entidad individual.

Véase historial de eventos.

Autenticación (funcionamiento) Proceso para verificar la identidad de un usuario, que se lleva a cabo normalmente preguntando al usuario una contraseña concertada previamente.

Principio de autenticidad

(concepto) Junto con integridad, confiabilidad y funcionalidad, es una de las características fundamentales de un documento, según la Norma ISO 15489.

Un documento auténtico es aquel que puede probar que cumple con la funcionalidad para la que fue creado.

(Adaptado de la Norma ISO 15489-1:2001, 7.2.2)

Véase también integridad, confiabilidad y funcionalidad.

Usuario autorizado (sustantivo) Se refiere a un usuario autenticado que tiene la autoridad para ejecutar una función.

Autoridad (concepto) Tener la capacidad para desempeñar una función en particular, en especial con relación a una entidad en particular. La autoridad se otorga a los usuarios mediante la asignación de roles en diferentes partes del sistema o en relación con las diferentes entidades utilizando una lista de control de acceso.



Automático (adjetivo) Es una operación o función que realiza el sistema de acuerdo con sus propias normas internas de procedimiento. No hay ningún tipo de intervención ni del usuario ni del manual.

Véase también manual.




Destrucción automática

(funcionamiento) Se puede destruir automáticamente el contenido del componente de un documento cuando el documento cumple con su fecha de vencimiento para el proceso de eliminación. La naturaleza del contenido y el diseño de la SDCM es la que determina si el contenido se destruye o no automáticamente o se destruye o no hasta que cumpla con la confirmación de la eliminación. Todos los componentes tienen una bandera que indica si el contenido se puede destruir o no de manera automática.

Principio de disponibilidad

(concepto) Aspecto no funcional de un sistema de información que describe el periodo durante el cual el sistema está totalmente estable y operacional, sobre todo en contraste con el tiempo en el que el sistema está funcionando parcialmente o está fuera de línea. Algunas veces, se expresa en proporción o porcentaje.

BCS (sigla) Esquema de Clasificación Empresarial

Copia de seguridad (verbo) Hacer una copia redundante de los datos del sistema de información con el fin de que el sistema se pueda restaurar después de presentarse una falla o un desastre.

(sustantivo) La copia redundante de los datos del sistema de información se guarda en un lugar seguro a fin de que se pueda utilizar más adelante para restaurar el sistema, si es necesario

Véase también restaurar y recuperar.

Booleano (concepto) Hace referencia a un valor que tiene solamente dos

posibles estados: verdadero o falso.

Véase también bandera.

Operador booleano (concepto) Es un operador que se utiliza para combinar de manera lógica los valores booleanos para calcular un solo resultado. Existen solo tres operadores booleanos básicos Y, O, y NO de los cuales se pueden derivar otras operaciones booleanas. Véase también Booleano.

Destrucción ascendente

(concepto) Es el método para manejar el proceso de eliminación en los casos en que se evalué de manera individual el periodo de retención de cada documento y se puedan eliminar por separado. La eliminación de la agrupación de documentos está asociada a las normas de procedimiento de sus contenidos, de manera que una vez que se destruyan los documentos, se destruya automáticamente la agrupación.




Navegar (Funcionamiento) Descubre entidades al explorar sus relaciones con otras entidades. Por ejemplo, a partir de un documento descubre su agrupación padre utilizando la relación padre /hijo, o al utilizar otras relaciones descubre sus componentes, clase, cronograma de eliminación, retención de eliminaciones asociadas, etcétera.

(ambigüedad) Navegar en un SDCM no se debe confundir con un navegador de Internet.

Clasificación comercial

(verbo) Véase clasificación.

Esquema de la clasificación comercial

(sustantivo) Véase esquema de clasificación.

Actividad comercial

(sustantivo) Actividad que desarrolla una empresa con el fin de constituir o cumplir con su función comercial reglamentaria, que puede incluir cualquiera de las áreas de actividad en la que puede participar una organización, o en la que está obligada a comprometerse con los controles normativos externos u otros tipos de control. “El análisis de la actividad y del proceso comercial le facilitará la comprensión de la relación entre el negocio de la organización y sus documentos”. (ISO 15489-2:2001, 3.2.3)

Función comercial (sustantivo) El área de actividad comercial que persigue la organización, relacionada generalmente con el objetivo o la misión de la organización y la ejecución de su estrategia y políticas comerciales. La ISO 15489 describe las funciones comerciales como soporte en la búsqueda de los objetivos y estrategias de la organización. (ISO 15489-2:2001, 4.2.2.2)

(ambigüedad) La función comercial que se utiliza en la clasificación no se debe confundir con el desempeño de una función.

Transacción comercial

(sustantivo) Hace referencia a la fase discreta o “paso constituyente” (ISO 15489-2:2001, 4.2.2.2) en una actividad comercial para la cual se conserva el documento probatorio. El documento puede incluir información relacionada con :

• La transacción comercial que se llevó a cabo;• Cuando tuvo lugar; y• Quiénes participaron.



Sistema comercial (sustantivo) Cualquier sistema de información que se utiliza como parte de la realización de actividades. Por ejemplo, un sistema de gestión financiera.

Cancelación (Funcionamiento) Véase Cancelación de la eliminación.




Captura (concepto) Es una actividad que conlleva a la creación de un documento en un SDCM. También se pueden utilizar otros términos para esto como la declaración de un documento. Muchas veces, esta apreciación depende de la percepción del usuario en cuanto a si el contenido del documento se debe trasladar a un medio de almacenamiento (captura), o se puede hacer un documento en su lugar (declarar).

Véase también declarar

Cascada (concepto) El impacto que tendrá en sus descendientes el cambio a una entidad. Por ejemplo, en el caso de los descendientes de una agrupación raíz, tanto las agrupaciones hijos como los documentos, heredan su clasificación de su agrupación padre, luego al cambiar la clase de agrupación raíz tendrá un efecto en cascada de padre a hijo, dando lugar a que todos los descendientes de la agrupación raíz sean reclasificados.

Véase también Jerárquico.

Certificación (adjetivo) El acto por el cual se reconoce formalmente que un sistema de gestión documental cumple con todos los requisitos de MoReq2010® con respecto a los servicios centrales y los módulos nominados. DLM Forum® es la única entidad que puede certificar un sistema documental, siempre sujeto a prueba por parte de un centro de prueba acreditado de MoReq2010® .

Véase también prueba.Hijo (sustantivo) Hace referencia a una entidad que forma parte de un

conjunto de entidades que pertenecen y están subordinadas a otra entidad padre. La entidad padre puede tener múltiples hijos, aunque cada entidad hijo solo tiene un padre. El vínculo entre las entidades padre e hijo, se conoce como relación padre/hijo.

Véase también antecesor, descendiente, padre y relación padre/hijo.

Agrupación hijo (sustantivo) Es cualquier agrupación que no es una agrupación raíz.

Véase también agrupación padre y agrupación raíz.



Clase (entidad) Una unidad de clasificación que puede estar asociada con una agrupación o con un documento. Las clases en MoReq2010® cuentan siempre con un programa de eliminación por defecto, que se hereda de cualquier documento que ellos clasifiquen, de conformidad con el Principio de la ISO 15489, que establece que la “Clasificación de actividades comerciales actúa como una herramienta de apoyo altamente eficaz para llevar a cabo las actividades comerciales y muchos de los procesos que intervienen



Término Explicación y relaciones con los conceptos generales

en la gestión de documentos incluyendo…el establecimiento de los periodos de retención correspondientes y las acciones para la eliminación de documentos”. (ISO 15489-1:2001, 9.5.1)

Véase también clasificación.

Clasificación (funcionamiento) El acto de asociar una clase a una agrupación o documento, teniendo como base el esquema de clasificación.

(sustantivo) Clase que se aplica a una agrupación o documento.

Véase también clase, clasificación y reclasificación por defecto.

Esquema de clasificación

(sustantivo) Representación de las funciones, actividades y transacciones comerciales de la organización como un conjunto de clases discretas que se pueden asociar con documentos y agrupaciones de documentos.

“Los sistemas de clasificación provienen del análisis de los procesos comerciales que se llevan a cabo para garantizar que los documentos y la descripción de sus metadatos representan con precisión el proceso comercial para el que fueron creados”. (ISO 15489-2:2001, 4.2.2.2)

Servicio de Clasificación

(servicio) Servicio para separar de forma lógica dentro de un SDCM responsable, desde el punto de vista operacional, con el fin de conservar las entidades clase dentro de un esquema de clasificación.

Aclarar (funcionamiento) Cuando se utiliza junto con una bandera o con un valor booleano, es decir, para asignar el valor “falso”.

Véase también bandera.

Cerrar (funcionamiento) La función de cerrar una agrupación de manera que ya no puede aceptar hijos adicionales que se pueden trasladar o crear allí. El usuario no puede cerrar una agrupación, salvo que todas sus agrupaciones hijos se hayan cerrado con anterioridad o se cierren de manera simultánea. Véase también Abrir.

Cierre (sustantivo) En cuanto a las agrupaciones se refiere, significa el hecho de estar cerradas. Una agrupación hijo o un documento se pueden trasladar a una agrupación cerrada, pero ninguna agrupación hijo o documento adicional se pueden trasladar o crear allí.



Código (tipo de dato) Elemento de metadato que solo puede contener uno de un grupo limitado de valores predefinidos.

Véase también tipo de dato y valor.




Columna (sustantivo) Lugar donde los elementos de metadatos o las propiedades de las entidades se organizan en tablas, cada fila de la tabla contiene normalmente el metadato de una sola entidad, mientras que cada columna contiene los valores por cada entidad de un solo elemento de metadato.

Véase también fila y tabla.

Comentario (metadato) Una anotación adicional, que por lo general la presenta el usuario, aunque algunas veces se crea automáticamente, la cual proporciona detalles explicativos e históricos posteriores para efectos de, como motivación o resultado de la toma de una acción importante.

Véase también comentario de un evento, comentario de exportación y comentario última revisión.

Aplicaciones disponibles en el mercado

(adjetivo) Un producto que se puede instalar y ejecutar en diferentes entornos y que requiere un mínimo de reconfiguraciones. Los productos COTS se diferencian de otras aplicaciones personalizadas que están diseñadas especialmente para entornos o situaciones específicas. MoReq2010® aplica igual a los productos COTS y a las instalaciones en las sedes individuales.

También conocidos como COTS.

Principio de Integridad

(concepto) Cuando se aplica al componente de un documento, asegura que colectivamente el contenido del documento incluye el documento completo garantizando así la integridad del mismo.

Véase también destructibilidad, discreción e inmutabilidad.

Búsqueda compleja (sustantivo) Búsqueda que se realiza al encadenar varias consultas de búsqueda dentro de una consulta de búsqueda compleja. Estos tipos de búsqueda son necesarios porque las entidades están relacionadas entre sí, algunas veces con relaciones complejas.

Véase también búsqueda.



Principio de cumplimiento

(concepto) El cumplimiento es un aspecto no funcional de un sistema de gestión documental que evalúa su idoneidad dentro de una industria en particular, o de competencia legal, mediante la evaluación de su soporte y adopción de diferentes normas y reglamentaciones. Estas normas y Reglamentaciones aplican a las tecnologías, obligaciones, políticas, derechos, medios de comunicación, formatos y normas de procedimiento de información, implementadas por un sistema de gestión documental.




Cumple con las normas

(adjetivo) Declaración del estado de cumplimiento de un sistema o proceso, que se usa en particular, para confirmar que el sistema de gestión documental cumple con la especificación MoReq2010®.

Véase también certificado y Sistema de Gestión Documental que cumple con la especificación MoReq2010®

Componente (entidad) Parte de un documento que representa un elemento discreto de contenido. Con el fin de completar un documento incluyendo todos sus componentes y su contenido, se debe manejar de manera atómica.

Contenido del Componente

(sustantivo) Elemento real del documento, ya sea un objeto físico o una secuencia digital. Las demás entidades en un SDCM son netamente representativas, que sostienen metadatos relacionados con, o extraídos del contenido.

Confirmación (funcionamiento) Véase confirmación de la eliminación

Periodo de confirmación

(sustantivo) Periodo comprendido entre la fecha de vencimiento del proceso de eliminación y la fecha de vencimiento de la confirmación de la eliminación, durante el cual el usuario debe garantizar que la eliminación del documento se llevó a cabo y lo confirma con el SDCM. La eliminación de un documento se congela a la espera de su confirmación o cancelación.

Véase también cancelación de la eliminación, confirmación de la eliminación y fecha de vencimiento de la confirmación de la eliminación.

Contenido (Sustantivo) Véase contenido del componente.

Metadato contextual (sustantivo) Metadato que no es de carácter obligatorio del MoReq2010® sino que está creado dentro de un SDCM en un contexto local para dar soporte a las necesidades locales del negocio y a las operaciones de una organización.

Definición del elemento de metadato contextual

(entidad) Definición de un elemento de metadato contextual. Estas definiciones se deben exportar siempre y cuando el metadato contextual se exporte para garantizar que un SDCM que importa datos de exportación puede interpretar el elemento de metadato y lo representa correctamente.

Servicio básico (sustantivo) Uno de los nueve servicios fundamentales y necesarios para una solución SDCM.



Co-requisito (Sustantivo) modulo para el cual se necesitan requisitos y consideraciones adicionales, si se implementa junto a otro módulo.

Véase también módulo, prerrequisito y servicio




COTS (sigla) Aplicaciones disponibles en el mercado, en particular en relación con productos de software.

Crear (funcionamiento) La función de adicionar una entidad nueva a un SDCM.

CRUD (sigla) Crear, leer, actualizar y borrar. Con frecuencia se consideran las cuatro operaciones fundamentales de un sistema en relación con sus datos.

(ambigüedad) MoReq2010® tiene una definición diferente y más especializada de los términos “crear“, “actualizar“ y ”borrar”.

Datos (sustantivo) Información almacenada en un formato electrónico o que se comunica vía Internet.

Véase también exportación de datos.

Flujo progresivo de datos

(verbo) Véase flujo progresivo de datos XML

Estructura de Datos (Estructura de datos) Metadato compuesto que consta de más de un elemento de metadato interrelacionados entre sí, unidos en una estructura para preservar su relación con el otro. Las estructuras de datos forman parte de las entidades de la misma manera que los elementos de metadatos simples.

Todas las estructuras de datos se proporcionan como parte del modelo de información del MoReq2010®, que incluye el sistema identificador único para cada estructura de datos. Por ejemplo, el identificador del sistema para la estructura de datos “Lista de Control de Acceso” es “60124baa-2625-4795- bf14-7e67f2224ccf”.

Base de Datos (sustantivo) Grupo de datos que por lo general está dividido en tablas de entidad del mismo tipo. Generalmente, las tablas están relacionadas entre sí por los identificadores de almacenamiento en una columna que hacen referencia a entidades de otra tabla.

Véase también columna, fila y tabla.

Archivo de Datos (sustantivo) Archivo informático legible que contiene datos en cualquier formato digital. El término “archivo de datos” ha sido acuñado específicamente para su uso en MoReq2010® con el fin de evitar cualquier ambigüedad con otros términos usados en la gestión de documentos.

(ambigüedad) La palabra “archivo” utilizada en este contexto no hace referencia a una agrupación.




Tipo de dato (sustantivo) Tipo de dato XML que se utiliza para definir las características de los elementos de metadatos. Los tipos de datos XML se utilizan completamente en MoReq2010® ya que esta estandarización permite diferentes soluciones SDCM para compartir las definiciones de los elementos de metadatos.

Fecha (tipo de dato) El elemento de metadato con base en el día, mes y año. La fecha no incluye información de hora o zona horaria y por lo tanto solo es exacta dentro de un periodo de 24 horas.

Fecha/hora (tipo de dato) Valor de metadato con base en la fecha y hora del día que pueden ser modificados por los usuarios y por lo tanto no es tan exacto como la marca del tiempo que se genera automáticamente. Los datos de fecha/hora no incluye la zona horaria. Véase también hora/fecha originada y marca de tiempo.

Declarar (concepto) Término relacionado con captura que describe la acción del usuario que puede anteceder a la creación de un registro en un SDCM.

Véase también captura.

Eliminación de duplicados

(concepto) La práctica de no almacenamiento o transmisión de la misma información más de una vez. La eliminación de duplicados se considera de mayor importancia para el proceso de exportación MoReq2010®. Cuando se exporta una cantidad de entidades pueden compartir los datos en común, como por ejemplo, la clase de un documento. Si se exportan a la vez varios documentos de la misma clase, entonces la información clase solo se exportará una vez.

Definición (entidad) Véase definición de función y definición de elemento de metadato.

Por defecto (concepto) Entidad o valor que se usa siempre que no se especifique explícitamente un reemplazo. Por ejemplo, un documento tiene clase por defecto (heredada de su agrupación padre) a menos que sea anulada al aplicar una clasificación diferente directamente al registro en sí.

Véase clasificación por defecto, programa de eliminación por defecto, identificador de idioma por defecto, y valor por defecto.



Clasificación por defecto

(sustantivo) La clase de una agrupación hijo o documento que se hereda automáticamente de su padre, a menos que sea anulado.

Véase también clase, por defecto y clasificación.




Programa de eliminación por defecto

(sustantivo) Programa de eliminación de un documento que hereda automáticamente de su clase, a menos que sea anulado.

Véase también por defecto y programa de eliminación.

Identificador de idioma por defecto

(metadato) Identificador de idioma que se utiliza para un elemento de metadato textual a menos que se especifique un idioma diferente cuando el elemento de metadato es un valor determinado.

Véase también por defecto y el identificador de idioma.

Valor por defecto (metadato) Valor de un elemento de metadato determinado automáticamente siempre que el metadato esté ejemplificado. El valor por defecto se almacena en la definición del elemento de metadato.Véase también por defecto y valor.

Borrar (funcionamiento) Borrar datos, especialmente una entidad, desde un SDCM de manera que no queden rastros. MoReq2010® solo permite que se borren entidades siempre y cuando no se hayan utilizado. Cuando las entidades se han utilizado no se pueden borrar y se deben destruir, dejando una entidad residual.

Hay una gran diferencia entre borrar una entidad y destruir una entidad.

Descendiente (sustantivo) En una estructura jerárquica, a partir de un entidad determinada, cualquier otra entidad que se pueda alcanzar siguiendo todos los caminos unidireccionales posibles desde las entidades padre hacia sus hijos.

Véase también antecesor, hijo y padre.

Descripción (metadato) Posibilidad de ampliar información describiendo

una entidad.

Véase también título.



Destruir (funcionamiento) Proceso controlado donde las entidades activas se convierten en entidades residuales mediante el borrado controlado de:

• Algunos de sus metadatos• Algunos de los eventos de sus eventos históricos, y • Su contenido, cuando se trata de documentos.

Hay una gran diferencia entre borrar una entidad y destruir una entidad.

Véase también eliminación ascendente.




Principio de Destrucción

(concepto) Cuando se aplica al componente de un documento, asegura que el contenido del documento se puede destruir para siempre, como resultado de la realización del proceso de eliminación en respuesta al programa de eliminación de documentos.

Véase también integridad, discreción e inmutabilidad

Reporte detallado (sustantivo) Reporte con base en un consulta de búsqueda que relaciona las entidades y sus metadatos, normalmente como una tabla.

Véase también reporte y reporte resumen.

Directorio (sustantivo) Sistema comercial externo común para los ambientes organizacionales modernos que conservan la lista de usuarios, grupo de usuarios y metadatos relacionados. Los directorios se implementan como un recurso fundamental que permite que otros sistemas comerciales, incluyendo los sistemas de gestión documental, interactúen con ellos y reutilicen esta información. Los protocolos comunes incluyen X.500 y LDAP. Normalmente los directorios no conservan información histórica sobre los usuarios y sus grupos de usuarios y el SDCM tiene responsabilidades adicionales para garantizar que se conserve en los casos en que se utilice un directorio externo.

Servicio de Directorios (sustantivo) Véase directorio.

Descubrimiento (concepto) En relación con el usuario, la búsqueda de entidades, sus metadatos y sus relaciones con otras entidades por medio de las herramientas de búsqueda y navegación.

Discreto (concepto) Individual, perceptible claramente por estar separada lógica o físicamente de otras entidades o unidades de información.

Principio de Discreción

(concepto) Cuando se aplica a los componentes de un documento, asegura que el contenido del componente es un elemento único que se identifica por separado del contenido de otros componentes y documentos.

Véase también integridad, destructibilidad e inmutabilidad.

Eliminación (funcionamiento) Llevar a cabo la acción de eliminación programada en un documento la cual dará como resultado bien sea su destrucción o el paso a una nueva etapa de su ciclo de vida. Los documentos solo se pueden eliminar de conformidad estricta con su programa de eliminación.




Proceso de eliminación

(sustantivo) Acción que se toma para disponer de un documento en respuesta al programa de eliminación de documentos. Si el documento no se retiente definitivamente, solo quedan tres posibles acciones de disposición:

• Revisión,• Transferencia, y• Destrucción.

Fecha de vencimiento para el proceso de eliminación

(metadato) La fecha, que marca el final del periodo de retención, cuando se debe llevar a cabo la acción de eliminación en un documento de conformidad con su programa de eliminación.

Véase también Fecha de vencimiento de la confirmación de la eliminación.

Cancelación de la eliminación

(funcionamiento) Cuando una acción de eliminación de transferencia o destrucción necesita confirmación, puede ser cancelada en vez de ser confirmada. Cancelar una acción de eliminación implica asignar un nuevo programa de eliminación para el documento.

Finalización de la eliminación

(funcionamiento) La acción de eliminación de revisión se debe terminar. Revisar un documento implica asignarle un nuevo programa de eliminación, como parte de la decisión de revisión.

Confirmación de la eliminación

(funcionamiento) Las acciones de eliminación de transferencia y destrucción de documentos la debe confirmar el usuario, excepto que los documentos tengan componentes que estén sujetos a destrucción automática. El usuario es quien confirma que la transferencia se ha realizado de manera exitosa o que el contenido de los documentos se destruyó realmente.

Véase también destrucción automática.

Fecha de vencimiento para la confirmación de la eliminación

(metadato) La fecha que marca el final del periodo de confirmación, para el cual la acción de eliminación que necesita confirmación, debería haberse llevado a cabo y confirmado por el usuario. Si la acción de eliminación no se confirma para esta fecha, entonces el SDCM lanzará una alarma.

Véase también alarma y periodo de confirmación.

Retención de la eliminación

(entidad) Una orden de carácter legal, administrativa o de otro tipo que impide la destrucción de documentos. A pesar de su nombre, retener la eliminación no impide la revisión o transferencia de documentos, sin embargo, no evitan que sean destruidos cambiando su acción de eliminación para mantenerlos en espera. La retención de la eliminación se puede aplicar a las clases y agrupaciones en su totalidad, así como a los documentos individuales.



Servicio de Retención de la eliminación

(servicio) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo del control de la retención de la eliminación.




Proceso de disposición (sustantivo) Proceso por el cual se actualiza y se maneja un documento, mediante la verificación de los cambios a su programa de eliminación y activación de la retención, del cálculo de su periodo de retención y aplicación de las acciones de eliminación cuando llegan a su fecha de vencimiento.

Programa de eliminación

(entidad) Programa detallado de ciclo de vida de un documento en el que se especifica lo siguiente:

• La activación de la retención (que se utiliza para determinar la fecha de inicio de la retención)

• El periodo de retención• La acción de eliminación, y • El periodo de confirmación

Véase también Programa de eliminación por defecto.

Servicio para programar la eliminación

(servicio) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo del control de los programas de eliminación.

DLM (Sigla) Gestión del Ciclo de Vida del Documento (conocido antes como “Données Lisibles par Machine”). Véase DLM Forum®.

DLM Forum® (sustantivo) Comunidad de documentos públicos y entidades interesadas en documentos, registros y en gestión del ciclo de vida de documentos e información, a través de la Unión Europea y fuera de allá. En febrero del 2010 el DLM Forum® se convirtió en una fundación sin ánimo de lucro y ahora es oficialmente el DLM Forum Foundation.

Véase también Consejo Directivo MoReq.

Fecha de vencimiento(sustantivo) Véase fecha de vencimiento de la acción de eliminación y fecha de vencimiento de la confirmación de la eliminación.

Duplicado (sustantivo) Una entidad que es una copia exacta de otra entidad. MoReq2010® permite que se dupliquen documentos, sus eventos y componentes, de manera que se pueda hacer, por ejemplo, un duplicado del mismo documento para ubicarlo en dos agrupaciones diferentes. Cada duplicado seguirá después su propio ciclo de vida por separado.

(funcionamiento) Función de duplicar un documento.Electrónico (adjetivo) Tener una representación puramente digital que se

almacene y se transmita por vía electrónica.

Véase también físico.




Elemento (sustantivo) Véase elemento de metadato.

Entidad (sustantivo) Entidades que representan unidades individuales y discretas de información dentro de un sistema de información. En un SDCM cada entidad debe ser de un tipo de entidad en particular y tiene algunas o todas las siguientes características:

• Sistema de metadatos;• Metadatos contextuales;• Lista de Control de Acceso;• Historial de eventos;

El sistema de metadatos y algunas veces los metadatos contextuales, enlazan la entidad con otras entidades, para establecer relaciones.

Diagrama de relaciones de entidades

(sustantivo) Técnica para configurar relaciones entre unidades de datos para describir un sistema de información. (ambigüedad) Las “entidades” y “relaciones” representadas en un diagrama de relación de entidades no son necesariamente las mismas entidades y relaciones que define MoReq2010®.

Subtipo de entidad (entidad) Derivación especializada de un tipo de entidad que puede mostrar comportamientos diferentes y que tiene elementos de metadato y funciones adicionales. Por ejemplo, la definición de un elemento de metadato contextual es un subtipo de definición de un elemento de metadato. MoReq2010® es completamente extensible, es decir que permite ingresar tipos y subtipos de entidades adicionales, según como sea necesario.Véase también tipo de entidad.

Tipo de entidad (entidad) Definición de una entidad. Los tipos de entidad que se relacionan a continuación, aparecen en los servicios básicos del MoReq2010®:

• Agrupaciones,• Clases,• Componentes,• Retención de la eliminación,• Programa de eliminación• Tipo de entidades,• Eventos,• Definición de funciones,• Grupos,• Definición de Elemento de Metadatos,• Documentos,• Roles,




• Plantillas, y• Usuarios.

Todos los tipos y subtipos de entidades se proporcionan como parte del modelo de información del MoReq2010® incluyendo el sistema identificador único para cada uno. Por ejemplo, el identificador del sistema para el tipo de entidad “documento” es “3ac228ef-c008-4524-9e41-5c4564eaa7f0”. Véase también subtipo de entidad.

Entrada (estructura de datos) Véase entrada de control de acceso y entrada cambio de metadatos.

Error (sustantivo) Falla en un programa o aplicación informática que impide la finalización exitosa de función.

Véase también registro de error e información ampliada sobre el error.

Registro de error (sustantivo) Registro de errores producidos dentro del SDCM. El registro de error se conserva al exterior del SDCM y contiene detalles e información ampliada sobre el error, por cada uno. El error se mantiene externamente para efectos de diagnóstico, con el fin de tener acceso a él, en caso de que el SDCM se caiga o presente fallas de inicio.

También se denomina registro externo

Evento (entidad) Entidad que se genera mediante la realización de una función. El evento conserva metadatos sobre:

• La función que se llevó a cabo,• Cuando se llevó a cabo,• Quien la realizó,• las entidades participantes,• Cuáles metadatos se cambiaron, y puede incluir• Un comentario de un evento.

Véase también función y entrada cambio de metadato.

Comentario de un evento

(metadato) Comentario que se incluye en un evento para suministrar más detalles sobre el mismo.

Véase también comentario.




Historial del evento (sustantivo) Todos los eventos en los que ha participado una entidad en particular. El SDCM mantiene el historial del evento para todas las entidades de conformidad con el principio expresado en la norma ISO 15489 que dice:

“Los Sistemas de Gestión Documental deben contener representaciones completas y exactas de todas las transacciones que se producen con relación a un documento en particular. Incluyen los procesos asociados con los documentos individuales”. (ISO 15489-1:2001, 8.3.2)

Probatorio (concepto) Tener peso como evidencia, particularmente en sentido legal. Parte de la razón por la cual se utiliza un SDCM es que complementa el valor probatorio de los documentos de una organización puesto que es la forma en que ellos pueden demostrar como los han controlado.

Exportar (funcionamiento) Función que desempeña un usuario donde una o más entidades y sus entidades relacionadas, se envían como datos XML, ya sean exportados en su totalidad o como placeholders. (Marcadores de posición)

(sustantivo) La exportación de datos se produce como resultado de la exportación de entidades en el formato de exportación de datos de MoReq2010®

Véase también importar, Algoritmo de compresión sin pérdida, algoritmo de compresión con pérdida y transferencia.

Comentario de exportación

(metadato) Comentario hecho por el usuario que realiza la exportación, el cual se incluye posteriormente en los datos exportados y en el comentario de eventos generado por la exportación.

Véase también comentario y evento de comentario

Exportación de datos (sustantivo) La salida de archivo de datos de un SDCM incluida en una exportación y en el formato de exportación de datos de MoReq2010®

Véase también formato de exportación de datos y datos XML. Formato de exportación de datos

(sustantivo) Formato específico de datos XML que ofrece un esquema válido para la exportación de todas las entidades, cuyo diseño fue realizado para acompañar el MoReq2010®. Véase también exportación de datos y datos XML.



Identificador de exportaciones

(metadato) El SDCM debe generar un identificador único, llamado identificador de exportaciones, que se utiliza para cada exportación. Se incluye en la exportación de datos y en los eventos generados por la exportación, para mostrar cuales entidades se exportaron en su totalidad o como placeholders.

Véase también UUID.




Exportar marcadores de posición

(sustantivo) Cuando se exporta una entidad como exportar marcadores de posición, se exporta también su sistema de metadatos, la lista de control de acceso y las entidades importantes, pero no sus metadatos contextuales, las entidades incluidas ni el historial de eventos.

Proceso de exportación (sustantivo) Proceso por el cual se exportan entidades desde un SDCM. El proceso de exportación implica:

• Configurar las entidades para exportación, • Determinar si van a ser exportadas en su totalidad o como placeholders. (marcadores de posición)• Eliminación de los duplicados, y• Realizar la operación de exportación.

Servicio de exportación (servicio) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo para llevar a cabo el proceso de exportación y el control de las exportaciones.

Exportados en su totalidad

(verbo) Cuando se exporta en su totalidad una entidad, se exporta también su sistema de metadatos, metadatos contextuales, la lista de control de acceso, las entidades incluidas, las entidades importantes y el historial de eventos.

Información ampliada del error

(sustantivo) Información de diagnóstico pormenorizada sobre la razón por la que se produjo el error en particular.

Módulo de extensión (sustantivo) Ampliación de los requisitos de MoReq2010®

desarrollada por el Consejo Directivo de MoReq y emitida por el DLM Forum®. El módulo de extensión incluye:

• Conceptos claves,• Requisitos funcionales,• Requisitos No Funcionales,• Glosario de términos nuevos, y• Extensiones al modelo de información.

Cada modulo de extensión también tiene sus propios casos de prueba y se pueden probar y certificar independientemente de los servicios básicos, siempre y cuando el SDCM haya sido certificado como compatible con MoReq2010®

Los módulos de ampliación se usan para agregar flexiblemente funciones adicionales a los servicios básicos en relación con tecnologías, industrias y estándares de cumplimiento específicos.

Externo (concepto) Funcionamiento autónomo fuera de control del SDCM con almacenamiento de datos por separado que no son controlados por el SDCM.




Registro externo (sustantivo) Véase Registro de error.

Falla (verbo) Véase error.

Primer día de la semana

(sustantivo) Se considera el día en que comienza la semana y se utiliza para la búsqueda y elaboración de reportes. Por ejemplo, los consultas de búsqueda, “Buscar documentos con fecha de vencimiento para la acción de eliminación la próxima semana” podrían tener resultados diferentes, dependiendo en teoría, de cuando comienza y termina la “próxima semana”. Por tradición el primer día de la semana es el domingo, aunque muchas organizaciones utilizan el lunes, ya que por lo general representa el primer día laboral.

Uso por primera vez (concepto) El concepto de Ciclo de Vida que se maneja en esta especificación es que una entidad se puede crear, modificar y borrar hasta el momento en que se asocia por primera vez con otra entidad. Después de usarse por primera vez, algunos metadatos quedarán permanentes y por lo tanto, debe destruirse la entidad, en vez de eliminarla, dejando una entidad residual. El concepto de uso por primera vez no aplica a ciertas entidades específicas, como documentos, componentes y eventos, así como tampoco a tipos de entidades, definiciones del sistema elemento de metadatos y definiciones de funciones establecidas por MoReq2010®.

Véase también marca de tiempo usado por primera vez.

Marca de tiempo usada por primera vez

(metadato) Marca de tiempo que aplica a una entidad cuando se

utiliza por primera vez. Véase también Marca de Tiempo.

Rol fijo (sustantivo) Rol integrado que forma parte del diseño de un SDCM y no se puede modificar, borrar o destruir. Algunos productos se suministran con ciertos roles predefinidos por el proveedor.

Véase también roles configurados previamente.

Bandera (tipo de dato) Elemento de metadato con base en un valor booleano que solo puede ser “verdadero “o “falso”. Cambiar el valor a “verdadero” se describe como” configurar”, mientras que cambiar el valor a ‘falso” se describe como “aclarar’’ la bandera. Véase también booleano, aclarar y configurar.

Diagrama de Flujo (sustantivo) Técnica para configurar procesos en un sistema de información.

Formato (sustantivo) Véase formato de exportación de datos y formato de reportes.




Búsqueda de texto completo

(concepto) Técnica de búsqueda de texto utilizando todas las palabras, más que la comparación de patrones. La búsqueda de texto completo es particularmente relevante a la información textual, y se mejora al conocer el idioma del texto. Esto, por ejemplo, mejora el motor de búsqueda para ignorar los sufijos y los prefijos (conocidos como “palabra derivada”), para buscar sinónimos, y para ubicar una importancia relativa en diferentes palabras en una frase.

La búsqueda del texto completo es “confusa” y muchos de los motores de búsqueda establecen un valor específico en resultados diferentes que los ordena a como mejor encaje en los criterios de búsqueda. Este valor específico es lo que se denomina puntuación relevante.

Véase también puntuación relevante y textual.

Función (funcionamiento) Operación predefinida en la que intervienen una o más entidades participantes, realizada por un usuario. Cada función tiene un resultado esperado incluido en las especificaciones de MoReq2010®. Las funciones están estrechamente relacionadas con los requisitos funcionales que especifican las funciones necesarias del SDCM.

(ambigüedad) La función no se debe confundir con la función comercial utilizada en la clasificación.

Definición de Función

(entidad) Definición de una función que se representa como una entidad. Las definiciones de función se utilizan para el control de acceso y en eventos que se generan mediante la realización de funciones. El control de acceso y las definiciones de función se incluyen en los roles que luego se otorgan a los usuarios y a los grupos de usuarios. Para realizar una función al usuario se le tuvo que otorgar un role que incluye la definición de su función. Cuando se generan los eventos, la definición de función de la función desarrollada se incluye en el evento.

La definición de función se proporciona como parte del modelo de información del MoReq2010® incluyendo el sistema identificador único para cada función. Por ejemplo, el identificador del sistema para la función “Grupo – Eliminar Usuario” es c3713f12-feb6-459e-a21a-7e63aaeeea6c”.

Requisito Funcional

(sustantivo) Requisito que indica lo que debe hacer un SDCM. Los requisitos funcionales se pueden probar para determinar si un SDCM en particular es compatible con MoReq2010®.

Véase también Requisito No funcional.



Generar (verbo) Creación automática de entidades, como eventos y otra información generada por un SDCM.




Buena practica (concepto) Métodos de trabajo aceptados que la experiencia demuestra que producen resultados por encima del promedio, en especial los que tienen que ver con una disciplina en particular como la gestión documental.

Otorgar (funcionamiento) Otorgar un rol a un usuario o a un grupo de usuarios. Al asignarle un rol se actualizará la lista de control de acceso a la que pertenece una entidad o servicio y se adicionará o modificará una entrada de control de acceso.

Véase también revocar y rol.

Grupo (entidad) Entidad que normalmente representa un equipo o una unidad de negocio dentro de la organización, y tiene varias entidades de usuarios como afiliados.

Jerárquico (concepto) Estructura usando relaciones padre/hijo de manera que cada entidad puede ser entidad padre, o entidad hijo, o ambos. Las jerarquías están conectadas, de manera que cada entidad se debe incluir para tener por lo menos una relación padre/hijo con otra entidad, y no cíclica, de modo que ninguna entidad puede ser el antecesor (o descendente) de si mismo.

Véase también Heredar.

Heterogéneo (concepto) Comprende entidades que son diferentes de acuerdo con algunas características fundamentales. MoReq2010® utiliza este término para referirse a las agrupaciones que contienen documentos que son clasificados utilizando clases diferentes. Véase también homogéneo.

Homogéneo (concepto) Comprende entidades que son iguales o similares de acuerdo con algunas características básicas. MoReq2010® utiliza este término para referirse a las agrupaciones que contienen documentos que tienen la misma clase heredada de su agrupación padre. Véase también heterogéneo.

Identificador (metadato) Véase identificador de idioma, identificador de certificación SDCM, identificador de compatibilidad del Módulo, identificador del tipo de servicio e identificador del sistema.




Principio de inmutabilidad

(concepto) Cuando se aplica a los componentes de un documento, asegura que permanece sin cambio el contenido del componente. Una vez que se crea el documento, el contenido de sus componentes no debe cambiar con el tiempo.

Véase también integridad, discreción y destructibilidad.

Implementar (verbo) Interpretar y codificar los requisitos del MoReq2010®

en una aplicación. Para implementar la especificación, los proveedores deben desarrollar los requisitos en la implementación.

Implementación (sustantivo) Aplicación que implementa los requisitos del MoReq2010®.

También se conoce como solución.

Implementar identificador de módulo

(metadato) Véase identificador del módulo.

Implementar identificador de servicio

(metadato) Véase identificador del servicio.

Importar (funcionamiento) Reconstitución de copias de las entidades que han sido exportadas de un SDCM a otra SDCM diferente, por medio de la entrada de datos XML utilizando el formato de exportación de datos de MoReq2010®

.

Véase también exportar, Algoritmo de compresión sin pérdida, Algoritmo de compresión con pérdida y transferencia.

En su totalidad (calificador) Véase Exportado en su totalidad

En el sitio (calificador) Véase administrado en el sitio.

Inaccesible (adjetivo) No se puede inspeccionar porque el usuario no tiene acceso a la entidad.

Véase también acceso y control de acceso.

Entidad incluida (concepto) Algunas entidades incluyen otras entidades. Cuando se exportan en su totalidad, sus entidades incluidas también se deben exportar en su totalidad. Por ejemplo, una agrupación incluye sus agrupaciones hijo y sus documentos, y un documento incluye sus componentes. Cuando la agrupación se exporta en su totalidad todos sus descendientes se exportarán también de la misma forma y los componentes de los registros que son descendientes de la agrupación también se exportarán.




Información (sustantivo) Hechos conocidos de una persona u organización. En caso de que la información proporcione evidencia de las actividades o transacciones comerciales de una organización, dicha información se debe capturar como un documento. Por lo tanto, los documentos de la organización se describen como un sub-grupo de la información disponible de esa organización.

La información se puede manejar a través de un sistema de información, mientras que los documentos se pueden manejar a través de un sistema de información especializado conocido como sistema de gestión documental. Este sistema implementa funcionalidades tan particulares que se ajustan adecuadamente a la gestión documental.

Modelo de Información (sustantivo) Modelo de metadatos funcional y estructurado que se considera como la base de todo el MoReq2010® y de los mapas de cada entidad, de los elementos de metadatos y de la función uno a otro. El cumplimiento estricto del modelo de información es vital para garantizar que la exportación de datos de las diferentes soluciones SDCM sea completamente compatible.

Sistema de información

(sustantivo) Conjunto integrado de componentes cuya función es recopilar, almacenar, procesar y comunicar información. Los principales componentes de los sistemas de información son: hardware y software, bases de datos, sistemas de telecomunicaciones, recursos humanos y procedimientos.

Del sistema de información (2011). En la Encyclopædia Britannica. Obtenido de http://www.britannica.com/EBchecked/topic/287895/information-system

Heredar (verbo) Véase herencia.

http://www.britannica.com/EBchecked/topic/



Herencia (concepto) Adopción de una entidad con las características o propiedades de otra entidad para su asociación. Por lo general, la herencia se lleva a cabo a través de la relación padre/hijo, aunque no en todos los casos. Por ejemplo, un documento hereda su programa de eliminación por defecto de su clase. El principio de herencia se utiliza en el MoReq2010® en las siguientes áreas principales:

• Control de acceso,• Clasificación,• Programas de eliminación,• Retención del proceso de eliminación, y• Exportación.




Inspeccionar (funcionamiento) Examinar una entidad y sus metadatos. El acceso a la función inspeccionar es fundamental para el proceso de descubrimiento. Si el usuario no puede inspeccionar una entidad se considera inaccesible y por lo tanto no puede haber ninguna señal de acceso del usuario a la entidad a través del SDCM durante la navegación, búsqueda o por cualquier otra forma.

Instalar (verbo) Inicializar una instancia de un SDCM para instalar y configurar el hardware y software necesario.

Integración (concepto) Interactuar e interaccionar con otro sistema comercial. La integración estricta implica una estrecha cooperación.

Principio de integridad (concepto) Al igual que autenticidad, confiabilidad y facilidad de uso, es una de las principales características de un documento según la norma ISO 15489.

“Se entiende por integridad de un registro a aquel que se encuentra completo y sin alteraciones”. (ISO 15489-1:2001, 7.2.4)

Véase también autenticidad, confiabilidad y facilidad de uso.

Interface (sustantivo) Parte de un sistema de información que ofrece a los usuarios y/o a otros sistemas, su funcionalidad. Al interactuar con la interface de un SDCM, el usuario puede realizar funciones.

Interoperabilidad (concepto) Capacidad que tiene un sistema para poder funcionar utilizando datos e información suministrada por otro sistema. En concreto, la interoperabilidad del MoReq2010® entre sistemas de gestión documental se define como la capacidad que tiene un sistema fuente para exportar sus entidades y de un sistema destino para importar y representarlos como entidades completas y totalmente funcionales junto con las propias.

Idioma (sustantivo) Lenguaje humano. Los idiomas se especifican en MoReq2010® utilizando identificadores de idiomas.

Véase también Idioma por defecto e identificador de idioma. Identificador de Idioma

(tipo de dato) Los identificadores de idiomas de MoReq2010®

deben ser compatibles con la normativa RFC5646 y con IANA Language Subtag Registry.

Véase también textual e identificador de idioma por defecto.



Comentario última revisión

(metadato) Comentario hecho por el usuario que realiza la última revisión al documento. El comentario a la última revisión se aplica al documento como metadato, para que los usuarios entiendan cuales fueron los asuntos que se tuvieron en cuenta en la anterior revisión.

Véase también comentario, última revisión de marca de tiempo y revisión.




Última revisión de marca de tiempo

(metadato) Sistema que establece la fecha y la hora de la última revisión. La última revisión de marca de tiempo se utiliza cuando se tiene en cuenta el comentario de la última revisión para determinar cuánto hace se que realizó la evaluación. Véase también comentario de la última revisión, revisión y marca de tiempo.

Nivel (sustantivo) La intensidad de la estructura jerárquica como medida para contar el número de entidades del antecesor común de todas las entidades en la jerarquía, y hacer el seguimiento de padres a hijos hasta su descendiente más lejano, si este descendiente tiene la mayor intervención en la relación padre/hijo.

Véase también jerarquía y niveles máximos de agrupación.

Ciclo de Vida (concepto) Cada entidad en un SDCM tiene un ciclo de vida predeterminado que comienza con la creación de una entidad y cuenta con varias fases dependiendo de su tipo de identidad. La entidad está activa inicialmente hasta que se destruye, y se convierte en una entidad residual.

Suprimir (funcionamiento) Término que se utiliza para describir la remoción de la retención de la eliminación de una clase, agrupación o documento. Cuando se destruye la retención de la eliminación, inmediatamente se suprime.

Retención jurídica (sustantivo) En MoReq2010® el término retención de la eliminación se utiliza en vez de “retención jurídica” Véase Retención de la eliminación

Localización (concepto) Personalizar una instancia individual de un SDCM para dar cumplimiento a los requisitos locales. Este proceso se puede hacer de diferentes formas, teniendo en cuenta todos los aspectos de localización que son el uso de idiomas diferentes, creación de roles específicos, diseño de un esquema de clasificación organizacional, definición de los elementos de metadatos contextuales, uso de diferentes títulos y descripciones por tipos de entidades y, definiciones de funciones.

Registro (sustantivo) Véase registro de error



Lógica (concepto) Diferentes desde el punto de vista conceptual. Por ejemplo, un servicio dentro de un SDCM se puede diferenciar de manera lógica de otros servicios, mientras que realmente siguen siendo parte del mismo codebase; o dos componentes diferentes pueden tener el mismo contenido aunque use punteros para que parezca como si tuvieran contenidos diferentes, cumpliendo así con el principio de discreción.




Algoritmo de compresión sin pérdida

(concepto) Cuando se usa en el contexto de interoperabilidad, o cuando se exporta e importa, este concepto hace referencia a la idea de que la información contextual importante no se pierde durante la transferencia. Véase también exportar, importar, Algoritmo de compresión con pérdida y transferencia.

Algoritmo de compresión con pérdida

(concepto) Cuando se usa en el contexto de interoperabilidad, o cuando se exporta e importa, significa que alguna información contextual, como metadatos, eventos, listas de control de acceso o relaciones con otras entidades se pierden durante la transferencia.

Véase también exportar, importar, Algoritmo de compresión sin pérdida y transferencia.

Principio de capacidad de mantenimiento

(concepto) Característica no funcional de un sistema de gestión documental que describe la forma relativamente fácil de mantener la actualización de una aplicación determinada o la instalación en el sitio. El sistema se considera menos sostenible si tiene dificultad para prestar el servicio, se debe tomar desconectado por un periodo representativo de manera que se pueda aplicar las actualizaciones y ajustes correspondientes, o requiere de gastos costosos por concepto de soporte o contratos de mantenimiento con terceros.

Versión mayor (sustantivo) Véase versión.

Gestión en el sitio (concepto) La gestión de documentos con componentes cuyo contenido está ubicado en otro sistema de información externa.

Principio de manejabilidad

(concepto) Característica no funcional de un sistema de gestión documental que hace referencia a la forma como se maneja y administra dicho sistema. La labor del administrador técnico es garantizar que el sistema de gestión documental permanezca en funcionamiento, mientras que el administrador de documentos tiene la responsabilidad de garantizar que este sistema se use eficazmente.

Mandato (metadato) Instrumento de carácter legal o de otro tipo que vincula la autoridad procesal para el programa de eliminación o para las eliminaciones retenidas.



Manual (adjetivo) Operación o función que realiza un usuario en especial en contraste con la operación o función automática que realiza el SDCM de conformidad con sus propias normas de procedimiento. Es importante tener en cuenta que un usuario puede ser otro sistema comercial. Por consiguiente, la función y operación “manual” no necesariamente es realizada por humanos.

Véase también automático.




Niveles máximos de agrupación

(metadato) Es el número de niveles de agrupación permitido por debajo de la agrupación raíz determinada. Si a los niveles de agrupación máxima se le asigna un valor de cero, luego entonces ninguna agrupación hijo se puede adicionar por debajo de la raíz.

Véase también nivel.

SDCM (Sigla) Sistema de Gestión Documental compatible con MoReq2010®.

Identificador de certificación SDCM

(metadato) Identificador único universal emitido por DLM Forum® para otorgar el certificado de cumplimiento de MoReq2010®. El identificador de certificación SDCM se utiliza para reportar el estado de cumplimiento del SDCM.

Véase también certificado e identificador del sistema. Metadato (sustantivo) Información sobre una entidad compuesta por varios

elementos de metadatos

Véase elemento de metadato.

Entrada para cambiar metadatos

(estructura de metadatos) Estructura de datos incluida en un evento en el que uno o más elementos de metadatos fueron modificados por el evento. Cada entrada para el cambio de metadatos contiene el valor de un elemento de metadato antes y después de que fue modificado.

Elemento de Metadato

(sustantivo) Un objeto de un metadato descrito en la definición de elemento de metadato que tiene valor cero o más valores que le han sido determinados por los usuarios y por el SDCM.

Definición del Elemento de Metadato

(entidad) Definición de un elemento metadato que indica, entre otras propiedades, sus:

• Título – nombre del elemento de metadato;• Tipo de dato – Tipo de metadato que contiene;• Cardinalidad – cantidad de valores que puede tener; así como • Si estos valores los puede cambiar el usuario.

Véase definición del elemento de metadato contextual y definición del sistema de elemento de metadato.

Servicio de metadato

(servicio) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo para manejar las definiciones del elemento de metadato y las plantillas de metadatos.

Véase también servicio del modelo de metadado.



Plantilla de metadato

(entidad) Plantilla.




Valor del metadato (sustantivo) Véase valor.

MGB (sigla) Consejo Directivo de MoReq.

Migración (funcionamiento) Variante de transferencia cuya intención es trasladar todas o un grupo considerable de entidades activas de un sistema de gestión documental a un SDCM nuevo que permite que sean administradas por un nuevo dueño, en un ambiente nuevo o por una tecnología o solución nueva.

Por lo general, el objetivo de la migración es desactivar el sistema de gestión documental anterior. Algunas veces la fuente no es el Sistema de Gestión Documental compatible con MoReq2010® y la migración es un ejercicio singular que tiene como finalidad reprogramar los documentos más antiguos en el formato de exportación de datos utilizado por MoReq2010®.Una vez migrados al SDCM, las entidades se pueden volver a transferir en el futuro, sin que sufran pérdidas.

Versión menor (sustantivo) Véase versión.

Modelo Servicio de metadato

(servicio) Implementación preferida del servicio del rol del MoReq2010®.

Véase también servicio de metadato.

Modelo Servicio del rol

(servicio) Implementación preferida del servicio del rol del MoReq2010®.

Véase también servicio del rol.

Servicio modelo (concepto) Servicio definido por la especificación MoReq2010®,

que se puede reemplazar en su operación por un servicio de funcionamiento similar, con un grupo diferente de normas de procedimiento, definidas para una solución SDCM en particular. Para utilizar un servicio de reemplazo por un servicio modelo, es necesario haber probado el SDCM para garantizar una estrecha similitud en la funcionalidad global, que sea capaz de exportar sus propias estructuras de propiedad de datos en el formato de exportación de datos del MoReq2010®

Véase Modelo servicio de metadato y modelo servicio del rol.

Modificar (funcionamiento) Asignar un valor nuevo a un elemento de metadato, o cambiar o borrar un valor anterior.

Véase también asignar y asociar.




Modificable (adjetivo) Indica si un usuario puede o no modificar un elemento de metadato. Cuando el elemento de metadato no se puede modificar, se dice que es “sólo de lectura”.

Módulo (sustantivo) Véase modulo de extensión y modulo de aplicación informática plug-in.

Identificador del Módulo

(metadato) Identificador único universal suministrado por DLM Forum® que se utiliza en el suministro de datos en el SDCM, para indicar que implementa una versión mejor en particular de un módulo de MoReq2010®.

Véase también modulo, identificador del sistema y versión.

MoReq® (Sigla) Requisitos Modulares para el sistema de Gestión Documental (antiguo “Modelo de Requisitos para la Gestión de Documentos Electrónicos”).

(sustantivo) Término genérico utilizado para hacer referencia a cualquiera de las diferentes especificaciones publicadas por MoReq®, que abarcan MoReq® (2001), MoReq2® (2008) y MoReq2010®.

(ambigüedad) Término específico utilizado para hacer referencia a la especificación original de MoReq® publicada en el 2001.

También se puede utilizar de manera informal para denotar la versión más reciente de la especificación MoReq®, que corresponde a MoReq2010®.

Consejo Directivo MoReq

(sustantivo) Sub-Comité del DLM Forum® nombrado por el Comité Ejecutivo para administrar la especificación MoReq®

y las actividades relacionadas, que incluyen:

• Desarrollo, extensión, localización y adaptación a futuro, a través del patrocinio y grupos de trabajo colectivos;

• Traducción de la especificación a diferentes idiomas;• Emisión de notas de guía y Recursos complementarios;• Mantenimiento, aclaración y actualización;• Educación, talleres y programas de capacitación;• Mercadeo y publicidad;• Protección de la marca y gestión de los acompañantes.• Prueba y programa de certificación a través de una red de centros de pruebas acreditados.

El Consejo Directivo del MoReq® se conoce comúnmente como MGB.




MoReq2® (sustantivo) Sucesor inmediato de la especificación MoReq® desarrollada por DLM Forum® después de un estudio preliminar en el 2005, y lanzada en marzo de 2008. MoReq2® (2008) reemplazó a MoReq® (2001) y fue reemplazada por MoReq2010® en mayo del 2011.

MoReq2010® (sustantivo) La versión más reciente de la especificación MoReq® desarrollada por el programa de trabajo MoReq2010®, seguida del mapa del camino (roadmap) del MGB’s 2009.

El programa de trabajo de MoReq2010® se inició en la reunión del DLM Forum® celebrada en Madrid en Mayo de 2010, y después de un año de desarrollo, el MoReq2010® se lanzó en la reunión del DLM Forum® que se llevó a cabo en Budapest en mayo de 201.

MoReq2010® reemplaza a MoReq2® (2008). Sistema de Gestión Documental compatible con MoReq2010®.

(sustantivo) Sistema de Gestión Documental que es totalmente compatible con los servicios básicos de MoReq2010® y también puede ser totalmente compatible con uno o más módulos. El sistema de gestión documental compatible con MoReq2010®

se conoce normalmente como SDCM. Para asegurar que un SDCM es completamente compatible con MoReq2010®, debe ser probado y certificado por DLM Forum®.

Traslado (funcionamiento) Se utiliza en el contexto de una agrupación para señalar el retiro de una entidad hijo o de un documento de una agrupación y su adición a otra agrupación. La agrupación se puede trasladar para que se convierta en una agrupación raíz o se traslade de una agrupación raíz para convertirse en una agrupación hijo. Los registros siempre deben pertenecer a una agrupación.

Véase adicionar o retirar

Multi-arriendo (concepto) Con respecto al sistema de gestión de documentos, aquel que se comparte con diferentes organizaciones de manera que cada organización tiene su propia parte del sistema de gestión documental y no tiene acceso a los documentos ni a otras entidades que pertenecen a otras organizaciones.

Modelo de metadatos nativos

(sustantivo) Modelo de metadatos de un SDCM que no utiliza el modelo Servicio de metadato. Por lo general el modelo de metadatos nativo no es compatible con el modelo de metadatos de un SDCM suministrado por un proveedor diferente.

Véase propietario.




Modelo de permisos nativos

(sustantivo) Modelo del rol de un SDCM que no utiliza el modelo de Servicio del rol. Por lo general, el modelo de permisos nativos no es compatible con el modelo del rol, ni con el modelo de permisos nativos, de un SDCM suministrado por un proveedor diferente.

Véase propietario.

Designado (adjetivo) En relación con las entidades, hace referencia a una entidad o entidades que han sido escogidas o seleccionadas por el usuario.

Role No Administrativo

(sustantivo) Role que solo se hereda cuando se incluye en la lista de control de acceso de una entidad hijo. Los roles no administrativos se pueden excluir concretamente de ser heredados. Los roles administrativos nunca se pueden bloquear.

Véase también role administrativo

Sistema no compatible

(sustantivo) Sistema de gestión documental que no es compatible con el MoReq2010®, concretamente aquel que no ha sido certificado por el DLM Forum®.

Véase también sistema de información y sistema de gestión documental compatible con MoReq2010®

No Funcional (adjetivo) Característica o evaluación cualitativa, opuesta a la perspectiva netamente funcional.

Véase también, requisito no funcional.

Requisito No Funcional

(sustantivo) Requisito importante de un sistema que no se expresa como una función particular que deba realizar el sistema. Los requisitos no funcionales evalúan, no lo que el sistema hace, sino lo bien que lo hace. Esto incluye la evaluación cuantitativa de los siguientes principios:

• Desempeño,• Ampliación,• Manejabilidad,• Portabilidad• Protección,• Privacidad,• Facilidad de uso,• Accesibilidad• Disponibilidad,• Confiabilidad,• Recuperabilidad,• Mantenimiento,• Soporte,




• Garantía, y• Cumplimiento.

Véase también requisito funcional.

Abierto (sustantivo) Para agrupaciones, un estado que permite la creación de nuevas agrupaciones hijo o documentos en la agrupación, o que permite que se traslade a la agrupación, aquellas agrupaciones o documentos que ya existen.

Véase también cerrado.

(funcionamiento) La función de abrir una agrupación cerrada con el fin de que pueda aceptar hijos adicionales que puedan ser trasladados o creados allí.

Véase también cerrado.

Funcionamiento (sustantivo) Acción que se toma por lo general por un SDCM como respuesta a una norma de procedimiento interno, o a un estímulo externo. La función es una forma de operación especializada que por lo general (aunque no exclusivamente) la comienza el usuario, involucra a uno o más entidades participantes, y puede dar lugar a que se genere un evento.

Véase también función.Trimestre en una organización

(sustantivo) Un trimestre corresponde a un periodo de tres meses, en un año organizacional.

Véase también año en una organización.

Año en una organización

(sustantivo) Muchas organizaciones tienen un año financiero o administrativo que consta de cuatro trimestres, cada uno de tres meses, que no está alineado con el año calendario.

Véase también trimestre en una organización.

Fecha/hora de origen (metadato) La fecha y la hora en que se origina una entidad. Por defecto, MoReq2010® utiliza la fecha y hora de la creación de la entidad en el SDCM, sin embargo la fecha y hora real del origen de la entidad puede ser anterior a esta. Véase también fecha/hora.

Sustitución (verbo) Proporciona un reemplazo explícito de una entidad o valor por defecto, especialmente con respecto a la sustitución de una clasificación heredada de una agrupación o registro, o la sustitución del programa de eliminación por defecto, derivada de su clase.

Véase por defecto y heredar.




Paginación (concepto) Con respecto específicamente a los resultados de búsqueda, dividir un grupo grande de resultados de búsqueda en pequeños subgrupos que se devuelven de manera individual al usuario que realiza la búsqueda.

Véase también resultados de búsqueda.

Padre (sustantivo) Una entidad, en una estructura jerárquica, que tiene una o más entidades hijos. El enlace entre entidades padre e hijo se conoce como relación padre/hijo.

Véase también antecesor, hijo y descendiente.

Agrupación padre (sustantivo) Agrupación que contiene ya sea agrupaciones hijo o registros.

Véase también agrupación hijo y agrupación raíz.

Relación padre/hijo

(sustantivo) Relación entre padre e hijo en una estructura jerárquica. En MoReq2010® esta relación se establece mediante el almacenamiento de una referencia a los padres como parte del metadato de la entidad hijo.

Entidad participante (sustantivo) Entidad que se considera que ha participado en un evento, o para la que el evento es importante. El evento forma parte de la historia de eventos de cada entidad participante. Véase también evento

Desempeño (verbo) Llevar a cabo o ejecutar una función con relación a una o más entidades.

Véase también error y función.

Principio de desempeño

(concepto) Característica no funcional de un sistema de gestión documental relacionada con la velocidad y eficiencia del proceso.

Física (adjetivo) Tener presencia física en un mundo físico o real. Por ejemplo, un documento de contenido escrito en papel, comparado con un documento de contenido electrónico.

(ambigüedad)La palabra “física” se utiliza también como lo opuesto a lógica.

Véase también electrónico y lógica.

Placeholder, o Marcadores de posición.

(sustantivo) Véase exportar placeholder.




Módulo de aplicación informática de integración

(sustantivo) Módulo de MoReq2010® que integra los servicios básicos y proporciona funcionalidades especializadas en un área en particular. Los módulos informáticos de integración están organizados en series y para cumplir con cada SDCM deben implementar por lo menos un módulo informático de integración de cada serie. Un SDCM puede implementar más de un módulo de integración de la misma serie.

Puntero (concepto) Técnica para implementar el principio de discreción en una forma lógica, más que en una forma física. Por ejemplo, supóngase que dos documentos diferentes tienen componentes que incluyen el mismo contenido. En lugar de guardar dos copias del contenido, el SDCM guarda dos punteros del contenido y un contador del número de componentes que apuntan al mismo contenido. Cuando el primer componente se destruye su apuntador se borra y el apuntador del contador se reduce de dos a uno. Cuando el segundo componente se destruye, el puntero también se borra y como el apuntador del contador se reduce a cero, el contenido también se borra.

Principio de portabilidad

(concepto) Característica no funcional de un sistema de gestión documental que evalúa hasta qué punto se puede poner el sistema en funcionamiento en diferentes plataformas, dispositivos y ambientes operativos.

Roles configurados previamente

(sustantivo) Un rol, como un rol fijo, definido previamente por el proveedor de una solución SDCM para permitir su configuración. A diferencia del rol fijo, un rol configurado previamente que se puede modificar o destruir más adelante. Véase también rol fijo.

Prerrequisito (sustantivo) Módulo que se debe implementar antes de que el módulo designado se pueda poner en práctica. Se utiliza para indicar que un módulo de MoReq2010® que depende de la funcionalidad de otro también puede ser implementado por el SDCM.

Véase también co-requisito, módulo y servicio.Orden de presentación (metadato) Orden en la que deben aparecer los elementos,

establecida por los usuarios, en particular se refiere al orden en que se deben presentar los elementos de metadatos cuando se inspecciona la entidad.

Principio de privacidad

(concepto) Característica no funcional de un sistema de gestión documental, la privacidad tiene que ver con el nivel con que el sistema apoya los principios de protección de la información así como también el manejo de los aspectos de mayor extensión de cualquier tipo de información confidencial.




Proceso (sustantivo) Flujo de trabajo paso a paso descrito por MoReq2010® que debe implementar todas las soluciones SDCM de la misma manera, a fin de que produzca de manera segura los mismos resultados cada vez que se lleve a cabo. Los procesos más importantes descritos por MoReq2010® son el proceso de eliminación y el proceso de exportación.

Producto (sustantivo) Software COTS, por lo general con licencia de un proveedor, que se puede instalar como una aplicación independiente para proveer la implementación de un SDCM.

Propietario (concepto) Implementación que es específica para un producto en particular de un proveedor en particular y es compatible con otras implementaciones de sistemas de gestión documental de otros proveedores. Uno de los principales objetivos del diseño de MoReq2010® es evitar propietarios de sistemas de gestión documental incompatibles que no sean totalmente interoperables. Véase también modelo de metadato nativo y modelo de permisos nativos.

Depurar (verbo) Cuando las entidades se destruyen, automática y selectivamente borra elementos de metadatos predeterminados, así como también, borra eventos de su historial de eventos, con base en las funciones que ellos representan.

Solo de lectura (concepto) Véase modificable.

Reclasificación (funcionamiento) Cambiar la clasificación de una agrupación o documento. La reclasificación se puede dar como resultado de de la anulación de una clasificación por defecto, o, si la agrupación o documento hereda su clase, cosa que puede suceder como resultado de la reclasificación de una entidad padre o antecesor.

Véase también clasificación.

Documento (entidad) Cualquier “información creada, recibida y mantenida como evidencia e información por parte de una organización o persona, en cumplimiento de las obligaciones legales o como producto de las operaciones de la empresa” (ISO 15489-1:2001, 3.15)

En MoReq2010® un documento puede ser mucho más caracterizado, de la siguiente manera:

• Tiene un grupo extensible de metadatos que lo describen;• Tiene uno o más componentes que representan su contenido;• Se clasifica con una clasificación comercial;• Tiene un programa de eliminación que describe explícitamente si, cómo y cuándo será eliminado o destruido;• Pertenece a una agrupación de documentos;




• El acceso a este documento es controlado y limitado por los usuarios autorizados;• Su destrucción se puede prevenir por la retención de la eliminación; y• Se puede exportar a otro SDCM conservando todas las características mencionadas anteriormente.

Contenido del documento

(sustantivo) Véase contenido del componente.

Servicio del documento

(servicio) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo del control de las agrupaciones, documentos y sus componentes.

Gestión documental (concepto) Campo de la gestión responsable del control eficiente y sistemático de la creación, recibo, mantenimiento, uso y eliminación de documentos, incluyendo los procesos de captura y mantenimiento de evidencia de, e información sobre, las actividades y transacciones comerciales en forma de documentos. (Tomado de la Norma ISO 15489-1:2001, 3.16).

Sistema de gestión documental

(sustantivo) Sistema de información que captura, controla y proporcionar acceso a los documentos a través del tiempo. (ISO 15489-1:2001, 3.17).

Sistema de Gestión documental compatible con MoReq2010®

que ofrece la funcionalidad de un sistema de gestión documental de forma estandarizada a través de la implementación de un conjunto de servicios básicos, establecidos por la especificación MoReq2010® , que se puede prorrogar , adaptar y localizar mediante módulos adicionales.

Recuperar (verbo) Enfrentar una falla del sistema o un desastre mediante el reemplazo del hardware and software dañado y la restauración de los daños del sistema para que vuelvan al estado previamente conocido y estable.

Véase también copia de seguridad y recuperar.

Principio de Recuperación

(concepto) Característica no funcional de un sistema de gestión documental que evalúa su capacidad para recuperarse de una falla en el sistema o de un desastre. También se conoce como “recuperación de desastre” y “continuidad del negocio”.



Referencia (sustantivo) En concreto, en el contexto de relaciones entre entidades y el metadato de una entidad, se dice que un elemento de metadato contiene una referencia cuando su propósito es almacenar el sistema identificador único de otra entidad. Las relaciones entre entidades se realizan por medio de una entidad que referencia a otra. Si se autoriza a un usuario para que inspeccione ambas entidades, entonces el SDCM le debe permitir al usuario navegar por la relación, de una a otra, en cualquier dirección. (ambigüedad) MoReq2010® también utiliza el término “referencia”




en su sentido más general. Por ejemplo, la mayoría de los requisitos funcionales tienen una “función referencia” que simplemente es un índice del modelo de información que permite que el lector busque la definición de función que coincida con el requerimiento.

Relación (sustantivo) Véase diagrama de relación de entidad, relación padre/hijo, y en especial referencia.

Puntaje relevante (metadato) Por lo general, el propietario, el valor específico que se le da a la búsqueda completa de un texto que permite más resultados importantes para que se devuelvan primero.

Véase búsqueda completa de un texto.

Principio de confiabilidad

(concepto) Junto con autenticidad, integridad y facilidad de uso, es una de las características básicas de un documento, de acuerdo con la Norma ISO 15489.

“Un documento confiable es aquel a cuyo contenido se le puede dar crédito como una representación completa y exacta de las transacciones, actividades o hechos para los cuales confirmaron…” (ISO 15489-1:2001, 7.2.3)

(uso alterno) Confiabilidad también es una característica no funcional de un sistema de gestión documental, y cuando se usa en este sentido hace referencia a la capacidad de recuperación del sistema en su conjunto, y se mide con frecuencia como “la hora media entre fallas”. Véase también autenticidad, integridad y facilidad de uso.

Retirar (funcionamiento) Función de desvincular una entidad de un grupo de entidades, la mayoría de las veces con el propósito de trasladarla a otro lugar. Por ejemplo, extraer un documento de su agrupación padre para trasladarlo a una nueva agrupación padre.

Véase también, adicionar, asociar y trasladar.



Reporte (sustantivo) Montaje estructurado de información, que utiliza un esquema configurado previamente, en respuesta a una consulta específica o a una consulta más general, tales como consultas de búsqueda. La búsqueda y los reportes son actividades estrechamente relacionadas y algunas veces coinciden. La búsqueda que se hace posterior a un reporte se denomina reporte con fines específicos. De acuerdo con la tradición, un reporte tiene un formato de reporte que le permite ser almacenado como contenido electrónico y potencialmente se declara como un documento en sí. MoReq2010® requiere de un SDCM que pueda proveer reportes específicos, en respuesta a algunos de los requisitos funcionales, y dos tipos de informes generales: un reporte detallado y un reporte resumido.

Véase también reporte detallado y reporte resumido.

(funcionamiento) Función de generar un reporte




Formato de Reporte (sustantivo) Formato común y ampliamente reconocido para un reporte, como:

• Valores separados por comas o por tabuladores;• formatos de hoja de cálculo, como OOXML y ODF;• Formatos XML y HTML; y• Formatos de PDF u otros formatos de documentos.

Véase también formato y reporte.

Requisito (sustantivo) Véase Requisito funcional y requisito no funcional.

Revocar (funcionamiento) Prevenir el uso adicional de un rol asignado previamente a un usuario o grupo de usuarios. Al cancelar el rol se actualizará la lista de control de acceso que pertenece a la entidad o al servicio y a su vez borra y modifica la entrada de control de acceso.

Véase también asignar y rol.

Entidad residual (sustantivo) Entidad que ha sido destruida. Entidad residual que ya no está activa y que al destruirse pudo depurar algunos de sus metadatos y algunos de los eventos de su historial de eventos.

Véase también entidad activa.

Restaurar (verbo) Recuperar un sistema de información a un estado previamente conocido y estable utilizando una copia de seguridad luego de presentarse una falla en el sistema o un desastre.

Véase también copia de seguridad y recuperar.

Retener (verbo) Conservar un documento en el SDCM y garantizar que no se borre o se destruya.

Véase también eliminar.

Mantener en espera (verbo) Retener un documento y prevenir su destrucción durante la duración de la retención de la eliminación.

Véase también Retención de la Eliminación.

Retener de manera permanente

(verbo) Retener un documento de manera indefinida y prevenir su destrucción a menos que o hasta que se determine un programa de eliminación diferente. Véase también acción de eliminación.




Periodo de retención (sustantivo) Periodo de tiempo durante el cual se retiene el documento desde su fecha de inicio de retención, que se inicia con la activación de la retención, hasta el vencimiento de su eliminación, marcando el final del periodo de retención.

Fecha de Inicio de la Retención

(metadato) Fecha en la cual se cumplen las condiciones de la activación de la retención dentro del programa de eliminación de documentos y comienza el periodo de retención.

Activación de la retención

(Sustantivo) Una de las posibles condiciones que puede hacer que comience un periodo de retención de documentos. Cada programa de eliminación incluye una activación de retención. Por ejemplo, la activación de la retención de un documento puede ser la fecha en que se adicionó a su agrupación padre.

Revisar (funcionamiento) Función de evaluar un documento que se vence para revisión y establecer cual va a ser el programa de eliminación que se le aplica. Un usuario autorizado puede terminar la revisión aplicando un nuevo programa de eliminación al documento e ingresando un comentario de revisión describiendo la decisión de la revisión.

Véase también comentario última revisión y última revisión Marca de tiempo

Decisión de la revisión (sustantivo) Decisión tomada cuando la persona que revisa el documento termina la revisión. Véase también eliminación completa y revisión.



Rol (entidad) Entidad que representa un grupo de definición de funciones. Asignarle un rol a un usuario o a un grupo de usuarios en relación con una entidad, permite que el usuario o cualquier miembro de ese grupo desempeñen ese rol en la entidad y sus descendientes. Por lo general los roles se configuran para reflejar las tareas de los miembros del personal que cumplen un cargo particular dentro de la organización. Por ejemplo, se pueden configurar diferentes roles de cada uno de los siguientes cargos.

• Empleado administrativo,• Funcionario local de documentos,• Gerente General de Documentos,• Gerente de Personal,• Representante de Ventas,• Auditor,• Contratista externo,• Visitante o temporal de oficina,• Asistente Ejecutivo de personal,• Director Ejecutivo,• Y así sucesivamente




Véase también rol fijo, asignar, rol pre configurado y cancelar.

Servicio rol (servicio) Servicio separado de una manera lógica dentro de un SDCM responsable desde el punto de vista operacional para el manejo de los roles.

Véase también modelo servicio del rol.

Agrupación raíz (sustantivo) Agrupación que no es hijo de otra agrupación. Cada agrupación raíz se crea directamente en el servicio de documento. Véase agrupación hijo y agrupación padre.

Fila (sustantivo) Cuando los elementos de metadatos o las propiedades de las entidades se organizan en tablas, cada fila de la tabla contiene normalmente el metadato de una sola entidad, mientras que cada columna contiene los valores para cada entidad de un solo elemento de metadato.

Véase también columna y tabla.

Reporte guardado (sustantivo) Reporte donde el SDCM guarda y almacena el formato de reporte y las consultas de búsqueda que se utilizan, para que el reporte guardado se pueda compartir con otros usuarios y se genere de nuevo, como se necesite. Un reporte guardado no es una entidad.

(ambigüedad) “reporte guardado” hace referencia al guardado de la definición del reporte, no a los resultados del reporte.

Búsqueda guardada (sustantivo) Consulta de búsqueda que se guarda para que se pueda compartir con otros usuarios, se pueda correr nuevamente cuando se necesite, y usarlo como base para otras búsquedas. Una búsqueda guardada no es una entidad.

(ambigüedad) Guardar “en cuanto a búsqueda se refiere” es guardar la consulta de búsqueda, no el resultado de la búsqueda.

Principio de ampliación

(concepto) Característica no funcional del sistema de gestión documental que evalúa hasta que punto el sistema puede crecer para soportar una mayor capacidad sin necesidad de reemplazo o reconfiguración amplia. Normalmente los sistemas tienen la necesidad de escalar debido a la expansión de la organización, el aumento de la carga laboral, su uso máximo y/o por la acumulación normal de documentos y entidades relacionadas, con el transcurso del tiempo.




Actividad programada (sustantivo) Proceso planificado o de rutina desarrollado por un sistema de información a intervalos regulares, en particular un recurso de difícil funcionamiento que se programa para una hora del día o de la semana cuando el uso normal del sistema es bajo.

Véase también actividad.

Notas de alcance (metadato) Notas de orientación que indican la mejor manera de aplicar una entidad particular y estipula las políticas y restricciones organizacionales sobre su uso. Por ejemplo, una clase puede tener notas de alcance que indican cuales agrupaciones y documentos de clase se deben aplicar y cuales agrupaciones y documentos son incompatibles para la clasificación dentro de esa clase. Las notas de alcance se pueden dar a las agrupaciones, clases, retención de eliminaciones, programa de eliminación y elementos contextuales de metadatos.

Búsqueda (funcionamiento) Descubrir entidades mediante criterios de búsqueda específicos que coincidan parcial o totalmente con los valores de sus elementos de metadatos.

Véase también búsqueda compleja y búsqueda de texto completo

Motores de búsqueda (sustantivo) Punto central del servicio de reporte y búsqueda de la solución SDCM. El motor de búsqueda normalmente clasifica el metadato en el SDCM, aplica el criterio de búsqueda, ejecuta y evalúa la búsqueda, y reúne y ordena los resultados de búsqueda. Los diferentes motores de búsqueda pueden ser más o menos sofisticados de acuerdo a la funcionalidad que ofrecen. Como muchas veces los motores de búsqueda son altamente especializados, como las bases de datos, algunos proveedores hacen uso de motores de búsqueda de terceros para sus soluciones SDCM.

Criterios de búsqueda (sustantivo) Condiciones individuales incluidas en las consultas de búsqueda. Cada consulta de búsqueda estará compuesta por uno o más criterios de búsqueda. Cada criterio de búsqueda está compuesto de elementos de metadatos para búsqueda, operadores de búsqueda y términos de búsqueda.

Descripción de búsqueda

(metadato) Descripción de una consulta de búsqueda que se incluye en un evento con el fin de retener la evidencia de la búsqueda que se llevó a cabo. La descripción de la búsqueda puede ser en un lenguaje natural o en un lenguaje de expresión estructurado.

Véase también comentario de evento.



Consulta de búsqueda (sustantivo) Consulta compuesta de uno o más criterios de búsqueda que el usuario configura para realizar una búsqueda.




Resultados de búsqueda

(sustantivo) Resultados de búsqueda expresados en una lista ordenada de entidades y sus metadatos.

Véase también paginación.

Términos de búsqueda (sustantivo) Parte de un criterio de búsqueda que contiene un valor que se puede comparar o buscar.

Servicio de reportes y de búsqueda

(servicio) Servicio separado de manera lógica dentro de un SDCM que es, o que está integrado con, un motor de búsqueda, desempeña búsquedas y genera reportes a los usuarios autorizados.

Véase también modelo servicio del rol.Protección (concepto) Una unidad de información es segura solo cuando los

usuarios autorizados tienen acceso a ella y la pueden manipular. En un SDCM, la seguridad interna la suministran los controles de acceso, mientras que la seguridad externa se evalúa de acuerdo al principio de seguridad no funcional.

Véase también anominato.

Principio de Seguridad

(concepto) Característica no funcional de un sistema de gestión documental que hace referencia a, y que mide su integridad y su capacidad para soportar el acceso no autorizado.

Sentencia sobre la creación

(concepto) Principio general que estipula que el contexto de un documento se captura mejor, cuando se crea el documento por primera vez, y que este contexto se debe utilizar para regir la eliminación del documento. En MoReq2010®, el principio de “sentencia sobre la creación” está caracterizado por la funcionalidad requerida del SDCM, donde cada registro que se crea se debe clasificar y cada clase tiene un programa de eliminación por defecto, asociado con este.

Servicio (sustantivo) Subconjunto lógico de la funcionalidad total de un SDCM que se enfoca solo en el control de una entidad o de un pequeño grupo de tipos de entidades. Por ejemplo, el servicio de programa de eliminación solo controla los programas de eliminación.

Véase también servicio de clasificación, servicio de retención de eliminación, servicio de programación de eliminación, servicio de metadatos, servicio del modelo de metadato, modelo servicio del rol, Servicio de búsqueda y reportes, servicio con base en la arquitectura, servicio de rol y servicio al usuario y al grupo de usuarios.




Servicio con base en la arquitectura

(concepto) Arquitectura adoptada dentro de la especificación en la que los requisitos funcionales dentro del núcleo del MoReq2010® están separados en servicios discretos. Cada servicio representa un grupo de funciones que teóricamente podrían ser llevadas a cabo por una aplicación separada. Dividir el núcleo de esta manera ayuda a presentar los conceptos importantes en orden lógico, aunque esto también apunta hacia el futuro en donde un SDCM puede tener dos servicios del mismo tipo, como por ejemplo dos servicios de clasificación diferentes para diferentes tipos de documentos o agrupaciones, o puede compartir un servicio, como su servicio de metadatos, con otro SDCM.

Identificador de servicio

(metadato) Identificador único universal proporcionado por DLM Forum® que se utiliza en los reportes de cumplimiento por un SDCM para indicar que se implementa un mejor versión particular de un servicio básico de MoReq2010®.

Véase también modulo, identificador del sistema y versión.

Configurar (funcionamiento) Cuando se utiliza junto con una bandera o un valor booleano, es decir, para asignarle el valor “verdadero”.

(ambigüedad) MoReq2010® también utiliza el término “conjunto” como un nombre colectivo para hacer referencia a agrupaciones de entidades.

Véase también bandera.Entidades importantes (concepto) Entidad que es especialmente importante para otra

entidad y por lo tanto siempre se debe exportar con está como un placeholder (marcador de posición), siempre que se exporte. Por ejemplo, la clase de un documento es una entidad importante para el documento. El documento no se puede exportar en su totalidad o como un placeholder sin que se exporte su clase también como un placeholder.

Imagen instantánea (sustantivo) Representación de cualquier dato o unidad de información, pero sobre todo una entidad activa y sus metadatos, congelada en un momento de tiempo determinado.

Solución (sustantivo) Véase implementación.

Fluir (verbo) Véase flujo progresivo de datos XML.

Subtipo (sustantivo) Véase subtipo de entidad.



Reporte resumen (Sustantivo) reporte con base en estadísticas más que en elementos de línea individuales.

Véase también reporte y reporte detallado.




Proveedor (sustantivo) Fabricante o productor de un sistema de gestión documental, o una institución que posee algunos o todos los derechos de propiedad intelectual, o un representante del proveedor, como un distribuidor o integrador de servicios

Principio de soporte al sistema

(concepto) Característica no funcional de un sistema de gestión documental; un sistema de apoyo es aquel que está siendo actualizado y mejorado por el proveedor y para el que existe un mecanismo de apoyo operativo para la emisión de reportes y para recibir información sobre nuevas versiones y soluciones de software.

Sistema (sustantivo) Véase sistema de información.

Identificador del Sistema

(metadato) Identificador único universal generado por el sistema para una entidad o para otros propósitos, como un identificador de exportación. Algunos sistemas identificadores son suministrados por MoReq2010®, incluyendo identificadores de servicios, identificadores de módulos, identificadores de tipos de entidad, identificadores de estructura de datos, identificadores de la definición del sistema de elemento de metadatos, e identificadores de la definición de función.

Sistema de metadatos (sustantivo) Metadato que es de carácter de MoReq2010® y está definido previamente por la especificación que incluye las definiciones del sistema de elemento de metadatos y sus identificadores del sistema. Cada tipo de entidad tiene su propio grupo de sistema de metadatos asociados a ella.

Definición del sistema de elemento de metadatos

(entidad) Definición del elemento de metadatos para un sistema de elementos de metadatos.

Todas las definiciones del sistema de elementos de metadatos se presentan como parte del modelo de información del MoReq2010® que incluye el sistema identificador único para cada uno. Por ejemplo, el identificador del sistema para el sistema del elemento de metadatos “Título” es 077fc367-48ba-44a8-8afb-012d05ed1a16”.

Tabla (sustantivo) Diseño real o conceptual de los metadatos de entidades en filas y columnas. Este diseño tiene más éxito cuando todas las entidades en una tabla tienen los mismos elementos de metadatos o propiedades, que por lo general significa que son del mismo tipo de entidad.

Véase también columna, base de datos y fila.



Administración técnica

(concepto) Véase administrador




Plantilla (entidad) Representación de un grupo de definiciones de elementos de metadatos contextuales que se pueden aplicar a una entidad. Siempre que se aplica la plantilla, cada uno de los elementos de metadatos contextuales se ejemplifica y se asocia con la entidad.

Véase también plantilla por defecto y definición de elemento de metadato contextual.

Prueba (verbo) Actividad para comprobar la exactitud del software por medio de la realización de funciones y comparando los resultados con los resultados esperados. En concreto para MoReq2010®, quiere decir una prueba formal al sistema de gestión documental contra los requisitos funcionales utilizando el esquema de pruebas de MoReq2010®

Véase también certificación.

Texto (tipo de dato) Información que se transmite utilizando caracteres y que normalmente se expresa por medio de palabras delimitadas por espacios y signos de puntuación. Todos los textos en MRS deben utilizar el grupo de caracteres Unicode.

Véase también Unicode.

Textual (adjetivo) Descriptor de un elemento de metadato con base en un texto que se espera que contenga un valor expresado en un lenguaje específico. La información no puede estar al alcance de un usuario que no entienda este lenguaje. Además, el lenguaje de un valor textual puede modificar la forma en que se procesa automáticamente. Por ejemplo, puede estar clasificada de forma diferente por el motor de búsqueda, organizada en un orden diferente en una lista, o representada utilizando diferentes estilos o tipos de letras.

Véase también Identificador de lenguaje.

Título (metadato) Nombre o identificación obligatoria de un texto para una entidad. Por lo general es más corto que una descripción completa. En MoReq2010® no se necesita que los títulos de las entidades sean únicos, inclusive para los documentos dentro de la misma agrupación, aunque se considera que es una buena practica.

Véase también descripción.



Zona horaria (metadato) Desplazamiento entre las dimensiones del tiempo a nivel local y el UTC (Tiempo Universal Coordinado). La información de la zona horaria se debe incorporar en todas las marcas de tiempo generadas por un SDCM para evitar la presencia de eventos que ocurran fuera de secuencia. Esto es particularmente necesario para apoyar la interoperabilidad.

Véase también Marca de Tiempo.




Marca de tiempo. (sustantivo) Valor generado por un sistema de alta precisión para el tiempo en que ocurre un evento u otra operación importante. Las marcas de tiempo deben incluir la fecha, hora y zona horaria completa y debe ser precisa al menos en un segundo, y debe buscar ser más exacto aún, como por ejemplo, con una precisión de milésimas de segundo.

Véase también Marcas de tiempo usadas por primera vez, última revisión de las marcas de tiempo, y zona horaria.

Transacción (sustantivo) Operación llevada a cabo por un sistema comercial que se almacena en un registro de transacción de manera que se pueda repetir en caso de que sea necesario restablecer el sistema después de un desastre. El usuario de las transacciones debe garantizar que se pierda la menor información posible si el sistema falla, de manera que el registro de la transacción se pueda usar para trasladarlo de la última copia de seguridad al momento inmediatamente anterior al desastre. (ambigüedad) El tipo de transacción descrito anteriormente no se debe confundir con una transacción comercial.

Véase transacción comercial.

Transferencia (funcionamiento) Acción de eliminación en la que los documentos son trasladados a un lugar de almacenamiento o de archivo secundario. Por lo tanto, la transferencia normalmente implica exportar e importar, seguida por la destrucción de los documentos en el sistema de origen. Se debe confirmar el éxito de la transferencia antes de que los registros sean destruidos en el SDCM de origen. La transferencia también se puede enviar como migración, especialmente si todas, o un número representativo de entidades en un SDCM, o en un servicio, se están transfiriendo.

Véase también acción de eliminación, confirmación de eliminación, exportar, importar y migración.

Árbol (sustantivo) Estructura jerárquica.

Véase también Jerárquico.

Unicode (sustantivo) El estándar Unicode establece la codificación de caracteres estandarizados y las normas de procedimiento para los textos en todos los idiomas europeos y todos los lenguajes humanos.



Identificador uniforme de recursos

(sustantivo) Identificador uniforme de recursos, o URI, se utiliza para identificar y localizar un recurso, como un archivo de datos, en Internet. Los identificadores uniformes de recursos se puedan extender para identificar recursos en otros lugares, como en el sistema operativo local.




Identificador único universal

(sustantivo) Número de identificación compuesto de 128 bits y descrito comúnmente como un UUID. Si se genera utilizando un algoritmo adecuado, solo hay una pequeña probabilidad de que cualquiera de los dos valores UUID vuelvan a ser el mismo, incluso entre los miles de millones de entidades. Los UUID son invaluables en su ahoyo para la interoperabilidad porque permiten que los identificadores del sistema sean intercambiados entre diferentes generadores de sistemas de información.

Los algoritmos adecuados para la generación de UUIDs se pueden encontrar en RFC4122, y estos inclusive pueden soportar “índices de alta asignación de hasta 10 millones por segundo por cada máquina” (RFC4122:2005, 2.).

Principio de facilidad de uso

(concepto) Junto con autenticidad, integridad y confiabilidad, es una de las características básica de un documento de acuerdo con la Norma ISO 15489.

“Un documento útil es aquel que se puede localizar, recuperar e interpretar” (ISO 15489-1:2001, 7.2.5)

(uso alternativo) La facilidad de uso también es una característica no funcional de un sistema de gestión documental, y cuando se usa en este sentido se refiere al sistema como un todo y a la calidad de la experiencia del usuario, incluyendo lo difícil que es aprender y su facilidad de funcionamiento para el uso día a día.

Véase también autenticidad, integridad y confiabilidad

Usuario (entidad) Persona o sistema con una cuenta que le permite tener acceso a y utilizar un SDCM. El usuario no tiene que ser un humano y podrías ser otro sistema comercial. Los usuarios deben estar autentificados antes de que puedan usar un SDCM.

Servicio de usuarios y grupo de usuarios

(entidad) Servicio separado de manera lógica dentro de un SDCM responsable desde el punto de vista operativo del control de los usuarios y de los grupos de usuarios. El servicio de usuarios y grupo de usuarios se pueden integrar con o contener la portada de un directorio.

UUID (sigla) Identificador único universal.

URI (sigla) Identificador Uniforme de Recursos.



Valor (sustantivo) Información ubicada en un elemento de metadato. Los valores deben cumplir de manera estricta con el tipo de dato descrito por la definición del elemento de metadato correspondiente.

Véase también código, tipo de dato y valor por defecto.




Versión (sustantivo) Cada servicio y cada modulo de MoReq2010® tiene un número de versión, integrada por una versión mayor y una versión menor. La versión menor representa un cambio en el servicio o módulo que presenta una aclaración, corrección o un requisito no funcional adicional sin necesidad de cambiar el modelo de información básica. Por lo tanto, todas las implementaciones que se hagan con la misma versión mayor deben ser compatibles entre sí, inclusive si sus versiones menores son diferentes. La versión mayor representa un cambio en el modelo de información, como la adición de nuevas funciones o elementos del sistema de metadatos, que hace que un SDCM que solo implementa una versión mayor, sea incompatible con una SDCM que solo implementa otras versiones. MoReq2010® proporciona identificadores de servicio, y los identificadores de módulos solo son reemplazados cuando cambian los números de la versión mayor

Véase también versión mayor y versión menor.Principio de sistema garantizado

(concepto) Característica no funcional de un sistema de gestión documental, un sistema de garantía es aquel que emite una garantía del proveedor para cubrir su uso.

Navegador de la web (sustantivo) Aplicación que se usa para visitar un sitio web y para cargar y ver páginas web.

(ambigüedad) Los términos navegar e inspeccionar tienen un significado especial en MoReq2010® que no se debe confundir con el uso de una navegador de la web.

XML (sigla) Lenguaje extensible de Marcas, formato de documento para expresar información en un texto legible por máquina, en donde los elementos y las entidades se identifican por las marcas insertadas en el texto.

Datos XML (sustantivo) Datos que representan entidades que son formateados en el formato de exportación de datos usados por MoReq2010® para transferencias, incluida la migración.

Flujo progresivo de datos XML

(verbo) Datos XML transmitidos vía electrónica como una transmisión continua, o una serie de paquete de datos.

Transformación XML (verbo) Manipulación de datos XML para que lo represente en un formato XML alterno, o como otra clase de datos.



14.5 Definiciones Funcionales

F14.5.1 Agrupación – Agregar Agrupación


f6c7d6a4-c69e-4d33-9d4a-4137274b68da

Título/Nombre Agrupación – Agregar Agrupación

Descripción Añada una agrupación hijo a la agrupación abierta moviéndola desde la raíz o desde su padre anterior

Tipo de Entidad Agrupación (E14.2.1)

Metadatos de la entidad

El siguiente elemento de metadatos perteneciente a la agrupación, será modificado:

• Fecha/Hora de Última Adición (M14.4.48)

El siguiente elemento de metadatos perteneciente a la agrupación,también podrá ser modificado (si no se ha fijado previamente):

• Fecha/Hora Usada Inicialmente (M14.4.32)

Los siguientes elementos de metadatos pertenecientes a la agrupación hijo participante serán modificados:

• Identificador de Agrupación Padre (M14.4.63)• Fecha/Hora Agrupada (M14.4.1)

El siguiente elemento de metadatos perteneciente a la agrupación hijo participante será eliminada (si es que existe):

• Niveles Máximos de Agrupación (M14.4.52)

Requerimientos funcionales

R6.5.8, R6.5.14

Objetivo • Control de acceso• Generación del evento

Metadatos adicionales del evento (ver R2.4.16)

• Identificador Padre Participante Anterior (M14.4.76)• Identificador Padre Participante Nuevo (M14.4.75)• Identificador de Agrupación Participante (M14.4.64)• Comentarios del Evento (M14.4.25)

Notas de uso • Esta función siempre se realiza en conjunto con la F14.5.22Agrupación – Eliminar Agrupación

• Antes de que un usuario pueda mover una agrupación, el usuario debe primero tener la autoridad para realizar dicha función sobre su nuevo padre, así como la autoridad de eliminar la agrupación de su padre o raíz anterior.• Para mover una agrupación de modo que se convierta en una agrupación raíz, el usuario debe tener la autoridad para realizar esta función, para el servicio de registro como unidad global.

as a whole



• Esta función solo aplica para las agrupaciones hijo añadidas al moverlas de otro origen, no aplica para la adición de agrupaciones hijo creadas en la agrupación (ver F14.5.5 Crear agrupación)

F14.5.2 Agrupación – Añadir Metadatos de Contexto


746b7ffc-d9a4-43d9-9dfa-01f6d1e8f671

Título/Nombre Agrupación – Añadir metadatos contextuales

Descripción Añada uno o más definiciones de elementos de metadatos contextuales a la agrupación



• Elementos de metadatos de contexto adicionales, según se especifica

El aplicar los elementos de metadatos contextuales desde una plantilla también puede modificar el siguiente elemento de metadatos de la plantilla (si no se ha fijado previamente):


Requerimientos funcionles

R7.5.19



• Identificador de Agrupación Participante (M14.4.64)• Comentario del Evento (M14.4.25)• Ingreso de Cambio de Metadatos (D14.3.3)• Identificador de Plantilla Aplicado (M14.4.2)

Notas de Uso Si los elementos de metadatos contextuales son añadidos desde una plantilla entonces el Identificador de Plantillas Aplicado debe ser incluido en los metadatos del evento (la plantilla no se considera como una entidad participante)

F14.5.3 Agrupación – Añadir Registro


0ef1d20b-a65f-4b0a-b2a0-e7b3a9a665f4

Título/Nombre Agrupación – Añadir Registro

Descripción Añada un registro a la agrupación abierta, moviéndola desde la agrupación anterior.





Los siguientes elementos de metadatos pertenecientes a la agrupación serán modificados:

• Ultima Fecha/Hora Agregada (M14.4.48)

Los siguientes elementos de metadatos pertenecientes a la agrupación también pueden ser modificados (si no se han fijado previamente):

• Primera Fecha/Hora Utilizada (M14.4.32)

Los siguientes elementos de metadatos pertenecientes al registro serán modificados:

• Identificación de Agrupación Padre (M14.4.63)• Fecha/Hora Agrupada (M14.4.1)

Los siguientes elementos de metadatos pertenecientes al registro podrán ser modificados dependiendo de si el usuario autorizado decide retener o reemplazar la clasificación de los registros previos, según R6.5.13:

• Class Identifier (M14.4.4)Requerimientos funcionles

R6.5.13, R6.5.14

Objetivo • Control de Acceso• Generación de evento


• Identificador Padre Participante Anterior (M14.4.76)• Identificador Padre Participante Nuevo(M14.4.75)• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio de Metadatos (D14.3.3)

Notas de uso • Esta función siempre se realiza en conjunto con la F14.5.22Agrupación – Eliminar Registro

• Antes de que un usuario pueda mover un registro, el usuario debe tener la autoridad para realizar esta función en la nueva agrupación padre, así como la autoridad para eliminar el registro de la agrupación padre anterior• Esta función solo aplica a los registros añadidos a una nueva agrupación padre, moviéndolos desde su anterior agrupación padre, no aplica para los registros añadidos mediante su creación en la agrupación

(ver F14.5.121 Registro - Crear)

F14.5.4 Agrupación – Cerrar


09fb9edc-d179-49dc-b069-a435f162e6fd

Título/Nombre Agrupación – Cerrar

Descripción Cierre la Agrupación Activa





• Fecha/Hora Cerrada (M14.4.5)


R6.5.6

Objetivo • Control de Acceso• Generación del evento


• Identificador de la Agrupación Participante (M14.4.64)• Comentarios del Evento (M14.4.25)

Notas de uso El cerrar una agrupación puede resultar en su destrucción automática si todos sus contenidos han sido destruidos previamente. (ver R8.4.21 y Agrupación F14.5.9 – Destruir)

F14.5.5 Agrupación – Crear


6054ae16-2036-424e-9bb7-aedb6e8229cc

Título/Nombre Agrupación – Crear

Descripción Cree una Agrupación





• Identificador del Sistema (M14.4.100)• Fecha/Hora Creada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Identificador de Clase (M14.4.4)• Título (M14.4.104)• Descripción (M14.4.16)• Notas Sobre el Alcance (M14.4.97)• Fecha/Hora Cerrada (M14.4.5)• Máximos Niveles de Agrupación (M14.4.52)• Identificador de Agrupación Padre (M14.4.63)• Fecha/Hora Agrupación (M14.4.1)• Elementos de Metadatos Contextuales

Si la agrupación se genera en una agrupación padre entonces los siguientes elementos de metadatos pertenecientes a la agrupacion padre serán modificados:

• Fecha/Hora Última Adición (M14.4.48)

El siguiente elemento de metadatos perteneciente a la agrupación padre, también podrá ser modificado (si no se ha fijado previamente): • Fecha/ Hora Usada Inicialmente (M14.4.32)

Si los elementos de metadatos contextuales son aplicados a partir de una plantilla, los siguientes elementos de metadatos de la plantilla pueden ser modificados (si no han sido establecidos ya):

• Fecha/ Hora Usada Inicialmente (M14.4.32)Requerimientos funcionles

R2.4.25, R6.5.1, R6.5.2, R7.5.18

Objetivo • Control de Acceso• Generación del Evento


• Identificador de Agrupación Participante (M14.4.64)• Identificador Padre Participante Nuevo (M14.4.75)• Comentario del Evento (M14.4.25)• Ingreso de Cambios en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)



Notas de uso • La agrupación puede ser generada cerrada mediante una Fecha/Hora Cerrada• Las agrupaciones raíz (sin padre) deben tener un Identificador de Clase • Solo las agrupaciones raíz pueden tener Niveles Máximos de Agrupación• Solo las agrupaciones hijo tienen identificadores de Agrupación Padre y un Tiempo Hora de Agrupación; el evento generado también incluirá un Identificador de Agrupación del Padre Participante y aparecerá en el historial de eventos de tanto la agrupación siendo generada como la Agrupación Padre • La agrupación puede ser generada con elementos de metadatos contextuales así como con los elementos de metadatos del sistema enumerados.• Si los elementos de metadatos contextuales son agregados a partir de una plantilla entonces un Identificador de Plantilla Aplicada debe ser incluido en los Metadatos del Evento.• Para cada elemento de metadatos fijado al momento de generación, excepto para el Identificador de Sistema y la Fecha/Hora generada, se debe añadir un Ingreso de Cambio en Metadatos para el evento correspondiente.

F14.5.6 Agrupación – Eliminar


ae8dd3fe-3e02-4aa5-b9d0-840e0ea5b68b

Título/Nombre Agrupación – Eliminar

Descripción Elimine la Agrupación no utilizada



La Agrupación no utilizada se elimina junto con su historial de evento


R6.5.7

Objetivo Control de Acceso Únicamente

Metadatos adicionales del

No se genera evento

Notas de uso

F14.5.7 Agrupación – Eliminar Evento Residual


bff0f6be-8b87-454e-b4a9-a8ca584e574b

Título/Nombre Agrupación – Eliminar Evento Residual

Descripción Elimine el evento del historial de eventos de la agrupación residual





• No se modifican elementos de metadatos• Se elimina la entidad del evento


R2.4.21



• Identificador de Agrupación Participante (M14.4.64)• Identificador de Definición de la Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)

Notas de uso Esta función siempre genera un evento (ver R2.4.14)

F14.5.8 Agrupación - Eliminar Metadatos Residuales


8e6f41c0-fe66-4147-865b-7c3fd0d3b3aa

Título/Nombre Agrupación – Eliminar Metadatos Residuales

Descripción Elimine el elemento de los metadatos de la agrupacion residual



Cualquier elemento de metadatos puede ser eliminado incluyendo tanto elementos de metadatos del sistema como contextuales, excepto un identificador de sistema o una fecha/hora


R7.5.7



• Identificador de Agrupación Participante (M14.4.64)• Identificador de Definición de la Función de Evento Eliminado (M14.4.15)• Comentario del Evento (M14.4.25)




F14.5.9 Agrupación - Destruir


60aa99a4-cf98-4e03-b64d-1fd137e90296

Título/Nombre Agrupación - Destruir

Descripción Destruya la Agrupación



• Fecha/Hora Destruida (M14.4.17)


R6.5.6, R8.4.22

Objetivo Generación de Evento únicamente


• Identificador de Agrupación Participante (M14.4.64)• Identificador de Definición del Elemento de Metadatos Eliminado (M14.4.15)• Identificador de Definición del Elemento de Función del Evento Eliminado (M14.4.14)

Notas de uso • Esta función se realiza automáticamente por el SDCM cuando la agrupación se cierra, bajo R6.5.6, y todos sus hijos han sido previamente destruidos según R8.4.22

• El Identificador de Definición de Elementos de Metadatos Eliminado y el Identificador de Definición de la Función de Evento Eliminado son utilizados para mostrar qué elementos de los metadatos y cuales tipos de eventos fueron sustraídos del historial de eventos de la agrupación al momento de ser destruidos según R2.4.20 y R7.5.6

F14.5.10 Agrupación - Exportada


3f124e3f-64e8-4627-ac32-d1aa7b95ffa9

Título/Nombre Agrupación – Exportada

Descripción La Agrupación ha sido exportada por completo o como placeholders



No se modifican elementos de metadatos


R11.4.10

Objetivo Generación de Evento Únicamente




• Identificador de Agrupación Participante (M14.4.64)• Identificador de Exportación (M14.4.30)• Exportado en Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función se realiza automáticamente por los SDCM como resultado del proceso de exportación (ver F14.5.185 Usuario - Exportación) para todas las entidades que sean exportadas cuandoquiera que un usuario lleve a cabo una exportación según R11.4.1

• El Identificador de Exportación es el identificador del sistema generado por el SDCM para la exportación, según R11.4.4• El Exportado en Bandera Completa debe ser configurado si la entidad fue exportada por completo y aclarado si la entidad fue exportada como placeholders• El Comentario del Evento contiene el comentario de exportación bajo R11.4.5

F14.5.11 Agrupación – Clase de Defecto Heredado


d54f1e11-36c9-451e-abff-9cfa6b7b28e7

Título/Nombre Agrupación – Clase de Defecto Heredado

Descripción Hereda la clasificación por defecto de la agrupación padre



• Identificador de Clase (M14.4.4)


R6.5.4, R6.5.14

Objetivo • Control de Acceso• Generación de Evento


• Identificador de Agrupación Participante (M14.4.64)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Esta función solo puede ser realizada por agrupaciones hijo donde la clase de defecto haya sido contrarrrestada (ver F14.5.20 Agrupación – Clase de Contrarrestado)

• El realizar esta función elimina el Identificador de Clase de la Agrupación hijo, asegurando que herede la clasificación del padre



F14.5.12 Agrupación - Inspección


f607266f-e7fd-4bba-bbd3-462772c1d653

Título/Nombre Agrupación – Inspección

Descripción Busca la agrupación, o la descubre revisando e inspecciona sus metadatos





R6.5.9, R6.5.17, R9.4.7



• Identificador de Agrupación Participante (M14.4.64)

Notas de uso Un evento solo debe generarse para esta función cuando el usuario examina los metadatos de la agrupación y no cuando se identifica al buscar o se incluya en los resultados de búsqueda

F14.5.13 Agrupación - Inspeccionar ACL


c1de7c62-b4be-4622-99f5-f78ee88f41da

Título/Nombre Agrupación – Inspeccionar ACL

Descripción Inspecciona la lista de control de acceso de la agrupación





R4.5.9



• Identificador de Agrupación Participante (M14.4.64)



F14.5.14 Agrupación – Inspeccionar Evento


db9c7774-0799-45e0-999e-0018cbd71e97

Título/Nombre Agruación – Inspeccinar Evento

Descripción Revise el historial de eventos de la agrupación e inspecciones sus eventos





R2.4.19



• Identificador de Agrupación Participante (M14.4.64)• Identificador de Evento Participante (M14.4.71)

F14.5.15 Agrupación – Modificar ACL


2b8f6950-8dce-41ba-aec3-a3b8181a4739

Título/Nombre Agrupación – Modificar ACL

Descripción Modifica la lista control de acceso de la agrupación



• Bandera de Incluir Roles Heredados (M14.4.43)• Ingreso de Control de Acceso (D14.3.1)


R4.5.10



• Identificador de Agrupación Participante (M14.4.64)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)



Notas de uso • Si el valor de la Bandera de Incluir Roles Heredados es modificado entonces el Ingreso de Cambios en Metadatos debe ser adicionado al evento correspondiente• El Usuario Participante o el Identificador de Grupo se refiere al

Usuario o Grupo asociado con el ingreso de control de acceso• Si se modifica simultáneamente más de un control de acceso que

pertenezca a la agrupación entonces se debe generar un evento por cada ingreso de control de acceso.

• Los metadatos del evento muestran cuales roles se otorgaron al usuario o grupo participante y cuales roles existentes fueron anulados mediante la adición, modificación y eliminación de entradas de control de acceso

F14.5.16 Agrupación – Modificar los Niveles Máximos de Agrupación


148427cb-6e55-498d-8352-c13729ad09c5

Título/Nombre Agrupación – Modificar los Niveles Máximos de Agrupación

Descripción Modificar al numero máximode niveles de agrupación que se permiten por agrupación raiz



• Niveles máximos de agrupación (M14.4.52)


R6.5.5




Notas de uso Todas las agrupaciones raíz pueden tener Niveles Máximos de Agrupación



F14.5.17 Agrupación – Modificar Metadatos


d4104970-759a-45fc-aa83-43ca632a2307

Título/Nombre Agrupación – Modificar Metadatos

Descripción Modifica los metadatos de la agrupación activa



• Título (M14.4.104)• Descripción (M14.4.16)• Notas del Alcance (M14.4.97)• Elementos de Metadatos Contextuales


R6.5.3




Notas de uso • Cualquiera de los elementos de los metadatos del sistema enumerados pueden ser modificados asi como cualquier elemento de metadatos contextuales modificables que pertenezcan a la agrupación

• Por cada elemento de metadatos modificado se debe agregar un Igreso de Cambios a Metadatos al evento mediante la realización de esta función

F14.5.18 Agrupación – Modificar Fecha/hora Originada


3ed4bcd1-ae2f-4c34-a0e1-5ddde22d1453

Título/Nombre Agrupación – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora originada de la agrupación activa



• Fecha/Hora Originada (M14.4.61)


R2.4.26





• Identificador de Agrupación Participante (M14.4.64)• Comentario del Evento t (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso El evento para esta función debe tener un Comentario de Evento (ver R2.4.26)

F14.5.19 Agrupación - Abrir


7c533508-1967-401c-9aa4-a6ad85fb63d5

Título/Nombre Agrupación – Abrir

Descripción Abre la agrupación activa cerrada previamente



• Tiempo/Hora Cerrado (M14.4.5)


R6.5.6



• Identificador de Agrupación Participante (M14.4.64)• Comentario del Evento (M14.4.25)

Notas de uso Abrir una agrupacion elimina el Tiempo/Hora cerrado

F14.5.20 Agrupación – Contrarrestar Clase


a938c62a-6dff-4f7f-9490-9780cfc74f8b

Título/Nombre Agrupación – Contrarrestar Clase

Descripción Contrarresta la clasificación previa de la agrupación



• Identificador de Clase (M14.4.4)


R5.4.8, R6.5.4, R6.5.14






Notas de uso El realizar esta función añade un Identificador de Clase a la Agrupación o lo reemplaza si la Agrupación ya cuenta con un Identificador de Clase

F14.5.21 Agrupación – Remover Agrupación


41388b8a-b380-4997-8925-9f678c1655fc

Título/Nombre Agrupación – Remover Agrupación

Descripción Remover una agrupación hijo de la agrupación, moviendola a la raíz o a otro padre



Ver funciones relacionadas F14.5.1 Agrupación – Añadir Agrupación


R6.5.8

Objetivo Acceso de control únicamente

Notas de uso • Antes de que un usuario pueda mover una agrupación hijo por fuera de la agrupación, el usuario debe tener la autoridad para realizar dicha función asi como la autoridad para adicionar una agrupación al nuevo padre o raíz

• Para eliminar una agrupación raíz y darle un padre,el usuario debe tener la autoridad para realizar esta función para el servicio de registro entero como tal• Esta función siempre se realiza de manera conjunta con la F14.5.1

Agrupación – Añadir Registro, la cual describe los metadatos modificados asi como el evento generado

• Esta función no modifica los metadatos de forma separada ni genera un evento

F14.5.22 Agrupación – Remover Registros


d7d6dc0f-3d13-4f98-8fd5-b2ad9163d2cc

Título/Nombre Agrupación – Remover Registros

Descripción Remueve un registro de la agrupación, moviendolo a una agrupación padre diferente





Ver función relacionada F14.5.3 Agrupación – Añadir Registro


R6.5.8

Objetivo Control de acceso únicamente

Notas de uso • Antes de que un usuario pueda mover un registro por fuera de la agrupación, el usuario debe tener la autoridad para realizar esta función asi como la autoridad para añadir un registro a la nueva agrupacion padre

• Esta función siempre se lleva a cabo de manera conjunta con la F14.5.3Agrupación – Añadir Registro, la cual describe los metadatos modificados y el evento generados

• Esta función no modifica los metadatos de manera separada ni genera un evento

F14.5.23 Clase – Añadir Metadatos Contextuales


5e4be488-5911-4fee-bb5b-bbc1e76bf8d4

Título/Nombre Clase – Añadir Metadatos Contextuales

Descripción Adiciona a la clase una o más definiciones de elementos de metadatos contextuales

Tipo de Entidad Clase (E14.2.2)


• Elementos de metadatos contextuales adicionales, según se especifica

El aplicar elementos de metadatos contextuales de una plantilla tambien puede modificar el siguiente elemento de metadatos de la plantilla (si no se ha establecido ya):

• Fecha/Hora usada inicialmente (M14.4.32)


R7.5.19



• Identificador de Agrupación Participante (M14.4.65)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)



Notas de uso Si los elementos de metadatos contextuales se añaden desde una plantilla entonces el Identificador de Plantilla Aplicado debe incluirse en los metadatos del evento (la plantilla no se considera como una entidad participante)

F14.5.24 Clase- Creación


c4285bfb-b62b-403c-9078-49522d881a85

Título/Nombre Clase – Creación

Descripción Crear una Clase



• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Notas Sobre el Alcance (M14.4.97)• Identificador de Cronograma de Eliminación por Defecto (M14.4.11)• Elementos de metadatos contextuales

El aplicar los elementos de metadatos contextuales desde una plantilla tambien puede modificar el siguiente elemento de metadatos de la plantilla (si no se ha fijado previamente):



R2.4.25, R5.4.2, R7.5.18



• Identificador de Clase Participante (M14.4.65)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)



Notas de uso • La entidad de la clase puede ser creada con elementos de metadatos contextuales asi como con los elementos de metadatos del sistema enumnerados

• Si los elementos de metadatos contextuales son agregados a partir de una plantilla entonces un Identificador de Plantilla Aplicada debe ser incluido en los metadatos del evento.• Para cada elemento de metadatos fijado al momento de generación,

excepto para el Identificador de Sistema y Fecha/Hora generada, se debe añadir un Ingreso de Cambio en Metadatos para el evento correspondiente.

• Cuando los controles de acceso heredados sean modificados al crearse, entonces se deben generar eventos separados Clase F14.5.33 – Modifique ACL para cada cambio que se realice a la lista de control de acceso.

F14.5.25 Clase – Eliminar


f6134d1a-649d-4b0a-9da4-ce9e4b713d6f

Título/Nombre Clase - Eliminar

Descripción Elimina la clase no utilizada



La clase no utilizada se elimina junto con sus metadatos e historia de eventos


R5.4.5

Objetivo Control de accesos únicamente

Notas de uso No se genera ningún evento

F14.5.26 Clase – Eliminar Evento Residual


e8adbb3a-6e5d-49d2-989f-dabbcc384133

Título/Nombre Clase – Eliminar Evento Residual

Descripción Elimine el evento del historial de eventos de la clase residual



• No se modifican elementos de metadatos• La entidad evento es eliminada


R2.4.21





• Identificador de Clase Participante (M14.4.65)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)


F14.5.27 Clase – Eliminar Metadatos Residuales


145d6256-0974-46b1-b698-bc0d0ecadb57

Título/Nombre Clase – Eliminar Metadatos Residuales

Descripción Eliminar los elementos de los metadatos de la clase



Cualquier elemento de metadatos puede ser eliminado, incluyendo elementos de metadatos contextuales y del sistema, except un identificador de sistema o una fecha/hora


R7.5.7



• Identificador de Clase Participante (M14.4.65)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Comentario del Evento (M14.4.25)


F14.5.28 Clase - Destruir


fed36daf-26ce-4d44-8452-b0cc3607ab75

Título/Nombre Clase - Destruir

Descripción Destruye la clase activa







R5.4.6





• Identificador de Clase Participante (M14.4.65)• Comentario del Evento (M14.4.25)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)

Notas de uso El Identificador de Definición deElementos de Metadatos eliminado y la Definicion de Función de Eventos eliminada son usadas para mostrar que elementos de metadatos y cuales tipos de eventos fueron sustraidos del historial de eventos de la clase al ser destruidos según R2.4.20 y R7.5.6

F14.5.29 Clase - Exportado


476a72fd-0d53-470c-b962-afe9b1780759

Título/Nombre Clase –Exportado

Descripción La clase ha sido exportada por completo o como placeholder





R11.4.10

Objetivo Generacion de Eventos Unicamente


• Identificador de Clase Participante (M14.4.65)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función se realiza automaticamente por el proceso de exportación SDCM como resultado del proceso de exportación (ver F14.5.185 User - Export) para todas las entidades exportadas cuando un usuario realiza una exportación de acuerdo a R11.4.1

• El Identificador de Exportacion es el identificador del sistema generado por el SDCM para la exportación segun R11.4.4• La Exportación En Bandera Completa debe ser configurada si la entidad fue exportada por completo y aclarada si la entidad se exportó como placeholder• El Comentario de Evento contiene el comentario de exportación según R11.4.5



F14.5.30 Clase - Inspeccionar

Identificador del Sistema 1ce37d0a-be50-410b-9518-a4919921255f



Título/Nombre Clase - Inspeccionar

Descripción Busca la clase o la descubre , e inspecciona sus metadatos





R5.4.7, R6.5.9, R6.5.17, R9.4.7



• Identificador de Clase Participante (M14.4.65)

Notas de uso Solo se debe generar un evento para esta función cuando el usuario examine los metadatos de la clase y no cuando se identifique al revisar o como resultado de una busqueda

F14.5.31 Clase - Inspeccionar ACL


1107cc8a-798c-4d6f-8d95-55c9f87b43bc

Título/Nombre Clase – Inspeccionar ACL

Descripción Inspeccionar la lista de control de acceso de la clase





R4.5.9



• Identificador de Clase Participante (M14.4.65)



F14.5.32 Clase – Inspeccionar Evento


8753d035-a402-4346-be10-5010e1f278b3

Título/Nombre Clase – Inspeccionar Evento

Descripción Revise el historial de eventos de la clase o descubrala , e inspeccione sus eventos





R2.4.19



• Identificador de Clase Participante (M14.4.65)• Identificador de Evento Participante (M14.4.71)

F14.5.33 Clase – Modificar ACL


caced2b7-3496-4f0c-b679-6a8abc692c4a

Título/Nombre Clase – Modificar ACL

Descripción Modifica la lista de control de acceso de la clase





R4.5.10



• Identificador de Clase Participante (M14.4.65)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)



Notas de uso • Si el Valor de Bandera Incluir Valores Heredados se modifica entonces sedebe añadir un ingreso de Cambios en Metadatos al evento correspondiente• El Usuario Participante o Identificador de Grupo se refiere al usuario o grupo asociado con el ingreso de control de acceso • Si se modifica más de un ingreso de contol de acceso perteneciente a la clase simultáneamente, se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique • Los metadatos de evento informan que nuevos roles fueron

otorgados al usuario o grupo participante así cuales roles fueron anulados ya sea añadiendo, modificandoo, borrando o eliminando el ingreso de control de acceso

F14.5.34 Clase – Modificar Cronograma de Eliminación por Defecto


7308ee79-510a-4738-bf79-07fd0e85f4af

Título/Nombre Clase – Modificar Cronograma de Eliminación por Defecto

Descripción Modificar el identificador del cronograma de eliminacion por defecto de la calse activa



• Identificador de cronograma de eliminación por defecto (M14.4.11)


R5.4.4, R8.4.13



• Identificador de Clase Participante (M14.4.65)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

F14.5.35 Clase – Modificar Metadatos


aa06e05a-2d32-4a08-9902-bf1628ce506e

Título/Nombre Clase – Modificar Metadatos

Descripción Modifica los Metadatos de la Clase Activa




Entity metadata • Titulo (M14.4.104)• Descripción (M14.4.16)• Notas del Alcance (M14.4.97)• Elementos de Metadatos Contextuales


R5.4.3




Notas de uso • Cualquiera de los elementos de metadatos del sistema pueden ser modificados junto con cualquier elemento de metadatos contextuales modificables que pertenezcan a la clase

• Por cada elemento de metadatos modificado se debe adicionar un Ingreso de Cambio de Metadatos al evento generado alllevar a cabo la función

F14.5.36 Clase – Modificar Fecha/Hora Originada


db27260a-e681-42b9-ad2f-64c5929b4f33

Título/Nombre Clase – Modificar Fecha/Hora Modificada

Descripción Modificar la Fecha/Hora originada de la clase activa





R2.4.26




Notas de uso El evento para esta función siempre debe tener un Comentario de Eventos (ver R2.4.26)



F14.5.37 Componente – Añadir Metadatos Contextuales


4c36756b-c66d-4469-9379-c3d979a777dc

Título/Nombre Componente – Añadir Metadatos Contextuales

Descripción Añadir una o mas definiciones de elementos de metadatos contextuales al componente

Tipo de Entidad Componente (E14.2.3)



El aplicar elementos de metadatos contextuales también puede modificar los siguientes elementos de metadatos (si no se han establecido ya):

• Tiempo/Hora usada inicialmente (M14.4.32)


R7.5.19

Objetivo Generación de Evento Únicamente


• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado para ejecutar el Registro F15.5.115 – Añadir Metadatos Contextuales• Si los elementos de metadatos contextuales son agregados de una plantilla, entonces el Identificador de Plantilla Aplicado debe incluirse en los metadatos del evento (la plantilla no se considera como una entidad participante)

F14.5.38 Componente – Creación


0d6d5d46-4bab-4e92-8311-7d93ea476fd1

Título/Nombre Componente – Creación

Descripción Crear el component de un registro

Tipo de Entidad Component e(E14.2.3)


• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Identificador de Registro (M14.4.86)



• Título (M14.4.104)• Descripción (M14.4.16)• Bandera de Eliminación Automática (M14.4.3)• Elementos de metadatos contextuales

Si los elementos de metadatos contextuales son aplicados a partir de una plantilla,los siguientes elementos de metadatos pueden ser modificados(si no se han establecido aun):



R2.4.25, R6.5.19, R6.5.21, R7.5.18

Objetivo Generación de Evento Unicamente


• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso • El component es generado simultaneamente con su registro (ver F14.5.121)

Registro -Crear• El component puede ser creado con elementos de metadatos

contextuales asi como los elementos de metadatos del sistema enumerados

• Si los elementos de metadatos contextuales son agregados de una plantilla entonces el Identificador de Plantilla Aplicado debe ser incluido en los metadatos del evento.• Para cada elemento de metadatos establecido en la creación, excepto el Identificador de Sistemas y la Fecha/Hora creada, se deba añadir un Ingreso de Cambios en Metadatos, debe ser agregado al evento correspondiente

F14.5.39 Componente – Eliminación de Evento Residual


a0efddae-9c93-4bd4-bca1-11e4e12086d4

Título/Nombre Componente – Eliminacion de Evento Residual

Descripción Eliminar el evento del historial de eventos del componente residual

Tipo de Entidad Componente(E14.2.3)






R2.4.21, R6.5.21

Objetivo Generacion de Evento Unicamente


• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado a realizar el Registro F15.5.122 – Eliminar Evento Residual• Esta función siempre genera un evento (ver R2.4.14)

F14.5.40 Componente – Eliminar Metadatos Residuales


18378b4a-db17-4309-9c04-a88e15888e1e

Título/Nombre Componente – Elminar Metadatos Residuales

Descripción Eliminar el elemento de los metadatos del componente residual component



Cualquier elemento de metadatos puede ser eliminado, incluyendo tanto elementos de metadatos contextuales como de sistema, excepto un identificador de sistema o fecha/hora


R6.5.21, R7.5.7



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado a realizar el Registro F15.5.123 – Eliminar Metadatos Residuales • Esta función siempre genera un evento (ver R7.5.7)

F14.5.41 Componente – Destruir


4bc532be-b33b-407b-9c59-28bb6c65e1ff

Título/Nombre Componente – Destruir



Descripción Destruir el component como parte de la descripcion de un registro







R8.4.20



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)

Notas de uso • Esta función se realiza automáticamente por el SDCM como parte de la destrucción de un registro (ver F14.5.124 Registro-Destruir)

• El Identificador de Definición de Elementos de Metadatos Eliminado y el Identificador de Definición de Función de Evento Eliminado son usados para mostrar cuales elementos de metadatos y cuales tipos de eventos fueron sustraídos del historial de eventos del componente al momento de su destrucción, según R2.4.20 y R7.5.6

F14.5.42 Componente – Duplicar


9cd765ac-a511-4da1-9bee-90b40f769d60

Título/Nombre Componente – Duplicar

Descripción Duplicar un Componente



• Identificador de Duplicado (M14.4.23)


R6.5.16

Objetivo Generación del Evento Unicamente


• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Duplicado Participante (M14.4.69)• Identificador de Duplicado (M14.4.23)



Notas de uso • Esta función se realiza automáticamente por el SDCM como parte del duplicado de un registro (ver F14.5.126 Registro - Duplicado)

• Se generaran dos eventos de duplicado, uno para el primer componente que identifica al segundo componente como el duplicado mediante el Identificador de Duplicado Participante, y uno para el segundo



componente que identifica al primer componente como el duplicado mediante el Identificador de Duplicado Participante.

• Los eventos de duplicado estaran ligados por el Identificador de Duplicado en la entidad de evento.

F14.5.43 Componente – Exportado


cad7c66b-50ef-479c-9403-f61af0cffea4

Título/Nombre Componente – Exportado

Descripción El component ha sido exportado por completo o como placeholder





R11.4.10



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función se realiza automáticamente por el SDCM como parte del proceso de exportación (ver F14.5.185 Usuario - Exportación) para todas las entidades exportadas cuandoquiera que un usuario conduzca una exportación según R11.4.1

• El Identificador de Exportación esl el identificador de sistema generado por el SDCM para la exportacion segun R11.4.4• La Bandera de Exportación debe ser configurada si la entidad fue exportada por completo y aclarada si la entidad fue exportada como placeholder• El Comentario de Evento contiene el comentario de exportacion según R11.4.5

F14.5.44 Componente – Inspección


31b1b287-7de3-4f67-a637-c0f7063d19ac

Título/Nombre Componente - Inspección

Descripción Ubique el componente o descubralo mediante búsqueda e inspeccione sus metadatos







R6.5.17, R6.5.21



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado para ejecutar un Registro F15.5.131 Registro - Inspeccionar• Solo se debe generar un evento para esta función cuando el usuario examina los metadatos del componente y no cuando se identifica durante una búsqueda o si aparece como el resultado de una búsqueda

F14.5.45 Componente – Inspeccionar Evento


351ea1cf-87e0-4499-a397-f608ad3033c3

Título/Nombre Componente – Inspeccionar Evento

Descripción Ubique el historial del evento del componente e inspeccione sus eventos





R2.4.19, R6.5.21



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Identificador de Evento Participante (M14.4.71)

Notas de uso Esta función puede ser realizada por cualquier usuario autorizado para ejecutar un Registro F15.5.133 Inspeccionar - Evento



F14.5.46 Componente – Modificar Metadatos


fbc13347-7576-4aaa-9109-d5ff69a43021

Título/Nombre Componente – Modificar Metadatos

Descripción Modifica los metadatos del component activo


Entity metadata • Titulo (M14.4.104)• Descripción (M14.4.16)• Elementos de Metadatos Contextuales


R6.5.20, R6.5.21



• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado para ejecutar un Registro F15.5.135 Modificar - Metadatos• Cualquiera de los elementos de metadatos del sistema enumerado puede ser modificado junto con cualquier elemento de metadatos contextuales modificable que pertenezca al componente • Por cada elemento de Metadatos modificado se debe añadir un Ingreso de Cambio en Metadatos al evento generado al realizar esta función

F14.5.47 Componente – Modificar Fecha/Hora Originada


94480ab5-c230-4c54-b0a4-4980441bde4c

Título/Nombre Componente – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora originada del componente activo





R2.4.26, R6.5.21





• Identificador de Componente Participante (M14.4.66)• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Esta función puede ser realizada por cualquier usuario autorizado para ejecutar un Registro F15.5.136 Modificar Fecha/Hora Originada• El evento para esta función siempre ha de contar con un Comentario de Evento (ver R2.4.26)

F14.5.48 Definición de Elementos de Metadatos Contextuales – Crear


e12e910b-8a2e-4939-a34b-1f0eb06a9697

Título/Nombre Definición de Elementos de Metadatos Contextuales - Crear

Descripción Generar una definición de elementos de metadatos contextuales

Tipo de Entidad Definicion de Elementos de Metadatos Contextuales (E14.2.4)


• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Notas Sobre el Alcance (M14.4.97)• Orden de Presentación (M14.4.84)• Ocurre Mínimo (M14.4.56)• Ocurre Máximo (M14.4.53)• Bandera Es Modificable (M14.4.46)• Bandera Es Referencia de Entidad (M14.4.45)• Identificador de Tipo de Referencia de Entidad (M14.4.24)• Tipo de Datos (M14.4.10)• Bandera Es Textual (M14.4.47)• Valor por Defecto (M14.4.13)• Identificador de Lenguaje por Defecto (M14.4.12)• Bandera de Retener en Destrucción (M14.4.88)


R2.4.25, R7.5.2, R7.5.3, R7.5.4





• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Por cada elemento de metadatos establecido en la creación, excepto el Identificador de Sistemas y la Fecha/Hora generada, se debe añadir un Ingreso de Cambios en Metadatos al evento correspondiente

• Cuando los controles de acceso heredados de las definiciones de los elementos de metadatos contextuales sean modificadas al momento de crearse, entonces la Definición de Elementos de Metadatos – Modificar ACL F14.5.112 debe ser generada de manera separada para cada cambio realizado a la lista de control de acceso

F14.5.49 Definición de Elementos de Metadatos Contexutales - Eliminar


be1eadc6-d5a2-4d39-9a79-43c501b70cdb

Título/Nombre Definición de Elementos de Metadatos Contextuales – Eliminar

Descripción Eliminar la definición de elementos de metadatos contextuales no utilizados



La definicion de elementos de metadatos contextuales no utilizados se elimina junto con sus metadatos e historial de eventos


R7.5.10


Notas de uso No se genera evento

F14.5.50 Definición de Elementos de Metadatos Contexutales– Eliminar Eventos Residuales


f791a9a7-2470-491c-b5e5-31cc04a90788

Título Definición de Elementos de Metadatos Contextuales – Eliminar Eventos Residuales

Descripción Eliminar el evento del historial de eventos de la definición de elementos de metadatos contextuales





R2.4.21



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)

Notas de uso Esta función siempre genera un evento (see R2.4.14)

F14.5.51 Definición de Elementos de Metadatos Contexutales – Destruir


59e9e6a6-b87a-4ca2-a615-36d04518e064

Título/Nombre Definición de Elementos de Metadatos Contextuales – Destruir

Descripción Destruye la definicion de elementos de metadatos contextuales activa





R7.5.11



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Comentario del Evento (M14.4.25)

F14.5.52 Definición de Elementos de Metadatos Contexutales – Exportados


c1a541d1-d68a-4dc4-93d0-ae5596263d73

Título/Nombre Definición de Elementos de Metadatos Contextuales – Exportados

Descripción La definicion de elementos de metadatos contextuales ha sido exportada por completo o como placeholder





R11.4.10



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función se realiza automáticamente por los SDCM como resultado del proceso de exportación (verF14.5.185 Usuario- Exportación) para todas las entidades exportadas cuandoquiera que un usuario realice una exportación R11.4.1

• El Identificador de Exportación es el sistema idenetificador generado por los SDCM para exportación según R11.4.4• La bandera de exportación completa debe configurarse si la entidad fue exportada por completo y aclarada si la entidad fue exportada como

placeholder• El comentario de Evento contiene el comentario de exportación según R11.4.5

F14.5.53 Definición de Elementos de Metadatos Contexutales – Modificar Antes de Usar


31e98553-840c-48ab-8514-df2a77e9ae87

Título/Nombre Definición de Elementos de Metadatos Contextuales – Modificar Antes de Usar

Descripción Modifica los Metadatos de la definición de elementos de metadatos contextuales que nunca ha sido utilizada anteriormente


Entity metadata • Ocurre Mínimo (M14.4.56)• Ocurre Máximo (M14.4.53)• Bandera Es Modificable (M14.4.46)• Bandera Es Referencia de Entidad (M14.4.45)• Entity Reference Type Identifier (M14.4.24)• Tipo de Datos (M14.4.10)• Bandera Es Textual (M14.4.47)


R7.5.9






Notas de uso • Esta función solo puese ser utilizada por definiciones de elementos de metadatos contextuales que nunca han sido aplicados a una entidad

• Para cada elemento de metadatos modificado se debe añadir un Ingreso de Cambios de Metadatos al evento generado al realizar esta funcion

F14.5.54 Contextual Metadata Element Definition – Modify Originated Date/Time


23ab0db8-2a0a-495b-b7a2-211d577b2e00

Título/Nombre Definición de Elementos de Metadatos Contextuales – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha Originada de la definición de los elementos de metadatos contextuales activos





R2.4.26




Notas de uso El evento para esta función siempre debe tener un Comentario de Evento (ver R2.4.26)

F14.5.55 Proceso de Disposición – Añadir Metadatos Contextuales


d3110710-a391-4b15-b6c2-8e3f904549e2

Título/Nombre Proceso de Disposición – Añadir Metadatos Contextuales

Descripción Añada una o mas deficiniciones de elementos de metadatos contextuales al proceso de disposición

Tipo de Entidad Proceso de Disposición (E14.2.5)




• Elementos de metadatos contextuales adicionales, segun se especifica

Aplicando los elementos de metadatos contextuales de una plantilla tambien puede modificar los siguientes elementos de metadatos de plantilla (si no ha sido establecido ya):

• Tiempo/hora usada inicialmente (M14.4.32)


R7.5.19



• Identificador de Proceso de Disposición Participante (M14.4.67)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso Si los elementos de metadatos contextuales son añadidos de una plantilla entonces el Identificador de Plantillas Aplicado debe ser incluido en los metadatos del evento (la plantilla no se considera como una entidad participante)

F14.5.56 Proceso de Disposición – Añadir Entidad


3fa1c42b-1d1a-4888-8e26-f57a8d76df27

Título/Nombre Proceso de Disposición – Añadir Entidad

Descripción Añada una clase activa, agrupación o registro al Proceso de Dsiposicion Activo


Entity metadata • Identificador de Registro Retenido (M14.4.39)• Identificador de Agrupación Retenida (M14.4.37)• Identificador de Clase Retenida (M14.4.38)

Realizar esta función tambien puede modificar los siguientes elementos de metadatos (si no ha sido establecido ya):

• Fecha/Hora usada inicialmente (M14.4.32)


R9.4.3





• Identificador de Proceso de Disposición Participante (M14.4.67)• Ingreso de Cambio en Metadatos (D14.3.3)• Comentario del Evento (M14.4.25)

F14.5.57 Proceso de Disposición – Crear


45e638b2-3eda-4a2d-b320-3b156ed82897

Título/Nombre Proceso de Disposición – Crear

Descripción Crear un Proceso de Disposición



• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Mandato (M14.4.51)• Notas Sobre el Alcance (M14.4.97)• Elementos de metadatos contextuales

Si los elementos de metadatos contextuales son añadidos de una plantilla entonces los siguientes elementos de metadatos de la Plantilla pueden ser modificados (si no ha sido establecido ya):



R2.4.25, R7.5.18, R9.4.1



• Identificador de Proceso de Disposición Participante (M14.4.67)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)



Notas de uso • El proceso de eliminacion puede ser creado con elmentos de metadatos contextuales asi como con los elementos de metadatos de sistema enumerados

• Si los elementos de metadatos contextuales son añadidos de una plantilla entonces el Identificador de Plantilla Aplicado debe incluirse en los metadatos del evento• Por cada elemento de metadatos establecido en la creación, , excepto el

identificador de Sistema y la Fecha/Hora generada deben ser añadidas al evento correspondiente

•Cuando los controles de acceso heredados del proceso de disposición sean modificados en la creación, se deben generar eventos separados F14.5.66 Proceso de Disposición – Modificar ACL para cada cambio realizado a la lista de control de acceso

F14.5.58 Proceso de Disposición – Eliminar


52e2be2e-3aa6-4854-8b7d-d58141cec8a5

Título/Nombre Proceso de Disposición - Eliminar

Descripción Eliminar el Proceso de Disposición no utilizado



El proceso de eliminacion no utilizado se elimina junto con sus metadatos e historial de eventos


R9.4.6

Objetivo Generación de Acceso Unicamente


F14.5.59 Proceso de Disposición – Eliminar Evento Residual


e6b9b61f-7b7e-4a30-84bc-0908b44d21af

Título/Nombre Proceso de Disposición – Eliminar Evento Residual

Descripción Eliminar el evento del historial de eventos del proceso de disposición



• No se modifican elementos de metadatos• Se elimina la entidad evento


R2.4.21

Objetivo • Control de Acceso• Generación de Evento


• Identificador de Proceso de Disposición Participante (M14.4.67)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)


F14.5.60 Proceso de Disposición – Eliminar Metadatos Residuales


462a20ad-18d6-4875-b47e-b2ec992c612a

Título/Nombre Proceso de Disposición – Eliminar Metadatos Residuales

Descripción Eliminar el elemento de los metadatos del proceso de disposición residual



Cualquier element del metadatos puede ser eliminado incluyendo tanto los elementos de metadatos contextuales como los de sistemas, a excepción del identificador de sistema o de la fecha/hora


R7.5.7



• Identificador de Proceso de Disposición Participante (M14.4.67)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Comentario del Evento (M14.4.25)


F14.5.61 Proceso de Disposición – Destruir


4b02e580-7fdb-4780-85ce-fdaa88fff88d

Título/Nombre Proceso de Disposición – Destruir

Descripción Destruye el proceso de disposición activo



• Fecha/Hora destruida (M14.4.17)


R8.4.11



• Identificador de Proceso de Disposición Participante (M14.4.67)• Comentario del Evento (M14.4.25)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)

Notas de uso La Definición de Elementos de Metadatos Eliminados y el Identificador de Definción de Función de Eventos Eliminados se utilizan para mostrar cuales elementos de Metadatos y cuales tipos de Eventos fueron sustraídos del historial de Eventos del Proceso de Disposición al ser destruido según R2.4.20 yR7.5.6

F14.5.62 Proceso de Disposición – Exportar


1b60af30-8fb7-44af-8441-425004fc2780

Título/Nombre Proceso de Disposición – Exportar

Descripción El proceso de eliminacion ha sido exportado por completo o como placeholder





R11.4.10



• Identificador de Proceso de Disposición Participante (M14.4.67)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función se realiza automaticamente por los SDCM como resultado del proceso de exportación (ver F14.5.185 Usuario – Exportación) para todas las entidades exportadas cuandoquiera que un usuario realice una exportación según R11.4.1

• El Identificador de Exportación es el sistema identificador generado por los SDCM para exportación según R11.4.4• La Bandera de Exportación Completa debe configurarse si la entidad fue exportada por completo y aclarada si la entidad fue exportada como

placeholder• El comentario de Evento contiene el comentario de exportación según R11.4.5

F14.5.63 Proceso de Disposición – Inspeccionar

Identificador del Sistema cc102e9a-953f-410f-9cf2-e527ba70e49

Título/Nombre Proceso de Disposición – Exportar

Descripción Revise el proceso de disposición o descubralo buscando , e inspeccione sus metadatos





R5.4.7, R6.5.9, R6.5.17, R9.4.7



• Identificador de Proceso de Disposición Participante (M14.4.67)

Notas de uso Un evento solo debe generarse para esta función cuando el usuario examina los metadatos del proceso de disposición y no cuando se identifica al buscar o se incluya en los resultados de búsqueda

F14.5.64 Proceso de Disposición – Inspeccionar ACL


971b7480-cb7e-43de-9a37-41c65cd65c7a

Título/Nombre Proceso de Disposición – Inspeccionar ACL

Descripción Inspeccione la lista de control de acceso del proceso de disposición





R4.5.9



• Identificador de Proceso de Disposición Participante (M14.4.67)

F14.5.65 Proceso de Disposición – Inspeccionar Evento


a729cbb2-ae32-46ca-a31b-de9a1b010100

Título/Nombre Proceso de Disposición – Inspeccionar Evento

Descripción Examine el historial de eventos del proceso de disposición e inspeccione sus eventos





R2.4.19



• Identificador de Proceso de Disposición Participante (M14.4.67)• Identificador de Evento Participante (M14.4.71)

F14.5.66 Proceso de Disposición – Modificar ACL


f308349e-fd2a-46ed-a3bc-abfd458f30bd

Título/Nombre Proceso de Disposición – Modificar ACL

Descripción Modifique la lista de control de acceso del proceso de disposición



• Bandera de Roles Heredados Incluidos (M14.4.43)• Ingreso de Control de Acceso (D14.3.1)


R4.5.10



• Identificador de Proceso de Disposición Participante (M14.4.67)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)

Notas de uso • Si el valor de la bandera de Roles Heredados Incluidos se modificaEntonces el Ingreso de Cambio en Metadatos debe ser añadido al evento correspondiente

• El Identificador de Grupo o Usuario Participante se refiere al Usuario o Grupo asociado al Ingreso de Control de Acceso •Si más de un ingreso de control de acceso perteneciente al proceso de diposición se modifica simultáneamente entonces se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique• Los metadatos de evento muestran cuales roles nuevos fueron

otorgados al usuario o grupo participante y cuales roles existentes fueron anulados mediante la adicion, modification o eliminacion de entradas de control de acceso

F14.5.67 Proceso de Disposición – Modificar Metadatos


1ff0d40d-2a88-4b31-88f9-c1efc135c618

Título/Nombre Proceso de Disposición – Modificar Metadatos

Descripción Modifique los metadaots del proceso de disposición activo


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Mandato (M14.4.51)• Notas Sobre el Alcance (M14.4.97)• Elementos de metadatos contextuales


R9.4.2



• Identificador de Proceso de Disposición Participante (M14.4.67)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Cualquiera de los elementos de los metadatos del sistema enumerados pueden ser modificados junto con cualquier elemento de metadatos contextual modificable perteneciente al registro

• Para cada elemento de metadatos modificado, un ingreso de cambios en metadatos al evento generado al realizar dicha funcion

F14.5.68 Proceso de Disposición – Modificar Hora/Fecha Originada

Identificador del Sistema 812a29d1-a7ad-44d8-a7aa-4bab741e1e5b

Título/Nombre Proceso de Disposición – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora Originada del Proceso de Disposición





R2.4.26



• Identificador de Proceso de Disposición Participante (M14.4.67)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso El evento para esta función siempre debe tener un Comentario de Evento (ver R2.4.26)

F14.5.69 Proceso de Disposición – Remover Entidad


dcde1a11-f6e8-44f6-b48b-d3e61e53b9e2

Título/Nombre Proceso de Disposición – Remover Entidad

Descripción Remover una clase, aggrupación o registro del proceso de disposición activo


Entity metadata • Identificador de Registro Retenido (M14.4.39)• Identificador de Agrupación Retenida (M14.4.37)• Identificador de Clase Retenida (M14.4.38)


R9.4.3



• Identificador de Proceso de Disposición Participante (M14.4.67)• Ingreso de Cambio en Metadatos (D14.3.3)• Comentario del Evento (M14.4.25)

F14.5.70 Cronograma de Disposición – Añadir Metadatos Contextuales


88fed471-3f1a-4171-8099-b35304d9aee5

Título/Nombre Cronograma de Disposición – Añadir Metadatos Contextuales

Descripción Añada una o más definiciones de elementos de metadatos contextuales al cronograma de disposición

Tipo de Entidad Cronograma de Disposición (E14.2.6)



El aplicar elementos de metadatos contextuales de una plantilla también puede modificar los siguientes elementos de metadatos de plantilla (si no se han establecido aun ):

• Tiempo/Hora usado inicialmente (M14.4.32)


R7.5.19



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)


F14.5.71 Cronograma de Disposición – Crear


25556d43-6aa9-41e5-b146-e98473e14024

Título/Nombre Cronograma de Disposición – Crear

Descripción Crea un cronograma de disposción



• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Mandato (M14.4.51)

• Notas Sobre el Alcance (M14.4.97)• Código de Acción de Disposición (M14.4.18)• Código de Activación de Retención (M14.4.94)• Identificador de Elemento Activación de Retención (M14.4.95)• Código de Intervalo de Periodo de Retención (M14.4.90)• Número de Duración de Periodo de Retención (M14.4.89)• Código de Periodo de Retención Offset (M14.4.91)• Código de Periodo de Retención Offset Mes (M14.4.92)• Código de Intervalo de Periodo de Confirmación (M14.4.7)• Número de Duración de Periodo de Confirmación (M14.4.6)• Elementos de metadatos contextuales

Si se aplican elementos de metadatos contextuales de una planatilla también puede modificar los siguientes elementos de metadatos de plantilla (si no se han establecido aun )

• Hora/Fecha usado inicialmente (M14.4.32)


R2.4.25, R7.5.18, R8.4.1



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso • El cronograma de disposición puede ser con elementos de metadatos contextuales asi como con los elementos de metadatos de sistema enunciados

• Si los elementos de metadatos contextuales son agregados a partir de una plantilla entonces un Identificador de Plantilla Aplicada debe ser incluido en los metadatos del evento.• Para cada elemento de metadatos fijado al momento de generación, excepto para el Identificador de Sistema y Fecha/Hora generada, se debe añadir un Ingreso de Cambio en Metadatos para el evento correspondiente

• Cuando los controles de acceso heredados sean modificados al crearse, entonces se deben generar eventos separados Clase F14.5.33 – Modifique ACL para cada cambio que se realice a la lista de control de acceso

F14.5.72 Cronograma de Disposición – Eliminar


bac5ebc1-c4c3-4ec0-ba97-7421d17ca968

Título/Nombre Cronograma de Disposición – Eliminar

Descripción Eliminar el cronograma de de disposición no utilizado



El cronograma de disposición no utilizado se elimina junto con sus metadatos e historial de eventos


R8.4.10



F14.5.73 Cronograma de Disposición – Eliminar Evento Residual


8b26a551-b2c9-4940-ade6-ddf9ce771e62

Título/Nombre Cronograma de Disposición – Eliminar Evento Residual

Descripción Eliminar el evento del historial de eventos del cronograma de disposición residual



• No se modifican elementos de metadatos• The event entity is deleted


R2.4.21



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)Notas de uso Esta función siempre genera un evento (ver R2.4.14)

F14.5.74 Cronograma de Disposición – Eliminar Metadatos Residuales


2ef9758c-9143-4859-bf7f-f7e3384c8750

Título/Nombre Cronograma de Disposición – Eliminar Metadatos Residuales

Descripción Eliminar el elemento de los metadatos del cronograma de disposición residual




R7.5.7



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Comentario del Evento (M14.4.25)


F14.5.75 Cronograma de Disposición – Destruir


20f4d0e0-98c7-45b5-81d2-a14e67325f8e

Título/Nombre Cronograma de Disposición – Destruir

Descripción Destruye el cronograma de disposición activo





R8.4.11



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Comentario del Evento (M14.4.25)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)

Notas de uso El Identificador de Definición de Elementos de Metadatos Eliminado y el Identificador de Definicion de la Función de Evento Eliminado son utilizados para mostrar qué elementos de los metadatos y cuales tipos de eventos fueron sustraídos del historial de eventos de la agrupación al momento de ser destruidos según R2.4.20 y R7.5.6

F14.5.76 Cronograma de Disposición – Exportar


48f27df0-580a-4804-ab94-425dda402347

Título/Nombre Cronograma de Disposición – Exportado

Descripción El cronograma de disposiciónha sido exporatdo por completo o como placeholder





R11.4.10



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)


• El Identificadodor de Exportación es el identificador del sistemea genrado por el SDCM para la exportación, según R11.4.4• El Exportado en Bandera Completa debe ser configurado si la entidad fue exportada por completo y aclarado si la entidad fue exportada como placeholder• El Comentario del Evento contiene el comentario de exportacion bajo R11.4.5

F14.5.77 Cronograma de Disposición – Inspeccionar


a87eaf88-b537-4061-b57a-2d50e6fb5f9d

Título/Nombre Cronograma de Disposición – Inspeccionar

Descripción Examine el cronograma de disposición o descubralo buscando e inspeccione sus metadatos





R5.4.7, R6.5.17, R8.4.12



• Identificador de Cronograma de Disposición Participante (M14.4.68)

Notas de uso Solo se debe generar un evento para esta función cuando el usuario examine los metadatos del cronograma de eliminacion y no cuando se identifique durante una búsqueda o este incluido en resultados de busquedas

F14.5.78 Cronograma de Disposición – Inspeccionar ACL


624f62eb-7e01-4e98-b886-291a1166698d

Título/Nombre Cronograma de Disposición – Inspeccionar ACL

Descripción Inspecciona la lista de control de acceso del cronograma de disposición





R4.5.9



• Identificador de Cronograma de Disposición Participante (M14.4.68)

F14.5.79 Cronograma de Disposición – Inspeccionar Evento


028167e8-309a-458f-8ae3-5dfbab73451d

Título/Nombre Cronograma de Disposición – Inspeccionar Evento

Descripción Examine el historial de eventos del cronograma de disposición e inspeccione sus eventos





R2.4.19



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Identificador de Evento Participante (M14.4.71)

F14.5.80 Cronograma de Disposición – Modificar ACL


31b963f1-392c-4bd6-a696-934a53142632

Título/Nombre Cronograma de Disposición – Modificar ACL

Descripción Modifica la lista de control de acceso para el cronograma de disposición





R4.5.10



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)

Notas de uso • Si el valor de la Bandera de Roles Heredados se modifica se debe entonces añadir un ingreso de cambios en metadatos al evento correspondiente• El Usuario Participante o Identificador de Grupo se refiere al Usuario o Grupo asociado al ingreso del control de acceso • Si se modifica mas de un ingreso de control de acceso perteneciente al cronograma de eliminacion simultaneamente, entonces se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique• Los metadatos de evento indican cuales roles nuevos fueron otorgados al usuario o grupos participantes y cuales roles existentes fueron anulados mediante la adición, modificación o eliminación de ingresos de control de acceso

F14.5.81 Cronograma de Disposición – Modificar Metadatos


8ec42472-e351-4c7e-8c02-9da97677d9ac

Título/Nombre Cronograma de Disposición – Modificar Metadatos

Descripción Modifica los metadatos del cronograma de disposición activo


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Mandato (M14.4.51)• Notas Sobre el Alcance (M14.4.97)• Elementos de metadatos contextuales

Según R8.4.9, los siguientes metadatos solo pueden ser modificadosantes de que el cronorama de disposición se aplique a un registro:

• Código de Acción de Disposición (M14.4.18)• Código de Activación de Retención (M14.4.94)• Identificador de Elemento Activación de Retención (M14.4.95)• Código de Intervalo de Periodo de Retención (M14.4.90)• Número de Duración de Periodo de Retención (M14.4.89)• Código de Periodo de Retención Offset (M14.4.91)• Código de Periodo de Retención Offset Mes (M14.4.92)• Código de Intervalo de Periodo de Confirmación (M14.4.7)• Número de Duración de Periodo de Confirmación (M14.4.6)


R8.4.8, R8.4.9



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso • Cualquiera de los elementos de los metadatos del sistema enumerados pueden ser modificados asi como cualquier elemento de metadatos contextuales modificables que pertenezcan al registro

• Por cada elemento de metadatos modificado se debe agregar un Igreso de Cambios a Metadatos al evento mediante la realización de esta función.

F14.5.82 Cronograma de Disposición – Modificar Fecha/Hora Originada

Identificador del Sistema d98a38e4-8a18-4141-a245-58043ada13c1

Título/Nombre Cronograma de Disposición – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora Originada del cronograma de disposición activo





R2.4.26



• Identificador de Cronograma de Disposición Participante (M14.4.68)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso El evento de esta función siempre debe tener un Comentario de Evento (ver R2.4.26)

F14.5.83 Tipo de Entidad – Inspeccionar


e9975a09-acdf-4ef7-8ae8-eae72c66cb03

Título/Nombre Tipo d Entidad – Inspeccionar

Descripción Vaya al tipo de entidad o descubralo buscando e inspeccione sus metadatos

Tipo de Entidad Tipo de Entidad (E14.2.7)




R2.4.9, R7.5.12



• Identificador de Tipo de Entidad Participante (M14.4.70)

Notas de uso Un evento solo debe generarse para esta función cuando el usuario examina los metadatos del tipo de entidad y no cuando se identifica al buscar o se incluya en los resultados de búsqueda

F14.5.84 Tipo de Entidad – Inspeccionar ACL


a500ff2b-0518-459e-94d6-1f2f281b30d8

Título/Nombre Tipo de Entidad – Inspeccionar ACL

Descripción Inspeccioa la lista de control de acceso del tipo de entidad





R4.5.9



• Identificador de Tipo de Entidad Participante (M14.4.70)

F14.5.85 Tipo de Entidad – Inspeccionar Evento


e6d3f367-ec8f-4cac-b65b-7285dd4b3358

Título/Nombre Tipo de Entidad – Inspeccionar Evento

Descripción Encuentre el historial de evento del tipo de entidad e inspeccione sus eventos





R2.4.19



• Identificador de Tipo de Entidad Participante (M14.4.70)• Identificador de Evento Participante (M14.4.71)

F14.5.86 Tipo de Entidad – Modificar ACL

Identificador del Sistema 0704069a-0129-4978-9e69-401da1dbdc0a

Título/Nombre Tipo de Entidad – Modificar ACL

Descripción Modifica la lista de control de acceso para el tipo de entidad





R4.5.10



• Identificador de Tipo de Entidad Participante (M14.4.70)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)



pertenezca a la agrupación entonces se debe generar un evento por cada ingreso de control de acceso.


F14.5.87 Definición de Función – Inspeccionar


eedac611-18b3-46ab-9f78-ce5d105343f3

Título/Nombre Definición de Función – Inspeccionar

Descripción Vaya a la función de definición o descubrala buscando e inspeccione sus metadatos

Tipo de Entidad Definicion de Función (E14.2.9)




R2.4.11, R4.5.7



• Identificador de Definición de Función Participante (M14.4.72)

Notas de uso Un evento solo debe generarse para esta función cuando el usuario examina los metadatos de la definición de la función y no cuando se identifica al buscar o se incluya en los resultados de búsqueda

F14.5.88 Definición de Función – Inspeccionar ACL


eceb7200-db40-40cd-8140-a8a2fb2adfea

Título/Nombre Definición de Función – Inspeccionar ACL

Descripción Inspeccionar la lista de control de acceso de la definición de función

Tipo de Entidad Definición de Función (E14.2.9)




R4.5.9



• Identificador de Definición de Función Participante (M14.4.72)

F14.5.89 Definición de Función – Inspeccionar Evento


4ba33648-4e99-421a-acc3-92f1579839e4

Título/Nombre Definición de Función – Inspeccionar Evento

Descripción Vaya al historial del evento de la definición de función e inspeccione sus eventos





R2.4.19



• Identificador de Definición de Función Participante (M14.4.72)• Identificador de Evento Participante (M14.4.71)

F14.5.90 Definición de Función – Modificar ACL


c1c23be7-1bfe-49bb-a9e6-648a947926af

Título/Nombre Definición de Función – Modifique ACL

Descripción Modifique la lista de control de acceso para la definición de función

Tipo de Entidad Definición de función (E14.2.9)




R4.5.10



• Identificador de Definición de Función Participante (M14.4.72)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)



pertenezca a la definición de función entonces se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique


F14.5.91 Definición de Función – Modificar Generación de Evento


e2cf111d-faa8-4dd4-ad4c-36e15ad603f7

Título/Nombre Definición de Función – Modificar Generación de Evento

Descripción Cambia si un eventoes generado cuano se lleva a cabo la función



• Bandera de Evento Generado (M14.4.34)


R2.4.13



• Identificador de Definición de Función Participante (M14.4.72)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)


F14.5.92 Definición de Función – Modificar Retener Evento al Destruir


712df19b-80e1-4dda-b3a4-1971b8ebcf67

Título/Nombre Definición de Función – Modificar Retener Evento al Destruir

Descripción Cambia si un eveno es retenido o eliminao cuando la entidad participante es destruida



• Bandera de Retener al Destruir(M14.4.88)


R2.4.20



• Identificador de Definición de Función Participante (M14.4.72)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

F14.5.93 Grupo – Añadir Metadatos Contextuales


60d37b06-55e5-44d9-998b-8b866afbecb9

Título/Nombre Grupo – Añadir Metadatos Contextuales

Descripción Añade una o más definiciones de elemntos de metadatos contextuales al grupo

Tipo de Entidad Grupo (E14.2.10)


• Elementos de metadatos contextuales adicionales,según se especifica




R7.5.19



• Identificador de Grupo Participante (M14.4.73)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso Si los elementos de metadatos contextuales son agregados a partir de una plantilla entonces un Identificador de Plantilla Aplicada debe ser incluido en los metadatos del evento. (la plantilla no se considera una entidad participante)

F14.5.94 Grupo – Añadir Usuario


5327775f-2899-4268-aa59-92f5f6ee2f4f

Título/Nombre Grupo – Añadir Usuario

Descripción Añade el usuario actvo al grupo activo

Entity metadata El siguiente element de metadatos perteneciente al grupo participante puede ser modificado si no se ha ajustado previamente):

• Tiempo/Hora Utilizado Inicialmente (M14.4.32)

REalizar esta función de grupo añade el siguiente element de metadatos a la entidad de ususario participante:

• Identificador de Grupo (M14.4.36)


R3.4.4



• Identificador de Grupo Participante (M14.4.73)• Identificador de Usuario Participante (M14.4.81)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función puede presentarse en otro sistema ajeno al SDCM y sincronizarse al mismo

• Aunque esta función (y la autoridad correspondiente para llevarla a cabo) está asociada al grupo,el realizarla tiene el efecto de modificar el identificador de Grupo para la entidad usuario

F14.5.95 Grupo – Crear


97039415-a9c2-4cf7-999d-f4135304d97a

Título/Nombre Grupo – Crear

Descripción Crea un Grupo



• Identificador de Sistema (M14.4.100)• Fecha/Hora Generada (M14.4.9)• FEcha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Elementos de metadatos contextuales




R2.4.25, R3.4.9, R7.5.18



• Identificador de Grupo Participante (M14.4.73)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)


• La entidad de la clase puede ser creada con elementos de metadatos contextuales asi como con los elementos de metadatos del sistema enumnerados

• Si los elementos de metadatos contextuales son agregados a partir de una plantilla entonces un Identificador de Plantilla Aplicada debe ser incluido en los metadatos del evento.

• Para cada elemento de metadatos fijado al momento de generación, excepto para el Identificador de Sistema y Fecha/Hora generada, se debe añadir un Ingreso de Cambio en Metadatos para el evento correspondiente

• Cuando los controles de acceso heredados sean modificados al crearse, entonces se deben generar eventos separados Clase F14.5.33 – Modifique ACL para cada cambio que se realice a la lista de control de acceso

F14.5.96 Grupo – Eliminar


30e6e15b-f889-4ff7-8a66-a695498b5565

Título/Nombre Grupo – Elimnar

Descripción Elimina el grupo no utilizado



Se elimina la entidad del grupo no utilizado junto con sus metadatos e historial de evento


R3.4.11

Objetivo Control de Acceso Unicamente


F14.5.97 Grupo – Eliminar Evento Residual


ac82726d-804e-491d-a5ec-a27ffb986a91

Título/Nombre Grupo – Elminar Evento Residual

Descripción Elimina el evento del historial de evento del grupo residual





R2.4.21



• Identificador de Grupo Participante (M14.4.73)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)• Comentario del Evento (M14.4.25)


F14.5.98 Grupo – Eliminar Metadatos Residuales


41d00f75-2403-4d16-b825-f85acf6ee746

Título/Nombre Grupo – Eliminar Metadatos Residuales

Descripción Elimina el element de los metadatos del grupo residual





R7.5.7



• Identificador de Grupo Participante (M14.4.73)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Comentario del Evento (M14.4.25)

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 142 of 520


F14.5.99 Grupo – Destuir


0201d5d3-e201-4c5a-90b1-1a98913ba09a

Título/Nombre Grupo – Destruir

Descripción Destruye el grupo activo





R3.4.12



• Identificador de Grupo Participante (M14.4.73)• Comentario del Evento (M14.4.25)• Identificador de Definición de Elementos de Metadatos Eliminados (M14.4.15)• Identificador de Definición de Función de Evento Eliminado (M14.4.14)

Notas de uso El Identificador de Definición de Elementos de Metadatos Eliminado y el Identificador de Definicion de la Función de Evento Eliminado son utilizados para mostrar qué elementos de los metadatos y cuales tipos de eventos fueron sustraídos del historial de eventos de la agrupación al momento de ser destruidos según R2.4.20 y R7.5.6

F14.5.100 Grupo – Exportado


6978b25b-0036-44f9-ae99-b80e10027fe6

Título/Nombre Grupo – Exportado

Descripción El grupo ha sido exportado por completo o como placeholder





R11.4.10




• Identificador de Grupo Participante (M14.4.73)• Identificador de Exportación (M14.4.30)• Exportado En Bandera Completa (M14.4.31)• Comentario del Evento (M14.4.25)


• El Identificadodor de Exportación es el identificador del sistemea genrado por el SDCM para la exportación, según R11.4.4• El Exportado en Bandera Completa debe ser configurado si la entidad fue exportada por completo y aclarado si la entidad fue exportada como placeholder• El Comentario del Evento contiene el comentario de exportacion bajo

R11.4.5

F14.5.101 Grupo – Inspeccionar


642ce23c-542f-40c1-912d-07897a1415de

Título/Nombre Grupo – Inspeccionar

Descripción Vaya al grupo o descubralo buscando e inspeccione sus metadatos





R3.4.14



• Identificador de Grupo Participante (M14.4.73)

Notas de uso Solo se debe generar un evento para esta función cuando el usuario examine los metadatos de la clase y no cuando se identifique al revisar o como resultado de una busqueda


F14.5.102 Grupo – Inspeccionar ACL


d52f4721-d55b-4eee-aaab-f77d83e0dd55

Título/Nombre Grupo – Inspeccionar ACL

Descripción Inspecciona la lista de control de acceso delgrupo





R4.5.9



• Identificador de Grupo Participante (M14.4.73)

F14.5.103 Grupo – Inspeccionar Evento


bcadb823-13a1-4ba5-ae36-62b106132c7a

Título/Nombre Grupo – Inspeccionar Evento

Descripción Vaya al historial de evento del grupo e inspeccione sus eventos





R2.4.19



• Identificador de Grupo Participante (M14.4.73)• Identificador de Evento Participante (M14.4.71)

F14.5.104 Grupo – Modificar ACL

Identificador del Sistema f48f825f-2afb-427e-bdaa-056bb025521c


Título/Nombre Grupo – Modificar ACL

Descripción Modifica la lista de control de acceso the access control list del grupo





R4.5.10



• Identificador de Grupo Participante (M14.4.73)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)


Usuario o Grupo asociado con el ingreso de control de acceso y no debe confundirse conel Identificador de Grupo Participante el cual indica la entidad de grupo que tiene la lista de control de acceso

• Si se modifica simultáneamente más de un control de acceso que pertenezca al grupo entonces se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique

• Los metadatos del evento muestran cuales roles nuevos se otorgaron al usuario o grupo participante y cuales roles existentes fueron anulados mediante la adición, modificación y eliminación de entradas de control de acceso

F14.5.105 Grupo – Modificar Metadatos


b6d7687f-d94e-4281-8575-1302556ca6ba

Título/Nombre Grupo – Modificar Metadatos

Descripción Modifica los metadatos del grupo active



Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Elementos de metadatos contextuales


R3.4.10



• Identificador de Grupo Participante (M14.4.73)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)


• Cualquiera de los elementos de los metadatos del sistema enumerados pueden ser modificados asi como cualquier elemento de metadatos contextuales modificables que pertenezcan a la agrupación

• Por cada elemento de metadatos modificado se debe agregar un Igreso de Cambios a Metadatos al evento mediante la realización de esta función.

F14.5.106 Grupo – Modifificar FEcha/Hora Originada


b5ed9497-7ac2-4f95-8728-fd23d30d3b86

Título/Nombre Grupo – Modifcar Fecha/Hora Originada

Descripción Modifica la fecha/Hora Originada del grupo activo





R2.4.26



• Identificador de Grupo Participante (M14.4.73)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)

Notas de uso El evento para esta función siempre debe tener un Comentario de Eventos (ver R2.4.26)


F14.5.107 Grupo – Removee Usuario


c3713f12-feb6-459e-a21a-7e63aaeeea6c

Título/Nombre Grupo – Remover Usuario

Descripción Remueve el usuario active del grupo active


Entity metadata EL realizar esta función de grupo remueve los siguientes elementos de metadatos pertenecientes a la entidad de usuario participante:

• Identificador de Grupo (M14.4.36)


R3.4.4



• Identificador de Grupo Participante (M14.4.73)• Identificador de Usuario Participante (M14.4.81)• Comentario del Evento (M14.4.25)


• Esta función (y la autoridad correspondiente para realizarla)está asociada al grupo y no a la entidad participante

F14.5.108 Grupo – Reportar Membresía de Usuario


8b8c09d4-30aa-41c4-b0fc-1a0ecf4f9d88

Título/Nombre Grupo – Reportar Membresíade Usuario

Descripción Reporta los usuarios actives que pertenecieron al grupo en un momento (fecha/hora) histórico específico





R3.4.13




• Identificador de Grupo Participante (M14.4.73)• Fecha/Hora Histórica (M14.4.40)

F14.5.109 Definición de Elementos de Metadatos – Inspeccionar


a5423f4d-0f15-4376-8d22-b10affe3ae3a

Título/Nombre Definición de Elementos de Metadatos – Inspeccionar

Descripción Vaya a la definición de elmentos de metadatos, o descúbrala buscando e inspeccione sus metadatos

Tipo de Entidad Definición de Elementos de los Metadatos (E14.2.11)




R7.5.12



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)

Notas de uso Solo se debe generar un evento para esta función cuando el usuario examine los metadatos de la clase y no cuando se identifique al revisar o como resultado de una búsqueda

F14.5.110 Definición de Elementos de Metadatos – Inspeccionar ACL


35f8d31b-9db2-4d37-96a2-d0ad36533a92

Título/Nombre Definición de Elementos de Metadatos – Inspeccionar ACL

Descripción Inspeccione la lista de control de acceso de la definición de elementos de metadatos




MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 149 of 520Requerimientos funcionles

R4.5.9



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)

F14.5.111 Definición de Elementos de Metadatos – Inspeccionar Evento


72459e48-ea29-4b05-a125-75a36a0ea74f

Título/Nombre Definición de Elementos de Metadatos – Inspeccionar Evento

Descripción Vaya al historial de eventos de la definición de elementos de metadatos e inspeccione sus eventos





R2.4.19



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Identificador de Evento Participante (M14.4.71)

F14.5.112 Definición de Elementos de Metadatos – Modificar ACL


2f04f823-c37a-4c68-b6fa-76be4a76cf7d

Título/Nombre Definición de Elementos de Metadatos – Modificar ACL

Descripción Modifica la lista de control de acceso de la definición de elementos de metadatos





R4.5.10



• Identificador de Definición de Elemento de Metadatos Participantes (M14.4.74)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Rol Otorgado (M14.4.35)• Identificador de Rol Anulado (M14.4.87)


Usuario o Grupo asociado con el ingreso de control de acceso • Si se modifica simultáneamente más de un control de acceso que

pertenezca al grupo entonces se debe generar un evento por cada ingreso de control de acceso que se añada, remueva o modifique

• Los metadatos del evento muestran cuales roles nuevos se otorgaron al usuario o grupo participante y cuales roles existentes fueron anulados mediante la adición, modificación y eliminación de ingresos de control de acceso

F14.5.113 Definición de Elementos de Metadatos – Modificar Metadatos


2a70d3d6-4f38-4666-82ac-82d0ceb5e608

Título/Nombre Definición de Elementos de Metadatos – Modificar Metadatos

Descripción Modifica los metadatos de la definición de elementos de metadatos activa


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Notas Sobre el Alcance (M14.4.97)• Orden de Presentación (M14.4.84)• Valor por Defecto (M14.4.13)• Identificador de Lenguaje por Defecto (M14.4.12)


R7.5.8




Notas de uso Por cada elemento de metadatos modificado se debe agregar un Igreso de Cambios a Metadatos al evento mediante la realización de esta función

F14.5.114 Definición de Elementos de Metadatos – Modificar Retener al Destruir


f8f0cbb3-8f9e-4dc9-807e-36e351b85960

Título/Nombre Definición de Elementos de Metadatos – Modificar Retener al Destruir

Descripción Cambia si el valor de un elemento de metadatos es retenido o eliminado cuando se destruye la entidad a la que pertenece



• Bandera de Retener al Destruir (M14.4.88)


R7.5.6




F14.5.115 Registro – Añadir Metadatos Contextuales


83fa3a37-8bee-494e-af7a-8c23e56bb106

Título/Nombre Registro – Añadir Metadatos Contextuales

Descripción Añada una o más definiciones de elementos de metadatos contextuales al registro

Tipo de Entidad Registro (E14.2.12)


• Elementos de metadatos de contexto adicionales, según se especifica




R7.5.19



• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)• Ingreso de Cambio en Metadatos (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)


F14.5.116 Registro – Cancelar Destrucción


09cb99bb-bcd8-45cd-b0a3-436aab6a46b5

Título/Nombre Registro – Cancelar Destrucción

Descripción Cancele la destrucción pendiente del registro



• Identificador de Cronograma de Disposición (M14.4.22)• Fecha de Inicio de Retención (M14.4.93)• Código de Acción de Disposición (M14.4.18)• Fecha Establecida de Acción de Disposición (M14.4.19)• Fecha Establecida de Confirmación de Disposición (M14.4.20)• Fecha/Hora de Alerta de Retraso en Disposición (M14.4.21)


R8.4.18



• Identificador de Registro Participante (M14.4.77)• Ingreso de Cambio en Metadatos (D14.3.3)• Comentario del Evento (M14.4.25)

Notas de uso • Se debe aplicar un Nuevo cronograma de disposición al registro para reemplazarel cronograma de disposición enr igor

• El cometatio de cancelación se almacena como el Comemtario de Evento y se requiere según R8.4.18

F14.5.117 Registro – Cancelar Transferencia


19e3483a-dded-4e5f-a812-15b5a06da197

Título/Nombre Registro – Cancelar Transferencia

Descripción Cancela la transferencia pendiente del registro



• Identificador de Cronograma de Disposición (M14.4.22)• Fecha de Inicio de Retención (M14.4.93)• Código de Acción de Disposición (M14.4.18)• Fecha Establecida de Acción de Disposición (M14.4.19)• Fecha Establecida de Confirmación de Disposición (M14.4.20)• Fecha/Hora de Alerta de Retraso en Disposición (M14.4.21)


R8.4.18




Notas de uso • Se debe aplicar un Nuevo cronograma de disposición al registro para reemplazarel cronograma de disposición enr igor

• El cometatio de cancelación se almacena como el Comemtario de Evento y se requiere según R8.4.18

F14.5.118 Registro – Revisión Completa


339c50b5-3e06-4507-80e5-946cfa9b3ba5

Título/Nombre Registro – Revisión Completa

Descripción Completa una revision del registro



• Identificador de Cronograma de Disposición (M14.4.22)• Comentario de Últim Revisión (M14.4.49)• Fecha/Hora Última Revisión (M14.4.50)


R8.4.17




Notas de uso El comentario de revision se almacena como el Comentario de Evento (ver R8.4.17)

F14.5.119 Registro – Confirmar Destruccción


a221b6c3-4b3e-4737-a4f6-def8bded9af2

Título/Nombre Registro – Confirmar Destrucción

Descripción Confirma la destrucción del registro





R8.4.20, R8.4.23



• Identificador de Registro Participante (M14.4.77)• Comentario del Evento (M14.4.25)

Notas de uso • Cuando el usuario cierre agrupaciones como parte de la confirmación de la destrucción de un registro según R8.4.23, se deben generar eventos separados de F14.5.4Agrupación – Cerrar

• Al confirmarse,el SDCM de be realizar inmediatamente lasSiguientes funciones automáticas F14.5.124 Rgistro – Destruir, F14.5.41Componente – Destruir, y posiblemente F14.5.9 Agrupación – Destruir (under R8.4.21)

F14.5.120 Registro – Confirmar Transferencia

Identificador del Sistema 601253a3-723e-458b-be7d-2f4659c88eae

Título/Nombre Registro – Confirmar Transferencia

Descripción Confirma la transferencia del registro



• Fecha/Hora de Transferencia (M14.4.106)• Código de Acción de Disposición (M14.4.18)• Fecha Establecida de Acción de Disposición (M14.4.19)• Fecha Establecida de Confirmación de Disposición (M14.4.20)• Fecha/Hora de Alerta de Retraso en Disposición (M14.4.21)


R8.4.19




F14.5.121 Archivo – Crear

Identificador del sistema

13d444bf-3ba2-4c38-adc5-b57ec9e86f74

Título Archivo – Crear

Descripción Crear un archivo

Tipo de entidad Archivo (E14.2.12)

Metadata modificado de la entidad

• Identificador del sistema (M14.4.100)• Marca de tiempo creada (M14.4.9)• Fecha/Hora establecida (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Identificador de agrupacionde paternidad (M14.4.63)• Marca de tiempo agregada (M14.4.1)• Identificador de Clase (M14.4.4)• Identificador de Programación de Eliminación (M14.4.22)• Elementos contextuales de metadata

Los siguientes elementos de metadata pertenecientes a la agrupacion de paternidad del archivo serán modificados:

• Marca de tiempo de última adición (M14.4.48)

Los siguientes elementos de metadata pertenecientes a la agrupacion de paternidad del archivo también pueden ser modificados (si no han sido definidos previamente):

• Marca de Tiempo de Primera Utilización(M14.4.32)Si los elementos de contexto de metadata son aplicados desde una plantilla, los siguientes elementos de plantilla de metadata pueden ser modificados (si no han sido definidos previamente):

• Marca de Tiempo de Primera Utilización (M14.4.32)De los requisitos funcionales

R2.4.25, R6.5.10, R6.5.14, R7.5.18

Propósito • Control de Acceso• Generación de evento

Metadata adicional de eventos (ver R2.4.16)

• Identificadores de documentos participantes (M14.4.77)• Identificadores de nueva paternidad participantes (M14.4.75)• Comentario de evento (M14.4.25)• Cambio de ingreso de metadata (D14.3.3)• identificador de plantilla aplicada (M14.4.2)

Notas de uso • Uno o más components deben ser creados simultáneamente con el archivo (ver F14.5.38 Componente – Crear)

• El Identificador de Clase se aplica unicamente cuando se anula la clasificación inherente del archivo (de su agrupacion de paternidad) al ser creado

• El Identificador de Programación de Eliminación se aplica solamente cuando se anula inmediatamente el Programación predeterminado de eliminación del archivo (heredado de su clasificación) al ser creado.

• Todos los documentos deben tener un Identificador de Agrupacion de Paternidad y una Marca de tiempo Agregada• El archive puede ser creado con elementos de metadata contextual así como el sistema de elementos de metadata listado• Si los elements de metadata contextual son agregados desde una plantilla, entonces el Identificador de Plantilla Agregada debe ser incluida en la metadata del evento. • Por cada elemento de metadata ajustado en creación, excepto el Identificador de Sistema y la Marca de tiempo Creada, una Entrada de Cambio de metadata debe ser agregada al evento correspondiente.• Cuando los controles de acceso del archivo heredados son modificado en la creación, entonces eventos F14.5.134 Archivo – Modificar LCA deben ser generados para cada cambio realizado a la lista de control de acceso.

F14.5.122 Archivo – Borrar Evento Residual


9a91e950-48cd-4270-a592-dd41f4248ecc

Título Archivo – Borrar Evento Residual

Descripción Borrar el evento del historial de eventos de archivo residual

Tipo de Entidad Archivo (E14.2.12)

Metadata modificada de la Entidad

• Ningún elemento de metadata es modificado• La entidad del evento es borrada

De los requisitos funcionales

R2.4.21

Propósito • Control de Acceso• Generación de evento

Metadata adicional del evento (ver R2.4.16)

• Identificador de Archivo Participante (M14.4.77)•Identificador de Definición de la Función de Borrado de Evento (M14.4.14)• Comentario de evento (M14.4.25)


F14.5.123 Archivo – Borrar Metadata Residual


5812baba-fd3f-49c0-8560-2068d3f8c994

Título Archivo – Borrar Metadata Residual

Descripción Borrar el elemento de la metadata del archivo residual



Cualquier elemento de metadata puede ser eliminado, incluyendo los elementos de metadata de sistema o metadata de contexto, salvo un identificador del sistema o una marca de tiempo


R7.5.7

Propósito • Control de acceso• Generación de evento


• Identificador del Archivo Participante (M14.4.77)•Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Comentario de evento (M14.4.25)


F14.5.124 Archivo – Destruir


508e5ad6-0c8a-4ece-9b46-b8b39b53c857

Título Archivo – Destruir

Descripción Destruye el archivo



• Marca de tiempo de Destrucción (M14.4.17)• Identificador de Programación de Eliminación (M14.4.22)


R8.4.20, R8.4.24

Propósito Generación de evento únicamente


• Identificador de Archivo Participante(M14.4.77)•Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)Notas de uso • Esta función es ejecutada automáticamente por el SDCM como un

resultado del proceso de actualización (ver F14.5.140 Archivo – Eliminación de Actualización) para los documentos con componentes sujetos a destrucción automática, o por confirmación del usuario, en cualquier otro caso (ver F14.5.119 Archivo – Confirmar Destrucción)

• El Identificador de Programación de Eliminación se actualiza para asegurar que la Programación de eliminación, bajo el cual el archivo fue destruído, se mantenga junto al archivo residual incluso si había sido heredado previamente

• Los componentes del archivo deben ser destruídos simultáneamente de manera automática (ver F14.5.41 Componente – Destruir), y la

agrupacion del archivo puede también ser destruida bajo el R8.4.22 (ver F14.5.9 Agrupacion – Destruir)

• El Identificador de Definición del Elemento de Metadata Borrado y Identificador de Definición de la Función de Evento Borrada son utilizados para mostrar qué elementos de metadata y cuáles tipos de eventos fueron podados del historial de eventos del archivo en su destrucción bajo el R2.4.20 y el R7.5.6

F14.5.125 Archivo – Alerta de Eliminación


fdb351ed-d8eb-41e9-9e15-8b1bf32a3798

Título Archivo – Alerta de Eliminación

Descripción Alerta sobre el archivo, enviada cuando la Fecha de Vencimiento de Confirmación de Eliminación ha pasado



• Marca de tiempo del Alerta de Extemporaneidad de la Eliminación (M14.4.21)


R8.4.15



• Identificador de Archivo Participante(M14.4.77)• Identificador de Usuario Participante (M14.4.81)• Código de Acción de Vencimiento de la Eliminación (M14.4.58)• Fecha de Corte de Acción de Eliminación por Vencimiento (M14.4.59)• Fecha de Corte de Confirmación de Eliminación por Vencimiento (M14.4.60)• Comentario de evento (M14.4.25)

Notas de uso • Los usuario reciben alertas al serles asignados Rols que incluyen esta función• La función misma siempre se ejecuta automáticamente por el SDCM como parte del proceso de eliminación (ver F14.5.140 Archivo – Actualizar Eliminación)• El evento debe inclui un Identificador de Usuario Participante por cada usuario al que se haya enviado la alert • El Código de Acción de Vencimiento de la Eliminación debe indicar la acción de eliminación que estaba pendiente sobre el archivo cuando la alerta ha sido enviada• La Fecha de Corte de Confirmación de Eliminación por

Vencimiento debe indicar la Fecha de Corte de confirmación para el archivo cuando fuera enviada la alerta

• El Comentario de evento puede ser usado por el SDCM para dar detalles adicionales sobre la alerta (se pueden enviar alertas usando mecanismos y tecnologías variados, ver R8.4.15)

F14.5.126 Archivo – Duplicar


e6f97ac3-c9cc-4036-a471-a00c865db8a6

Título Archivo – Duplicar

Descripción Duplicate un archivo



Las siguientes entidades serán duplicadas:

• El archivo y toda su metadata;• Cada uno de los eventos y toda su metadata en el historial de eventos del archivo; y • Cada uno de los componentes del archivo, y toda su metadata.

Por cada archivo, componente y evento, incluyendo tanto el original como sus duplicados, la siguiente metadata será agregada para identificar el archivo, componente o evento correspondiente en el SDCM:

• Identificador de Duplicado (M14.4.23)


R6.5.16



• Identificador de Archivo Participante(M14.4.77)• Identificador de Duplicado Participante (M14.4.69)• Comentario de evento (M14.4.25)• Identificador de Duplicado (M14.4.23)

Notas de uso • Dos eventos de duplicado serán generados, uno para el primer archivo que identifica al segundo archivo como un duplicado suyo, usando el Identificador de Duplicado Participante, y uno para el segundo archivo que identifica al primero como duplicado suyo usando el Identificador de Duplicado Participante.

• Los evento de duplicado estarán vinculados por medio del Identificador de Duplicado en la entidad del evento

F14.5.127 Archivo – Exportado


1140f9cc-99e9-40e3-b3dd-be485170f718

Título Archivo – Exportado

Descripción El archivo ha sido exportado entero o como marcador de lugar



Ningún elemento de metadata es modificado


R11.4.10



• Identificador de Archivo Participante(M14.4.77)• Identificador de Exportación (M14.4.30)• Marcador de Exportación Completa (M14.4.31)• Comentario de evento (M14.4.25)

Notas de uso • Esta función es ejecutada automáticamente por el SDCM como resultado de un proceso de exportación (ver F14.5.185 Usuario - Exportar) para todas las entidades que son exportadas cada vez que un usuario lleva a cabo una exportación bajo R11.4.1

• El Identificador de Exportación es el Identificador del Sistema generado por el SDCM para la exportación bajo R11.4.4• El Marcador de Exportación Completa debe ser asignado si la entidad fue exportada entera y removido si la entidad fue exportada como un marcador de posición • El Comentario de evento contiene el comentario de exportación bajo R11.4.5

F14.5.128 Archivo – Bloqueado


38f887ed-7021-460d-8820-d26af5ce63a1

Título Archivo – Bloqueado

Descripción Indica que el archivo está sujeto a un bloqueo de eliminación



• Código de Acción de Eliminación (M14.4.18)• Fecha de Corte de Acción de Eliminación (M14.4.19)• Fecha de Corte de Confirmación de Eliminación (M14.4.20)


R8.4.21



• Identificador de Archivo Participante (M14.4.77)

Notas de uso • Esta función se ejecuta automáticamente por el SDCM como resultad del proceso de actualización (ver F14.5.140 Archivo – Eliminación de Actualización)

• El propósito de la función es generar un evento en el historial de eventos del archivo

• El Código de Acción de Eliminación debe ser modificado de DESTRUIR a MANTENER BLOQUEADO • La Fecha de Corte de Acción de Eliminación y la Fecha de Corte de Confirmación de Eliminación deben ser borradas

• Ver también F14.5.139 Archivo – Desbloqueado

F14.5.129 Archivo – Heredar Clase Predeterminada


e62728b4-13d7-4ef4-9833-7d8931c748e2

Título Archivo – Heredar Clase Predeterminada

Descripción Heredar la clasificación predeterminada de la agrupacion de paternidad del archivo


Entity metadata • Identificador de Clase (M14.4.4)


R6.5.12, R6.5.14



• Identificador de Archivo Participante(M14.4.77)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso Llevar a cabo esta función remueve el Identificador de Clase del archivo (ver F14.5.137 Archivo – Anular Clase) asegurando que el archivo herede la clasificación de su agrupacion de paternidad

F14.5.130 Archivo – Heredar Programación de Eliminación Predeterminada


eb4f94b8-9c0d-4f44-8d7c-b73c45735e49

Título Archivo – Heredar Programación de Eliminación Predeterminada

Descripción Heredar la programación de eliminación predeterminada de la clase del archivo


Entity metadata • Identificador de Programación de Eliminación (M14.4.22)


R6.5.14, R6.5.15



• Identificador de Archivo Participante (M14.4.77)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso Llevar a cabo esta función remueve el Identificador de Programación de Eliminación del archivo (ver F14.5.138 Archivo – Anular Programación de Eliminación) asegurando que el archivo herede su Programación de eliminación predeterminado de su clasificación

F14.5.131 Archivo – Inspeccionar


4f5f638f-f6ef-4917-adc0-82f90d065ef6

Título Archivo – Inspeccionar

Descripción Explora el archivo, o lo descubre a través de una búsqueda, e inspecciona su metadata.





R6.5.9, R6.5.17, R9.4.7, R8.4.16



• Identificador de Archivo Participante(M14.4.77)

Notas de uso Un evento debe ser generado únicamente por esta función cuando el usuario examina la metadata del archivo, y no cuando es identificado durante una exploración o incluído entre los resultados de búsqueda

F14.5.132 Archivo – Inspeccionarl LCA


7e4d0e6b-e726-4e3b-87a4-d1f6df60137e

Título Archivo – Inspeccionar LCA

Descripción Inspeccionar la Lista de Control de Acceso del archivo





R4.5.9




F14.5.133 Archivo – Inspeccionar Evento


29ee9ad5-6f9d-4663-9f99-99dca188c70e

Título Archivo – Inspeccionar Evento

Descripción Explora el historial de eventos del archivo e inspecciona sus eventos





R2.4.19



• Identificador de Archivo Participante(M14.4.77)• Identificador de Evento Participante (M14.4.71)

F14.5.134 Archivo – Modificar LCA


5e3380b4-da4a-4e1c-9387-5b83934ff1c2

Título Archivo – Modificar LCA

Descripción Modifica la Lista de Control de Acceso del archivo



• Marcador de Inclusión de Roles Heredados (M14.4.43)• Entrada de Control de Acceso (D14.3.1)


R4.5.10



• Identificador de Archivo Participante(M14.4.77)• Identificador de Usuario o Grupo Participante (M14.4.82)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Rol Asignado (M14.4.35)• Identificador de Rol Cancelado (M14.4.87)

Notas de uso • Si el valor del Marcador de Inclusión de Roles Heredados es modificado entonces se debe agregar una Entrada de Modificación de Metadata al evento respectivo• El Identificador de Usuario o Grupo Participante se refiere al usuario

o grupo que está asociado a la Entrada de Control de Acceso• Si más de una Entrada de Control de Acceso perteneciente al

archivo es modificada simultáneamente, entonces un evento debe ser generado por cada Entrada de Control de Acceso que sea agregada, removida o modificada

• La metadata del evento muestra cuáles roles nuevos fueron asignados al usuario o grupo participante y cuáles roles existentes han sido cancelados a través de la adición, modificación y remoción de Entradas de Control de Acceso

F14.5.135 Archivo – Modificar Metadata


b793efb9-fa12-41e9-9327-784324368bad

Título Archivo – Modificar Metadata

Descripción Modifica la metadata del archivo activo


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Elementos de metadata de contexto


R6.5.11




Notas de uso • Cualquiera de los elementos del sistema de metadata listados puede ser modificado, así como cualquier elemento de metadata contextual modificable pertenecientes al archivo

• Por cada elemento de metadata modificado, una Entrada de Modificación de Metadata debe ser agregado al evento generado mediante la ejecución de la función

F14.5.136 Archivo – Modificar Fecha/Hora Originada


2249c5a3-e760-4a82-89b5-47b804ff4c32

Título Archivo – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora Originada del archivo activo





R2.4.26




Notas de uso El evento para esta función siempre debe incluir un Comentario de evento (ver R2.4.26)

F14.5.137 Archivo – Anular Clase


069c29c9-15d9-42d8-8de4-a46b0405552a

Título Archivo – Anular Clase

Descripción Anula la clasificación anterior del archivo


Entity metadata • Identificador de Clase (M14.4.4)


R5.4.8, R6.5.12, R6.5.14



• Identificador de Archivo Participante (M14.4.77)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso Llevar a cabo esta función agrega un Identificador de Clase directamente al archivo o lo remplaza si el archivo ya tiene un Identificador de Clase

F14.5.138 Archivo – Anular Programación de Eliminación


c53ebf62-c69f-4e3d-b728-33252f4faa01

Título Archivo – Anular Programación de Eliminación

Descripción Anula la programacion de eleminación previa del archivo activo


Entity metadata • Identificador de Programación de Eliminación (M14.4.22)


R6.5.14, R6.5.15, R8.4.13




Notas de uso Ejecutar esta acción agrega un Identificador de Programación de Eliminación directamente al archivo, o lo remplaza si el archivo ya tiene un Identificador de Programación de Eliminación

F14.5.139 Archivo – Desbloqueado


185d46fa-22c8-4a65-904b-c51604df1189

Título Archivo – Desbloqueado

Descripción Indica que el archino no está sujeto a bloqueo alguno



• Código de Acción de Eliminación (M14.4.18)• Fecha de Corte de la Acción de Eliminación (M14.4.19)• Fecha de Corte de la Confirmación de Eliminación (M14.4.20)


R8.4.21




Notas de uso • Esta función es ejecutada automáticamente por el SDCM como resultado del proceso de actualización (ver F14.5.140 Archivo – Eliminación de Actualización)

• El propósito de la función es generar un evento en el historial de eventos del archivo• El código de Acción de Eliminación debe ser modificado de vuelta de MANTENER BLOQUEADO a DESTRUIR• La Fecha de Corte de Acción de Eliminación y la Fecha de Corte de la Confirmación de Eliminación deben ser calculados y aplicados al archivo• Ver también F14.5.128 Archivo – Bloqueado

F14.5.140 Archivo –Actualización de Eliminación


08f23ade-4023-46af-add7-39e6d399a5c3

Título Archivo –Actualización de Eliminación

Descripción Actualiza el progreso de eliminación del archivo



• Fecha de Comienzo de Retención (M14.4.93)• Código de Acción de Eliminación (M14.4.18)• Fecha de Corte de Acción de Eliminación (M14.4.19)• Fecha de Corte de Confirmación de Eliminación(M14.4.20)• Marca de tiempo del Alerta de Eliminación Inminente (M14.4.21)


R8.4.14



• Identificador de Archivo Participante(M14.4.77)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso • Esta función puede ser ejecutada por un usuario, siendo también ejecutada automáticamente por el SDCM en tiempo real o en intervalos regulares

• Cuando la metadata del archivo es actualizada, una Entrada de Modificación de Metadata debe ser agregada al evento por cada modificación• Un resultado de esta función puede ser activar una alerta (ver F14.5.125 Archivo – Alerta de Eliminación), la destrucción del

archivo (ver F14.5.124 Archivo – Destruir), para indicar que ya existe una programación de eliminación (ver F14.5.128 Archivo –

Bloqueado) o que ésta ha sido removida (ver F14.5.139 Archivo – Desbloqueado)

F14.5.141 Rol – Agregar Metadata de Contexto


c10b0afa-87b6-42be-a45d-55a663f2df54

Título Rol – Agregar Metadata de contexto

Descripción Agrega al rol una o más definiciones de elementos de metadata de contexto

Tipo de Entidad Rol (E14.2.13)


• Los elementos de metadata de contexto adicionales, según lo especificado

Aplicar elementos de metadata de contexto dede una plantilla puede también modificar el siguiente elemento de metadata de plantilla (si no ha sido establecido previamente):

• Marca de tiempo de Primera Utilización (M14.4.32)


R7.5.19



• Identificador de Rol Participante(M14.4.78)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Planilla Aplicada (M14.4.2)

Notas de uso Si los elementos de metadata de contexto son agregados desde una plantilla, entonces el Identificador de Plantilla Aplicada debe ser incluido en la metadata del evento (la plantilla no se considera una entidad participante)

F14.5.142 Rol – Agregar Definición de Función


b5782d06-9597-4c2b-aa18-1845e650ce05

Título Rol – Agregar Definición de Función

Descripción Agrega la definición de función a la definición de rol activo


Entity metadata • Identificador de Definición de Función (M14.4.33)


R4.5.4



• Identificador de Rol Participante(M14.4.78)• Identificador de Definición de Función Participante (M14.4.72)• Comentario de evento (M14.4.25)

F14.5.143 Rol – Crear


246af58d-72a1-4e03-9a1d-3fe7094e00af

Título Rol – Crear

Descripción Crea un rol



• Identificador del Sistema (M14.4.100)• Marca de tiempo creada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Marcador de Rol Administrativo IS (M14.4.44)• Título (M14.4.104)• Descripción (M14.4.16)• Notas de Alcance (M14.4.97)• Elementos de metadata de contexto

Si los elementos de la metadata de contexto son aplicados desde una plantilla el siguiente elemento de metadata de plantilla puede ser modificados (si no ha sido establecido previamente):

• Marca de tiempo de primera utilización(M14.4.32)


R2.4.25, R4.5.1, R7.5.18



• Identificador de Rol Participante(M14.4.78)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada (M14.4.2)

Notas de uso • El rol puede ser creado con elementos de metadata de contexto así como los elementos de metadata de sistema listados

• Si los elementos de metadata de contexto son agregados desde una plantilla, entonces el Identificador de Plantilla Aplicada debe ser

incluido en la metadata del evento• Por cada elemento de metadata asignado durante la creación, salvo el

Identificador del Sistema y la Marca de tiempo creada, una Entrada de Modificación de Metadata debe ser agregada al evento respectivo.

• En los casos en que el rol es creado con una o más definiciones de función activas asociadas a éste, se deben generar eventos F14.5.142 Rol – Agregar Definición de Función independientes por cada definición de función agregada a él al ser creada

• Cuando los controles de accesos heredados por el rol son modificados en la creación, se deben generar eventos F14.5.152 Rol – Modificar LCA independientes por cada cambio hecho en la lista de control de acceso

F14.5.144 Rol – Borrar


451fda23-8a3a-4a80-976f-9dd45a7eb1a5

Título Rol – Borrar

Descripción Borra el rol no utilizado


Metadata modificada de la

El rol que no está en uso es borrado, así como su metadata e historial de eventos


R4.5.5

Propósito Control de acceso únicamente



8eec771e-6441-4b58-b771-cccbaa94c55f

Título Rol – Borrar Evento Residual

Descripción Borra el evento del historial de eventos de un rol residual



• Ningún elemento de metadata es modificado• La entidad de evento es borrada


R2.4.21



• Identificador de Rol Participante(M14.4.78)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)• Comentario de evento (M14.4.25)


F14.5.146 Rol – Borrar Metadata Residual


55e02943-a58f-4f31-8207-dc44a390bd03

Título Rol – Borrar Metadata Residual

Descripción Borra el elemento de la metadata del rol residual



Cualquier elemento de metadata puede ser borrado, incluyendo tanto los elementos de metadata de sistema, como los de metadata de contexto , salvo un Identificador del Sistema o una Marca de tiempo


R7.5.7



• Identificador de Rol Participante(M14.4.78)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Comentario de evento (M14.4.25)



F14.5.147 Rol – Destruir


b969e173-ec5f-4046-95b5-f8e903d1e77b

Título Rol – Destruir

Descripción Destruye el rol activo



• Marca de tiempo de destrucción (M14.4.17)


R4.5.6



• Identificador de Rol Participante(M14.4.78)• Comentario de evento (M14.4.25)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)Notas de uso El Identificador de Definición del Elemento de Metadata Borrado y el

Identificador de Definición de la Función de Evento Borrada son usados para mostrar qué elementos de metadata y cuáles tipos de evento fueron suprimidos del historial de eventos del rol durante su destrucción, bajo R2.4.20 y R7.5.6

F14.5.148 Rol – Exportado


32673385-e87a-410c-ad54-0556ae1ed332

Título Rol – Exportado

Descripción El rol ha sido exportado entero o como marcador de lugar





R11.4.10




• Identificador de Rol Participante(M14.4.78)• Identificador de Exportación (M14.4.30)• Marcador de Erportación Completa (M14.4.31)• Comentario de evento (M14.4.25)

Notas de uso • Esta función es ejecutada automáticamente por el SDCM como resultado del proceso de exportación (ver F14.5.185 Usuario - Exportar) para todas las entidades que son exportadas siempre que un usuario lleva a cabo una exportación bajo R11.4.1

• El identificador de Exportación es el Identificador del Sistema generado por el SDCM para la exportación bajo R11.4.4• El Marcador de Exportación Completa debe ser asignado si la

entidad fue exportada entera y removido si la entidad fue exportada como un marcador de lugar

• El Comentario de evento contiene el comentario de exportación bajo R11.4.5

F14.5.149 Rol – Inspeccionar


f5833cf6-4d4a-43f9-bea8-77f768ba4e72

Título Rol – Inspeccionar

Descripción Explora en el rol, o lo descubre en una búsqueda, e inspecciona su metadata



Ningún elemento de metadatos es modificado


R4.5.7



• Identificador de Rol Participante(M14.4.78)

Notas de uso Un evento debe ser generado para esta función únicamente cuando el usuario examina la metadata del rol, y no cuando es identificado durante una exploración o incluído entre los resultados de búsqueda

F14.5.150 Rol – Inspeccionar LCA

Identificador del Sistema 5a336626-eab8-451e-8e7c-547b8933f5f4


Título Rol – Inspeccionar LCA

Descripción Inspecciona la lista de control de acceso del rol





R4.5.9



• Identificador de Rol Participante(M14.4.78)

F14.5.151 Rol – Inspeccionar Evento


bd6c020f-9ef6-4263-880f-99f28b75ac13

Título Rol – Inspeccionar Evento

Descripción Explora el historial de eventos del rol, e inspecciona sus eventos





R2.4.19



• Identificador de Rol Participante(M14.4.78)• Identificador de Evento Participante (M14.4.71)

F14.5.152 Rol – Modificar LCA


2803e039-8e4c-44a3-9e50-aebf5c2649e7

Título Rol – Modificar LCA


Descripción Modificar la lista de Control de acceso para el rol



• Marcador de Inclusión de Roles Heredados (M14.4.43)• Entrada de Control de acceso (D14.3.1)


R4.5.10



• Identificador de Rol Participante (M14.4.78)• Identificador de Usuario o Grupo Participante(M14.4.82)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Rol Asignado(M14.4.35)• Identificador de Rol Cancelado(M14.4.87)

Notas de uso • Si el valor del Marcador de Incluisión de Roles Heredados es modificado, entonces una Entrada de Modificación de Metadata debe ser agregada al evento correspondiente• El Identificador de Usuario o Grupo Participante hace referencia al

usuario o grupo que está asociado con la entrada de ontrol de acceso • Si más de una entrada de Control de acceso perteneciente a un rol es modificada simultáneamente, entonces un evento debe ser generado por cada entrada de control de acceso que haya sido agregada, removida o modificada.• La metadata del evento muestra cuáles nuevos roles fueron asignados al usuario o grupo participante, y cuáles roles existentes fueron cancelados a través de la adición, modificación o borrado de entradas de Control de acceso

F14.5.153 Rol – Modificar Metadata


59c2b665-aa89-4e87-8666-3d294f35a9e8

Título Rol – Modificar Metadata

Descripción Modificar la metadata del rol activo


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Notas de alcance (M14.4.97)• Elementos de metadata de contexto

De acuerdo con R4.5.3, la siguiente metadata puede ser modificada exclusivamente antes del uso del rol:


• Marcador del Rol de Administración IS (M14.4.44)


R4.5.2, R4.5.3



• Identificador de Rol Participante(M14.4.78)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso • Cualquiera de los elementos de metadata de sistema listados pueden ser modificados, así como cualquier elemento de metadata de contexto modificable que le pertenezca al rol

• Por cada elemento de metadata modificado, una Entrada de Modificación de Metadata debe ser agregada al evento generada al ejecutar la función

F14.5.154 Rol – Modificar Fech/Hora Originada


4cd52e0d-7972-499a-bc32-d7c81540094c

Título Rol – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora Originada del rol activo





R2.4.26



• Identificador de Rol Participante(M14.4.78)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso El evento de esta función siempre debe tener un comentario de evento (ver R2.4.26)

F14.5.155 Rol – Remover Definición de Función

Identificador del Sistema d0df9562-d560-4374-8ed8-07e4c3572d2a


Título Rol – Remover Definición de Función

Descripción Remueve la definición de función del rol activo


Entity metadata • Identificador de Definición de Función (M14.4.33)


R4.5.4



• Identificador de Rol Participante(M14.4.78)• Identificador de Definición de Función Participante (M14.4.72)• Comentario de evento (M14.4.25)

F14.5.156 Rol – Reportar Definiciones de Función


00a53f17-9866-4f0f-a387-16b549249284

Título Rol – Reportar Definiciones de Función

Descripción Reporta las definiciones de función que pertenecieron al rol en una fecha y hora específica del historial





R4.5.14



• Identificador de Rol Participante(M14.4.78)• Fecha/Hora del Historial (M14.4.40)

F14.5.157 Servicio – Agregar Metadata de Contexto


e2a1ab27-0a63-4abe-a2c7-a08c8027824c

Título Servicio – Agregar Metadata de Contexto


Descripción Agrega una o más definiciones de elementos de metadata de contexto al mantenimiento

Tipo de Entidad Servicio (E14.2.14)


• Elementos de metadata de contexto adicional, según lo especificado

Aplicar elementos de metadata de contexto desde una plantilla puede también modificar el siguiente elemento de metadata de plantilla (si no ha sido definido previamente):

• Marca de tiempo de Primera Utilización (M14.4.32)De los requisitos funcionales

R7.5.19



• Identificador de Servicio Participante (M14.4.79)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada(M14.4.2)

Notas de uso Si los elementos de metadata de contexto son agregados desde una plantilla, entonces el Identificador de Plantilla Aplicada debe ser incluido en la metadata del evento (la plantilla no se considera una entidad participante)

F14.5.158 Servicio – Inspeccionar


e9a0bfa5-6292-4ba2-80c4-eeab1a4c9a7f

Título Servicio – Inspeccionar

Descripción Explora en el servicio, o lo descubre a través de una búsqueda, e inspecciona su metadata





R2.4.3



• Identificador de Servicio Participante (M14.4.79)


Notas de uso Un evento debe ser generado para esta función únicamente cuando el usuario examina la metadata de servicio y no cuando es identificada mientras explora o al ser incluida entre los resultados de búsqueda

F14.5.159 Servicio – Inspeccionar LCA


ad683cd9-9f6a-45f7-a00d-a34550196b27

Título Servicio – Inspeccionar LCA

Descripción Inspecciona la lista de Control de acceso de servicio





R4.5.9




F14.5.160 Servicio – Inspeccionar Evento


40015ae8-17d7-4be4-a381-ae79066351ac

Título Servicio – Inspeccionar Evento

Descripción Explora el historial de eventos de servicio e inspecciona sus eventos





R2.4.19




• Identificador de Servicio Participante (M14.4.79)• Identificador de Evento Participante (M14.4.71)

F14.5.161 Servicio – Modificar LCA


537292ac-e4c4-45c0-8188-5597ffa58997

Título Servicio – Modificar LCA

Descripción Modifica la lista de control de acceso de servicio



• Entrada de Control de acceso (D14.3.1)


R4.5.10



• Identificador de Servicio Participante (M14.4.79)• Identificador de Usuario o Grupo Participante(M14.4.82)• Comentario de evento (M14.4.25)• Identificador de Rol Asignado(M14.4.35)• Identificador de Rol Cancelado(M14.4.87)

Notas de uso • Si el valor del Marcador de Inclusión del Rol Heredado es modificado, entonces una Entrada de Modificación de Metadata debe ser agregado al evento correspondiente• El Identificador de Usuario o Grupo Participante hace referencia al

usuario o grupo que está asociado a la entrada de Control de acceso • Si más de una entrada de Control de acceso que pertenece a Servicio es modificada simultáneamente, entonces un evento debe ser generado por cada entrada de Control de Acceso que es agregada, removida o modificada• La metadata del evento muestra cuales nuevos roles fueron asignados al usuario o grupo participante, así como cuáles roles fueron cancelados a través de la adición, modificación o borrado de entradas de Control de acceso

F14.5.162 Servicio – Modificar Metadata


d5be380f-b172-402a-898b-117d968c0ce3

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 182 of 520Título Servicio – Modificar Metadata

Descripción Modifica la metadata de Servicio


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Información del propietario (M14.4.62)• Elementos de metadata de contexto


R2.4.4



• Identificador de Servicio Participante (M14.4.79)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso • Cualquiera de los elementos de metadata de sistema listados pueden ser modificados, así como cualquier elemento modificable de metadata de contexto que pertenece al Servicio

• Por cada elemento de metadata modificado una Entrada de Modificación de Metadata debe ser agregada al evento generado al ejecutar esta función

F14.5.163 Servicio – Reportar Cumplimiento


8dbe7172-8919-4c42-a989-3d114a0812d4

Título Servicio – Reportar Cumplimiento

Descripción Reporta el estado de cumpimiento de Servicio





R2.4.5




Notas de uso El reporte debe listar sólo aquellos servicios, o paquetes de servicio, bajo R2.4.1, para los cuales el usuario tiene un rol que incluye esta función

F14.5.164 Plantilla – Agregar Metadata de Contexto


9540ba23-531f-45cf-9d9c-99150890bd2f

Título Plantilla – Agregar Metadata de Contexto

Descripción Agrega una o más definiciones de elementos de metadata de contexto a la plantilla

Tipo de Entidad Plantilla (E14.2.15)


• Elementos de metadata de contexto adicional, según especificado

Aplicar los elementos de metadata de contexto desde una plantilla puede también modificar el siguiente elemento de metadata de plantilla (si no ha sido determinado previamente):



R7.5.19



• Identificador de Plantilla Participante(M14.4.80)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada(M14.4.2)

Notas de uso Si los elementos de metadata de contexto son agregados desde una plantilla entonces el Identificador de Plantilla Aplicada debe ser incluido en la metadata del evento (la plantilla no es considerada una entidad participante)

F14.5.165 Plantilla – Crear


92634d40-ac65-4f87-ae90-fbe914dfe318

Título Plantilla – Crear

Descripción Crea una plantilla



• Identificador del Sistema (M14.4.100)• Marca de tiempo Creada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Identificador de Tipo de Entidad de Plantilla (M14.4.102)• Identificador de Servicio de Plantilla (M14.4.103)• Identificador de Clase de Plantilla (M14.4.101)• Identificador de Definición de Elemento de Metadata de Contexto (M14.4.8)• Elementos de metadata de contexto

Si los elementos de metadata de contexto son aplicados desde una plantilla, el siguiente elemento de metadata puede ser modificado perteneciendo a la plantilla de la cual fueron aplicados los elementos de metadata de contexto (si no ha sido asignado previamente):



R2.4.25, R7.5.14, R7.5.18



• Identificador de Plantilla Participante(M14.4.80)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada(M14.4.2)

Notas de uso • La plantilla ha sido creada con elementos de metadata de contexto así como los elementos de metadata de sistema listados

• Si son agregados elementos de metadata de contexto desde una plantilla, entonces el Identificador de Plantilla Aplicada debe ser incluido en la metadata del evento• Por cada elemento de metadata asignado durante la creación, salvo el Identificador del Sistema y la Marca de tiempo Creada,se debe agregar una Entrada de Modificación de Metadata al evento correspondiente • En los casos en que el Control de Accesos heredados de la plantilla sean

modificados en la creación, eventos F14.5.174 Plantilla – Modificar LCA separados deben ser generados por cada cambio realizado a la lista de Control de Acceso

F14.5.166 Plantilla – Borrar


5643fb8d-380b-4b0a-a30c-e0f09d3c2b0e

Título Plantilla – Borrar

Descripción Borra las plantillas no usadas



La plantilla no utilizada es borrada así como su metadata e historial de eventos


R7.5.16



F14.5.167 Plantilla – Borrar Evento Residual


5a95ef31-8881-424e-adfa-e6a4bfd3456e

Título Plantilla – Borrar Evento Residual

Descripción Borra el evento del historial de eventos de la plantilla residual



• Ningún elemento de metadata es modificado• La entidad de evento es borrada


R2.4.21



• Identificador de Plantilla Participante(M14.4.80)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)• Comentario de evento (M14.4.25)


F14.5.168 Plantilla – Borrar Metadata Residual


aa439637-6d4f-43e0-a63f-90b96f6be54f

Título Plantilla – Borrar Metadata Residual

Descripción Borra el elemento de metadata de la plantilla residual



Cualquier elemento de metadata puede ser borrado, incluyento tanto los elementos de metadata de sistema como los de metadata de contexto, excepto un Identificador del Sistema o una Marca de tiempo


R7.5.7



• Identificador de Plantilla Participante(M14.4.80)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Comentario de evento (M14.4.25)


F14.5.169 Plantilla – Destruir


37ff38c4-e14e-442c-aca6-1f1ad94ed41f

Título Plantilla – Destruir

Descripción Destruye la plantilla activa



• Marca de tiempo de destrucción (M14.4.17)


R7.5.17



• Identificador de Plantilla Participante(M14.4.80)• Comentario de evento (M14.4.25)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)

Notas de uso El Identificador de Definición del Elemento de Metadata Borrado y el Identificador de Definición de la Función de Evento Borrada son usados para mostrar qué elementos de metadata y cuáles tipos de eventos fueron suprimidos del historial de eventos de la plantilla al ser destruido, bajo R2.4.20 y R7.5.6

F14.5.170 Plantilla – Exportado


376e669e-9c7a-455c-bc2c-a46f344ad6da

Título Plantilla – Exportado

Descripción La plantilla ha sido exportada entera o como un marcador de lugar





R11.4.10



• Identificador de Plantilla Participante(M14.4.80)• Identificador de Exportación (M14.4.30)• Marcador de Exportación Completa (M14.4.31)• Comentario de evento (M14.4.25)

Notas de uso • Esta función es ejecutada automáticamente por el SDCM como resultado del proceso de exportación (ver F14.5.185 Usuario - Exportar) para todas las entidades que son exportadas siempre que un usuario lleva a cabo una exportación bajo R11.4.1

• El Identificador de Exportación es el Identificador del Sistema generado por el SDCM para la exportación bajo R11.4.4• El marcador de Exportación Completa debe ser asignado si la

entidad fue exportada completamente y retirado si la entidad fue exportada como un marcador de lugar

• El Comentario de evento contiene el comentario de exportación bajo R11.4.5

F14.5.171 Plantilla – Inspeccionar


1d699116-21ca-4318-8b2c-5a72851de157

Título Plantilla – Inspeccionar

Descripción Explora en la plantilla, o lo descubre a través de una búsqueda, e inspecciona su metadata





R7.5.12



• Identificador de Plantilla Participante(M14.4.80)

Notas de uso Un evento debe ser generado para esta función únicamente cuando el usuario examina la metadata de la plantilla, y no cuando es identificada a través de una exploración o incluida entre los resultados de búsqueda

F14.5.172 Plantilla – Inspeccionar LCA


9c75f837-16aa-4e1c-b8d7-705376cd800b

Título Plantilla – Inspeccionar LCA

Descripción Inspecciona la Lista de Control de Acceso de la plantilla





R4.5.9

Propósito • Control de acceso• Generación del evento


• Identificador de Plantilla Participante (M14.4.80)

F14.5.173 Plantilla – Inspeccionar Evento


142ba8e5-1cdf-4ca7-a6d6-2f8db1e4b08a

Título Plantilla – Inspeccionar Evento

Descripción Explora el historial de eventos de la plantilla e inspecciona sus eventos





R2.4.19



• Identificador de Plantilla Participante(M14.4.80)• Identificador de Evento Participante (M14.4.71)

F14.5.174 Plantilla – Modificar LCA


f5b7c65a-9b73-4769-969a-fde91d197381

Título Plantilla – Modificar LCA

Descripción Modifica la Lista de Control de Acceso para la plantilla



• Marcador de Inclusión de Roles Heredados (M14.4.43)• Entrada de Control de Acceso (D14.3.1)


R4.5.10



• Identificador de Plantilla Participante(M14.4.80)• Identificador de Usuario o Grupo Participante(M14.4.82)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Rol Asignado(M14.4.35)• Identificador de Rol Cancelado(M14.4.87)

Notas de uso • Si el valor del Marcador de Inclusión de Roles Heredados es modificado, se debe agregar una Entrada de Modificación de Metadata al evento correspondiente• El Identificador de Usuario o Grupo Participante hace referencia al usuario o grupo que está asociado con la Entrada de Control de Acceso

• Si más de una entrada de Control de Acceso perteneciente a la plantilla es modificada simultáneamente, un evento debe ser generado por cada Entrada de Control de Acceso que fue agregada, removida o modificada• La metadata de evento muestra qué nuevos roles fueron asignados al usuario o grupo participante y cuáles roles existentes fueron cancelados a través de la adición, modificación o borrado de entradas de control de acceso

F14.5.175 Plantilla – Modificar Metadata


d49046d1-984a-4ff0-b676-8598c2577466

Título Plantilla – Modificar Metadata

Descripción Modifica la metadata de la plantilla


Entity metadata • Título (M14.4.104)• Descripción (M14.4.16)• Identificador del Tipo de Entidad de Plantilla (M14.4.102)• Identificador de Servicio de Plantilla (M14.4.103)• identificador de Clase de Plantilla (M14.4.101)• Identificador de Definición de Elemento de Metadata de Contexto(M14.4.8)• Elementos de metadata de contexto


R7.5.15



• Identificador de Plantilla Participante(M14.4.80)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso • Cualquiera de los elementos de metadata de sistema listados puede ser modificado, así como cualquier elemento de metadata de contexto modificable que pertenezca a la plantilla

• Por cada elemento de metadata modificado, se debe agregar una Entrada de Modificación de Metadata al evento generada al ejecutar la función

F14.5.176 Plantilla – Modificar Fecha/Hora Originada


acf69ef4-7c80-48de-a11a-896c09d58b05

Título Plantilla – Modificar Fecha/Hora Originada

Descripción Modifica la Fecha/Hora Originada de la planilla activa





R2.4.26



• Identificador de Plantilla Participante(M14.4.80)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso El evento para esta función siempre debe tener un comentario de evento (ver R2.4.26)

F14.5.177 Usuario – Agregar Metadata de Contexto


2601f4d6-79df-4978-b860-b8e17b6520ce

Título Usuario – Agregar Metadata de Contexto

Descripción Agrega uno o más definiciones de elementos de metadata de contexto al usuario

Tipo de Entidad Usuario (E14.2.16)


• Elementos de metadata de contexto adicional, según especificado

Aplicar los elementos de metadata de contexto desde una plantilla puede también modificar el siguiente elemento de metadata de plantilla (si no ha sido previamente asignado):

• Marca de Tiempo de Primera Utilización(M14.4.32)


R7.5.19



• Identificador de Usuario Participante (M14.4.81)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada(M14.4.2)

Notas de uso Si los elementos de metadata de contexto son agregados desde una plantilla, el Identificador de Plantilla Aplicada debe ser incluido en la metadata del evento (la plantilla no se considera una entidad participante)

F14.5.178 Usuario – Explorar Documentos A Ser Eliminados


2c3722d2-bc17-4008-9c60-58d3d7d72f83

Título Usuario – Explorar Documentos A Ser Eliminados

Descripción Acceso a los documentos actualmente programados para ser eliminados por revisión, transferencia o destrucción





R8.4.16



• Identificador de Usuario Participante (M14.4.81)

Notas de uso Esta función permite al usuario explorar los documentos actualmente programados para ser eliminados; para inspeccionar cualquiera de estos documentos individualmente se requiere F14.5.131 Archivo – Inspeccionar

F14.5.179 Usuario – Crear


2cde7448-6c71-4cff-988a-973e0701a824

Título Usuario – Crear

Descripción Crea un usuario



• Identificador del Sistema (M14.4.100)• Marca de tiempo Creada (M14.4.9)• Fecha/Hora Originada (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Elementos de metadata de contexto

Si los elementos de metadata de contexto son aplicados desde una plantilla, el siguiente elemento de metadata de plantilla puede ser modificado (si no ha sido asignado previamente):

• Marca de Tiempo de Primera Utilización (M14.4.32)


R2.4.25, R3.4.2, R7.5.18



• Identificador de Usuario Participante (M14.4.81)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Plantilla Aplicada(M14.4.2)

Notas de uso • Esta función puede ocurrir en otros sistemas externos al SDCM y sincronizarse con éste

• La entidad usuario puede ser creada con un elemento de metadata de contexto así como los elementos de metadata de sistema listados

• Si los elementos de metadata de contexto son agregados desde una plantilla, se debe incluir un Identificador de Plantilla Aplicada en la metadata de evento• Por cada elemento de metadata asignado durante la creación, salvo el

Identificador del Sistema y la Marca de tiempo Creada, se debe agregar una Entrada de Modificación de Metadata al evento correspondiente

• En los casos en que el usuario es creado como miembro de uno o más grupos activos, eventos independiente para F14.5.94 Grupo – Agregar Usuario deben ser realizados automáticamente por cada grupo en que el usuario es creado, en el momento de la creación

• En los casos en que el control de acceso heredado por un usuario sea modificado durante la creación, deben ser generados eventos F14.5.190 Usuario – Modificar LCA independientes por cada modificación realizada a la lista de control de acceso

F14.5.180 Usuario – Borrar


3be51e0b-efd1-49e9-be3d-419ef6a60660

Título Usuario – Borrar

Descripción Borra un usuario no usado



La entidad de usuario no usado es borrado al igual que su metadata e historial de eventos


R3.4.5


Notas de uso Ningún evento es generado

F14.5.181 Usuario – Borrar Evento Residual

Identificador del Sistema b2593eb6-a542-4d20-8942-3f2cd0218edf

Título Usuario – Borrar Evento Residual

Descripción Borra el evento del historial de eventos del usuario residual



• Ningún elemento de metadata es modificado• La entidad del evento es borrada


R2.4.21



• Identificador de Usuario Participante (M14.4.81)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)• Comentario de evento (M14.4.25)


F14.5.182 Usuario – Borrar Metadata Residual


a8783b53-6557-4885-88c5-3781508809cd

Título Usuario – Borrar Metadata Residual

Descripción Borrar el elemento de la metadata del usuario residual



Cualquier elemento de metadata puede ser borrado, incluso los Elementos de metadata de contexto y los elementos de metadata de sistema, salvo un Identificador del Sistema o una Marca de tiempo


R7.5.7



• Identificador de Usuario Participante (M14.4.81)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Comentario de evento (M14.4.25)


F14.5.183 Usuario – Destruir


c33e48b3-2bc6-4851-b2e7-a40d602bfe1c

Título Usuario – Destruir

Descripción Destruye el usuario activo



• Marca de tiempo de Destrucción (M14.4.17)


R3.4.6



• Identificador de Usuario Participante (M14.4.81)• Comentario de evento (M14.4.25)• Identificador de Definición del Elemento de Metadata Borrado (M14.4.15)• Identificador de Definición de la Función de Evento Borrada (M14.4.14)

Notas de uso El Identificador de Definición del Elemento de Metadata Borrado y el Identificador de Definición de la Función de Evento Borrada son usados para mostrar qué elementos de metadata y cuáles tipos de evento fueron sustraídos del historial de eventos de la entidad usuario durante su destrucción, bajo R2.4.20 y R7.5.6

F14.5.184 Usuario – Reporte Detallado


428eb316-5eb8-4bda-87d6-fa4cc42331a3

Título Usuario –Reporte Detallado

Descripción Genera un reporte detallado basado en una consulta de búsqueda





R10.4.24, R10.4.26



• Identificador de Usuario Participante (M14.4.81)• Consulta de Búsqueda (M14.4.98)• Total de Entidades (M14.4.105)• Comentario de evento (M14.4.25)

Notas de uso • El reporte detallado está basado en ejecutar una búsqueda que debe ser descrita por la Consulta de Búsqueda, ver R10.4.22 y R10.4.24

• El Total de Entidades debe indicar el número de entidades incluidas en el reporte detallado, ver R10.4.20 y R10.4.24, esta cifra puede ser una aproximación

• Mayor información complementaria puede ser incluida dentro del Comentario de Evento, según sea requerido

F14.5.185 Usuario – Exportar


1262769d-024d-430f-a917-48b6a8e58d21

Título Usuario – Exportar

Descripción Exporta entidades desde el SDCM





R11.4.1, R11.4.10



• Identificador de Usuario Participante (M14.4.81)• Identificador de Exportación (M14.4.30)• Marca de tiempo de Inicio de Exportación (M14.4.28)• Marca de tiempo de Exportación Completa (M14.4.29)• Total de Entidades (M14.4.105)• Comentario de evento (M14.4.25)

Notas de uso • Esta función es ejecutada siempre que un usuario lleva a cabo una exportación bajo R11.4.1• El Identificador de Exportación es el Identificador del Sistema generado por el SDCM para la exportación bajo R11.4.4• El Total de Entidades debe indicar el número total de entidades que fueron exportadas, incluyendo las entidades exportadas completamente y las entidades exportadas como marcadores de lugar, y eventos• El Comentario de evento incluye el comentario de exportación bajo R11.4.5

• Este no es un evento que sea capturado por el historial de eventos de la entidad siguiendo su exportación bajo R11.4.10, el evento para esta función se convierte en parte del historial de eventos del usuario

• Ver también F14.5.10, F14.5.29, F14.5.43, F14.5.52, F14.5.62, F14.5.76,F14.5.100, F14.5.127, F14.5.148, F14.5.170, y F14.5.186

F14.5.186 Usuario – Exportado


6da05d24-5cbb-4b2b-9eb8-45d75564c6ab

Título Usuario – Exportado

Descripción El usuario ha sido exportado completamente o como marcador de lugar





R11.4.10



• Identificador de Usuario Participante (M14.4.81)• Identificador de Exportación (M14.4.30)• Marcador de Exportación Completa (M14.4.31)• Comentario de evento (M14.4.25)

Notas de uso • Esta función es ejecutada automáticamente por el SDCM como resultado de un proceso de exportación (ver F14.5.185 Usuario - Exportar) por todas las entidades que son exportadas siempre que un usuario lleva a cabo una exportación bajo R11.4.1

• El Identificador de Exportación es el Identificador del Sistema generado por el SDCM para la exportación bajo R11.4.4• El Marcador de Exportación Completa debe ser asignado si la entidad fue exportada completamente y retirado si la entidad fue exportada como un marcador de lugar• El Comentario de evento incluye el comentario de exportación bajo R11.4.5

F14.5.187 Usuario – Inspeccionar


246c3b2f-66cb-4585-8b6f-d38162ddaf99

Título Usuario – Inspeccionar

Descripción Explora en el usuario, o lo descubre por una búsqueda, e inspecciona su metadata





R3.4.14




Notas de uso Un evento debe ser generado para esta función únicamente cuando el usuario examina la metadata del usuario y no cuando es identificado durante una exploración o cuando es incluido entre los resultados de una búsqueda

F14.5.188 Usuario – Inspeccionar LCA


93dde507-4b84-4231-9641-8572f7b14c13

Título Usuario – Inspeccionar LCA

Descripción Inspeccionar la lista de control de acceso del usuario





R4.5.9




F14.5.189 Usuario – Inspeccionar Evento


8fe366ae-0e72-4042-8a8a-57e296927ee5

Título Usuario – Inspeccionar Evento

Descripción Explora el historial de eventos del usuario e inspeccionar sus eventos





R2.4.19



• Identificador de Usuario Participante (M14.4.81)• Identificador de Evento Participante (M14.4.71)

F14.5.190 Usuario – Modificar LCA


ef1deffd-68a5-4f19-ac54-ae3184d991d3

Título Usuario – Modificar LCA

Descripción Modifica la lista de control de acceso para el usuario



• Marcador de Inclusión de Roles Heredados (M14.4.43)• Entrada de control de acceso (D14.3.1)


R4.5.10



• Identificador de Usuario Participante (M14.4.81)• Identificador de Usuario o Grupo Participante(M14.4.82)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)• Identificador de Rol Asignado(M14.4.35)• Identificador de Rol Cancelado(M14.4.87)

Notas de uso • Si el valor del Marcador de Inclusión de Roles Heredados es modificado, se debe agregar una Entrada de Modificación de Metadata al evento correspondiente• El Identificador de Usuario o Grupo Participante hace referencia al usuario o grupo que está asociado con la entrada de control de acceso y no debe ser confundido con el Identificador de Usuario Participante el cual

indica la entidad de usuario que tiene la lista de acceso

• Si más de una entrada de acceso perteneciente al usuario es modificada simultáneamente, un evento debe ser generado por cada entrada de

acceso que sea agregada, removida o modificada• La metadata de evento muestra cuáles roles nuevos fueron asignados el usuario o grupo participante y cuáles roles existentes fueron cancelados a través de la adición, modificación o borrado de las entradas de control de acceso

F14.5.191 Usuario – Modificar Metadata


53b191b5-def2-4ab3-a110-3959c52784dc

Título Usuario – Modificar Metadata

Descripción Modifica la metadata del usuario activo


Metadata de la entidad

• Título (M14.4.104)• Descripción (M14.4.16)• Elementos de metadata de contexto


R3.4.3



• Identificador de Usuario Participante (M14.4.81)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso • Esta función puede ocurrir en otro sistema externo al SDCM y puede estar sincronizado con éste

• Cualquiera de los elementos de metadata de sistema listado puede ser modificado, así como cualquier Elemento de metadata de contexto modificable que pertenezca a la entidad de usuario

• Por cada elementos de metadata modificado, se debe agregar una Entrada de Modificación de Metadata al evento generado al ejecutar esta función

F14.5.192 Usuario – Modificar Fecha/Hora Originada


e3e88cce-a4b1-4860-9868-d9561f7417b3

Título Usuario – Modificar Fecha/Hora Originada

Descripción Modificar la Fecha/Hora Originada del usuario activo





R2.4.26



• Identificador de Usuario Participante (M14.4.81)• Comentario de evento (M14.4.25)• Entrada de Modificación de Metadata (D14.3.3)

Notas de uso El evento de esta función debe siempre tener un comentario de evento (ver R2.4.26)

F14.5.193 Usuario – Reportar Autorización


25315f00-835e-4dfb-9894-80688eadbf2b

Título Usuario – Reportar Autorización

Descripción Reporta la función y los roles activos que contienen aquellas funciones que el usuario puede llevar a cabo en una entidad nominal





R4.5.13




y uno de:

• Identificador de Agrupacion Participante (M14.4.64)• Identificador de Clase Participante (M14.4.65)• Identificador de Componente Participante (M14.4.66)• Identificador de Bloqueos de Eliminación Participante (M14.4.67)• Identificador de Programación de Eliminación Participante (M14.4.68)• Identificador de Tipo de Entidad Participante (M14.4.70)

• Identificador de Definición de Función Participante (M14.4.72)• Identificador de Grupo Participante (M14.4.73)• Identificador de Definición de Elemento de Metadata Participante (M14.4.74)• Identificador de Archivo Participante(M14.4.77)• Identificador de Rol Participante(M14.4.78)• Identificador de Servicio Participante (M14.4.79)• Identificador de Plantilla Participante(M14.4.80)

Notas de uso • Esta función es ejecutada sobre la entidad de usuario nominada por el usuario autorizado

• Por lo tanto, el Identificador de Usuario Participante hace referencia a la entidad de usuario nominada• Un máximo de una entidad participante más, representando la entidad nominada, debe ser incluida en el evento adicionalmente al Identificador de Usuario Participante• Si ninguna otra entidad participante es incluida en el evento, entonces la entidad propia de usuario, del usuario nominado, también es la entidad nominada

F14.5.194 Usuario – Reportar Membrecía del Grupo


868fd38a-74d4-4534-b3ec-37b0ec4d65aa

Título Usuario – Reportar Membrecía del Grupo

Descripción Reporta los grupos activos a los cuales un usuario nominado ha pertenecido en una Fecha/Hora específica del Historial





R3.4.7



• Identificador de Usuario Participante (M14.4.81)• Fecha/Hora del Historial (M14.4.40)

Notas de uso • Esta función se ejecuta sobre la entidad del usuario nominada por el usuario autorizado

• Por lo tanto, el Identificador de Usuario Participante hace referencia a la entidad de usuario nominado

F14.5.195 Usuario – Búsqueda


34dcf951-8608-46b5-808f-84fe8c378e7a

Título Usuario – Búsqueda

Descripción Busca entidades





R4.5.15, R6.5.18, R10.4.1, R10.4.22




Notas de uso • La Consulta de Búsqueda debe incluir una descripción de la consulta de búsqueda llevada a cabo, ver R10.4.22

• El Total de Entidades debe indicar el número de entidades encontradas por una búsqueda, ver R10.4.20, esta cifra puede ser una aproximación


F14.5.196 Usuario – Reporte de Resumen


aafece46-99dd-4e55-b0b2-81e5c0f1cf23

Título Usuario –Reporte de Resumen

Descripción Genera un reporte de resumen basado en múltiples consultas de búsqueda





R10.4.25, R10.4.26




Notas de uso • Una Consulta de Búsqueda debe ser agregada al evento por cada búsqueda incluida en el reporte de resumen, ver R10.4.25

• El Total de Entidades debe indicar el gran total de todas las entidades encontradas a través de todas las consultas de búsqueda, ver R10.4.20 y R10.4.25, esta cifra puede ser una aproximación


15. ReconocimientosDesarrollar una especificacion como la de MoReq2010® requiere de una gran cantidad de energia y compromiso de mucha gente. Debido a que la gestion de los documentos es un campo tecnico y altamente especializado, los encargados generalmente lideran grupos de expertos en la disciplina, nacionales e internacionales quienes sacrifican su tiempo y esfuerzo en una tarea sin animo de lucro. Because records management is a technical and highly specialised field, these contributors

El DLM Forum® desea agradecer a todos aquellos que han contribuido en el desarrollo de MoReq2010

®.

15.1 Equipo del Proyecto

El programa de trabajo de MoReq2010® tomo todo un ano. Fue lanzado en el DLM Forum AGM en Madrid en Mayo de 2010, y MoReq2010® fue oficialmente presentado en el DLM Forum AGM en Budapest en Mayo de 2011.

15.1.1 Autor

Jon Garde, Journal IT

15.1.2 Editor

Richard Blake, The National Archives, UK

15.1.3 Gerencia del Programa

Simon Cole, Automated Intelligence

Martin Waldron, Weathervane Consult

15.1.4 Equipo tecnicoHans Fredrik Berg, National Archives of Norway

Richard Jeffrey-Cook, InForm Consult

15.1.5 Correctores de texto

Paul Sutcliffe, Consultant

15.2 Grupo de Revisores Expertos

El DLM Forum® agradece la generosa asistencia de la European Commission al apoyar al Grupo de Revisores Expertos de MoReq2010® , facilitando las comunicaciones y coordinando las reuniones.

15.2.1 Direccion

Malcolm Todd, The National Archives, UK

15.2.2 European Commission

Jef Schram, European Commission

15.2.2 Expertos

Francisco Barbedo, National Archives de

Portugal

Diane Carlisle, ARMA International

Tracy Caughell, OpenText Corporation

Marie-Anne Chabin, Archive 17

Elena Cortés Ruiz, National Archives of Spain

Andrew Ewing, Hewlett Packard Software

Maria Guercio, University of Urbino

Andrea Hänger, Bundesarchiv

Hans Hofman, National Archives of the Netherlands/International Council on Archives

Toivo Jullinen, National Archives of Estonia

Julie McLeod, University of Northumbria

Bogdan-Florin Popovici, National Archives of Romania

Barbara Reed, Recordkeeping Innovation

Jože Škofljanec, National Archives of Slovenia

15.3 Consultores

Las siguientes personas contribuyeron en la revision formal de la especificacion durante la consulta para MoReq2010® (llevada a cabo en el verano de 2010) y la consulta del borrador de MoReq2010®

(invierno de 2010/11).

Malcolm Beach, In-Form Consult

Steve Bertone, OpenText Corporation

Kris Brown, HP

Stephen Clarke, ISO Committee TC46/SC11 Archives & Records Management

Lucas Colet, Public Research Centre Henri Tudor

Julian Croker, Steria

Christian Dubourg, Ever-Team Software

Laznik Dušan, Mentis d.o.o.

Marc Fresko, Inforesight

Rita Gago, Arquivo Municipal de Lisboa (Lisbon Municipal Archive)

Kirsten Glenwright, Objective Corporation

Mariella Guercio, University of Urbino

Paul Hampton, Alfresco

Katrina Hinton, Objective Corporation

Vincent Caper Hoolt, European Central Bank

Gabor Hornyak, MATRIX Auditing Evaluating and Certification

Gregor Joeris, SER Software Technology

Ben Johnson, Objective Corporation

Ulrich Kampffmeyer, PROJECT CONSULT Unter

Hanns Köhler-Krüner, HKK Consulting

Robert Lentz, cBrain A/S

Marko Lukičić, Ericsson Nikola Tesla

Karl Mayrhofer, Fabasoft

Leo Merman, Celt Consultancy

Christoph Mueller, HTW Chur

Giovanni Michetti, University of Rome “La Sapienza”

Tony Ogilvie, Automated Intelligence

Maria Palma, AedocDigital

Osmo Polonenn, Finnish MoReq Working Group

Bogdan-Florin Popovici, National Archives of Romania

Professor Roberta Raimondi, Bocconi School of Management Milan

Shaheen Ramdiane, OpenText Corporation

Susana. B. Rodriguez, Ministry Defense Spain

John Seeley, IKM Solutions

Deirdre Sharp, Norfolk County Council

María José Aldaz Sola, Archivistica.Net

Lucia Stefan, Archiva

Ricardo Vieira, INESC-ID

Naina Visani, IKM Solutions

Chris Walker

Robert Whiter, Oracle

Anthony Woodward, Record Point Software

Sherry Xie, University of British Columbia

PART TWO – PLUG-IN MODULES

100. SERIES DE INTERFACE

101. Interface Gráfica de Usuario (IGU)

101.1 Información de Módulo

Nombre del Módulo Interface Gráfica de Usuario (IGUIGU)

Versión de Módulo 1.0

Implementa Identificadorde Módulo (ver M14.4.41)

0f9584e5-552a-4a79-a8ea-3c2801765255

Prerequisitos MoReq2010® Servicios Básicos

Co-requisitos ninguno

101.2 Conceptos Clave

101.2.1 Características principales de una interface gráfica de usuario

Una interface gráfica de usuario o IGU es la manera mas común para que los usuarios interactúen con tecnologías modernas de informática. Una interface gráfica de usuario puede ser suministrada en cualquier sistema de información que tenga una pantalla y uno ó más dispositivos de entrada. La información es transmitida normalmente a un GUI a través de dispositivos de entrada tales como, teclados, ratones, tablets, esferos/agujas, pantallas táctiles y micrófonos que transmiten comandos de voz. El Feedback de una GUI es ante todo visual a través de una pantalla o display, sin embargo, en algunas ocasiones su suministra audio y otro feedback suplementario.

Las características principales de la mayoría de interfaces gráficas de usuario son:

• Permiten a los usuarios usar más de una aplicación al mismo tiempo y seguir enlaces e intercambiar aplicaciones, por ejemplo, un usuario leyendo un email en el correo de un cliente puede dar click en un enlace que abre en un navegador de la web;

• Permiten a los usuarios ver más de un ítem o parte de información al mismo tiempo y ver alguna información como texto y otra como imágenes, íconos o gráficas• Permiten a los usuarios manipular y llevar a cabo acciones en ítems dando click con

un mouse, tocando con un dedo o escribiendo en un teclado;• Permiten a los usuarios navegar visualmente entre ítems facilitando displays

múltiples de ítem tales como vistas de lista y vistas de árbol;• Permiten a los usuarios ver las relaciones entre ítems;• Permiten a los usuarios seleccionar múltiples ítems inmediatamente lazándolos, o

técnica similar, y luego realizar las mismas acciones en más de un ítemsimultáneamente;

• Permiten a los usuarios manipular ítems arrastrándolos y descargándolos sobre otrosítems;

• Permiten a los usuarios alternar entre vistas, o windows, del mismo set de información;

• Permiten a los usuarios ampliar entidades, o ver una vista alternativa, usando el zoom hacia dentro y hacia fuera;

• Pueden mostrar información seleccionada en diferentes maneras e indicar el status de ítems con varios efectos visuales;

• Pueden superponer diferente información de partes de un sistema en un solo displaycoherente ;

• Pueden suministrar notificaciones emergentes con cuadros de díalogo para que los usuarios interactúen con ellos;

• Pueden simular una forma para el registro de metadatos acerca de un ítem;• Pueden guiar al usuario a través de procesos complejos a través de técnicas como

un mago;• Pueden limitar las operaciones que un usuario puede seleccionar a través de listas de

selección y menús;• Pueden deshabilitar funciones que no sean apropiadas para un ítem particular;• Pueden mostrar resultados de búsqueda, informes y el contenido de ítems

directamente en la pantalla o display; y• Pueden ser adaptados y arreglados para satisfacer usuarios individuales and funciones específicas.

El presente módulo contiene los requerimientos para soluciones SDCM que implantan o implementan una IGU.

101.2.2 Interfaces gráficas de usuario y sistemas de documentos

Cuando un sistema de documentosos tenga una IGU, toda la funcionalidad dispar del sistema de documentos es juntada en esa interface de tal forma que los usuarios puedan interactuar con ella. Los procesos mismos pueden estar siendo ejecutados en diferentes lugares, tanto localmente como en servidores remotos y servidores de web. Las diferentes partes del sistema de documentos pueden conectarse entre sí en redes de área local, redes de área extensa, intranets privados, o la Internet pública. La IGU, sin embargo, debe buscar dar una vista unificada y coherente del sistema de documentos que esconde la complejidad técnica de su infraestructura subyacente.

Para la mayoría de sistemas de documentos la IGU pertenecerá a una aplicación nativa o a una aplicación web alojada en un navegador de la web. Cuando la IGU pertenezca a una aplicación nativa debe intentar, tanto como sea posible, seguir las convenciones y las directrices de la interface de usuario para el sistema operativo en el cual está alojada la aplicación. Cuando la IGU sea parte de una aplicación de web debe intentar, tanto como sea posible, seguir las convenciones y directrices de accesibilidad del World Wide Web Consortium (W3C). En ambos casos la IGU debe intentar ser fácil de usar y and y consecuente con las expectativas de los usuarios, para brindarle a estos últimos la mayor oportunidad de poder interactuar con y operar el sistema de documentos con mínima experiencia previa, entrenamiento y esfuerzo ergonómico.

En particular un SDCM debe usar su interface gráfica de usuario para:

• Permitir a los usuarios interactuar con los contenidos del sistema de documentos presentando entidades agrupadas en estructuras lógicas, tales como vistas de lista, vistas de árbol y mapas de la red;

• Representar el status de entidades a través de medios gráficos;• Mostrar por defecto solamente las entidades activas, pero permitir el cambio

de display para mostrar las entidades residuales también;• Facilitar la navegación, tal como se define en MoReq2010®, por ejemplo a

partir de una agrupacion padre, poder acceder fácilmente e inspeccionar sus hijo


• Permitir a los usuarios inspeccionar y, cuando estos tengan autorización, modificar los metadatos de entidades, por ejemplo a través de una vista de formas;

• Facilitar la terminación de tareas, tales como la población de los elementos de metadatos, suministrando ayudas tales como valores de defecto, listas de selección, correctores ortográficos, look up panels, y así sucesivamente;

• Permitir a los usuarios crear entidades fácilmente en el sistema de documentos, por ejemplo, iniciando posiblemente la creación de un archivo arrastrando y depositando un documento o enlace del sistema operativo u otra aplicación• Permitir a los usuarios construir consulta de búsquedas y especificar el criterio de

la búsqueda visualmente, y no a través de la búsqueda de una expresión de lenguaje escrita;

• Mostrar los resultados de las búsquedas de una forma que permita a los usuarios interactuar directamente con e inspeccionar las entidades resultado de la búsqueda;

• Permitir interacción gráfica con los resultados de la búsqueda, tales como columnas de reordenación, y así sucesivamente;

• Posiblemente permitir a los usuarios ver directamente el contenido de los documentos a través de la interface gráfica de usuario, o acceder y descargar contenido de los documentos;• Mostrar a los usuarios las operaciones a las cuales están autorizados a trabajar en una

entidad, antes de que las intenten;• Suministrar vistas de desempeño específico para usuarios con esas

responsabilidades, por ejemplo, permitir a los directores de archivo monitorear y llevar a cabo el proceso de eliminación;

• Permitir a los usuarios llevar a cabo operaciones en entidades fácilmente con el menor número posible de pasos suministrando ayudas tales como menús contextuales y de aplicación, barras de herramientas, teclados combinaciones clave, y así sucesivamente;

• Suministrar feedback cuando las operaciones se demores más de un segundo, por ejemplo, a través del uso de íconos de ocupado y barras de progreso;

• Suministrar feedback visual y en lo posible auditivo sobre los resultados de todas las operaciones, indicando claramente cuando han sido exitosas y cuando han fallado;

• Cuando las operaciones fallen, suministrar mensajes significativos al usuario que indiquen que ha fallado, preferiblemente porqué falló, y que hacer acerca de eso;• Atender a los usuarios con necesidades especiales adhiriéndose a las directrices de

accesibilidad y, por ejemplo, apoyando la ampliación de pantalla, presentando la misma información de diferentes maneras tales como usando un color y subrayar los hipervínculos, y así sucesivamente;

• Permitir a los usuarios personalizar su propia experiencia de la GUI, por ejemplo, seleccionando los colores de defecto, tamaño de fuentes, y ordenando los elementos de la IGU en diferentes lugares; y• Suministrar inmediatamente la asistencia disponible a los usuarios, como ayuda

sensible, guías de usuarios on line, preguntas frecuentes (FAQ por sus siglas en inglés), tutorias, asistentes, acceso a apoyo de ayuda en escritorio, y así sucesivamente.

Un SDCM puede también utilizar su interface gráfica de usuario para facilitar el trabajo colaborativo:

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 219 of 520• Mostrando los usuarios que estén accediendo actualmente al sistema de documentos;• Facilitando comunicación, chats, compartimiento de pantalla y tableros electrónicos, o

su equivalente, entre usuarios que estén usando el sistema de documentos simultáneamente;

• Permitiendo a los usuarios enviar mensajes a individuos o grupos de otros usuarios;• Permitiendo a los usuarios colocar notas adicionales contra entidades en el sistema de

documentos para beneficio de otros usuarios;

• Promoviendo el uso de y en lo posible hosting blogs y discusiones en línea;• Permitiendo a los usuarios crear listas de tareas que se refieran a entidades en el sistema de documentos;• Extendiendo el uso de listas de tareas a grupos enteros en vez de a usuarios individuales;• Promoviendo el uso de y en lo posible hosting calendarios individuales y de grupo

que muestren eventos y tareas próximos;• Permitiendo a los usuarios referir tareas importantes, como complejas decisiones

en la revisión de eliminación a otros usuarios más expertos; y • Suministro de cuadros de mando para monitorear el uso y status del sistema de documentos, tales como resumen de documentos oportunos y vencidos para eliminación.

Un SDCM no le debe permitir a su interface gráfica de usuario:

• Acceder el sistema de archives si no están autorizados para este acceso;• Mostrar a los usuarios que entidades existen que ellos no estén autorizados a inspeccionar;• Permitir a los usuarios realizar operaciones que ellos no estén autorizados a realizar;

101.2.3 Consideraciones Organizacionales

Una organización que use un SDCM con una interface gráfica de usuario puede desear ajustarla de manera particular, por ejemplo, de modo que:

• Muestre un logo corporativo;• Use colores corporativos, esquemas y fuentes;• Use defecto corporativo.• Incorpore los propios términos y condiciones para acceso y uso;• Refiera las preguntas de soporte a una mesa de ayuda corporativa en lugar de soporte a nivel de proveedor;• Tenga guías de usuario personalizadas, preguntas frecuentes, tutorías y asistentes; y• Tenga un diseño predeterminado y presentación decidas a un nivel organizacional.

La organización debe también estar consciente de las implicaciones de seguridad de tener parte del sistema de documentos instalada en los computadores personales de sus usuarios y estaciones de trabajo, haciendo preguntas como:

• Esconde documentos, contenido de archives u otros elementos localmente?• Lo Escondido está encriptado?• Que tan fácil es sobrepasar o evitar sus controles de seguridad?• Que tan segura es la comunicación entre la aplicación del cliente y otras partes

basadas en servidor del sistema de documentos?• Está ésta comunicación encriptada?

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 220 of 520• Se puede acceder al sistema de archives de forma remota, por ejemplo, a través de computadores de terceros en cafés Internet, etc.?

Estas consideraciones pueden también ser necesarias para otros tipos de interface de usuario, diferente de la interface gráfica de usuario.


R101.4.1

De acuerdo con los requerimientos básicos de servicio R2.4.6, el SDCM debe implantar una interface gráfica de usuario (IGU) que permita a los usuarios autorizados tener acceso a la funcionalidad total especificada por el servicio ó el paquete de servicios.

El término “IGU” describe cualquier interface principalmente visual que es controlada por un operador humano.Las IGUs pueden ser contrastadas con las interfaces de comando en línea donde los sistemas son controlados escribiendo instrucciones u órdenes en una terminal.

Para ser certificado como compatible con MoReq2010®, la IGU no debe implementar solamente una parte de la funcionalidad especificada por MoReq2010® para el servicio o el paquete de servicios cubierto.

R101.4.2

El SDCM debe mostrar entidades de una manera consistente que permita a los usuarios reconocerlas por tipo de entidad, identificarlas por Título u otros metadatos y ver inmediatamente su status.

Por ejemplo, un usuario debe estar en capacidad de diferenciar inmediatamente una clase de una reunión o un cronograma de eliminación.

R101.4.3

El SDCM debe mostrar, por defecto, únicamente las entidades activas, pero debe permitir a los usuarios mostrar las entidades activas y las residuales.

Por defecto, las entidades residuales no deben ser visibles en la IGU. Cuando un usuario elige mostrar las entidades activas y las residuales, entonces su status debe ser claramente indicado, bajo R101.4.2.

Ver también R2.4.22 y R10.4.17.

R101.4.4

El SDCM debe permitir a los usuarios autorizados crear nuevas entidades y agregarlas al sistema de documentos, especificando valores para sus metadatos, incluyendo metadatos contextuales.

Por ejemplo, los usuarios autorizados deben estar en condición de agregar nuevas clases al servicio de clasificación, nuevos agregados al servicio de documentos, nuevos cronogramas de eliminación al servicio de cronograma de eliminación, nuevos dominios de eliminación al servicio de dominio de eliminación, etc.

Dependiendo de la naturaleza del SDCM puede también permitir a los usuarios crear nuevos documentos de manera ad hoc, arrastrando y soltando documentos y enlaces de un sistema operativo u

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 221 of 520otras aplicaciones. Para otros tipos de SDCM la creación de documentos será más estructurada.

Los valores de metadatos pueden ser suministrados por el usuario, o el SDCM puede generar valores (Por ejemplo el Identificador de Sistema), o suministrar valores por defecto, o el SDCM puede estar en condición de extraer automáticamente valores de metadatos del contenido de los nuevos documentos. En todos los casos, todos los valores obligatorios de metadatos deben estar presentes antes de que la nueva entidad sea creada en el SDCM.

R101.4.5

El SDCM debe facilitar la inspección de entidades mostrando sus metadatos, incluyendo metadatos contextuales, a solicitud y permitiendo que sus valores sean modificados por un usuario autorizado de acuerdo con los otros requerimientos del MoReq2010®.

El MoReq2010® no e specifica cómo puede un usuario solicitar una vista de los metadatos de una entidad a t r a v é s d e u n a IGU.

R101.4.6

El SDCM debe suministrar un usuario autorizado creando una entidad, bajo R101.4.4, o adicionando o modificando metadatos, bajo R101.4.5, con ayuda automatizada para completar la tarea, en su caso, y debe permitir al usuario buscar y encontrar entidades para agregar a los metadatos en tanto los modifica.

La ayuda puede ser suministrada por listas de selección pop up, autocompletado, correctores ortográficos, máscaras de formato, ayuda sensible de contexto, etc. Buscar y agregar entidades es necesario para muchas diferentes labores, por ejemplo, especificando la clasificación de un agregado, o anulando el cronograma por defecto de eliminación de un archivo.

R101.4.7

El SDCM debe asegurar que los usuarios autorizados no pueden modificar los valores de los metadatos de lectura solamente y no pueden registrar valores para metadatos contrarios al tipo de datos del elemento.

El SDCM debe hacer cumplir y apoyar el registro del formato correcto de metadatos incluyendo cualquier limitación especificada por la definición del elemento de metadatos y su tipo de datos especificado.

R101.4.8

Además de los metadatos, bajo R101.4.5 el SDCM también debe permitir a un usuario autorizado ver, y, si está autorizado, modificar la lista de control de acceso (o el equivalente) a una entidad.

El modelo de servicio de la función del MoReq2010® no especifica ninguna forma en particular en la cual el acceso a entidades deba ser controlado y gestionado, siempre que cumpla con los principios generales de control de acceso especificados por el MoReq2010® y esté en condiciones de ser exportado como una lista de control de acceso compatible con el MoReq2010®.

R101.4.9

El SDCM debe mostrar visualmente las relaciones entre entidades y permitir a los usuarios autorizados navegar en estas relaciones.

Por ejemplo, el SDCM debe permitir a un usuario inspeccionar un agregado, navegar e inspeccionar su clasificación, navegar e inspeccionar su historia de eventos, navegar e inspeccionar

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 222 of 520sus documentos de niños, navegar e inspeccionar sus cronogramas de eliminación, navegar e inspeccionar sus componentes, etc.

El MoReq2010® no especifica cómo s e d eb en mos t r a r l a s r e l a c i on es e nt r e e nt i dad es en u na IGU, o el tipo de vista requerido.

R101.4.10

El SDCM debe guiar al usuario mostrando que operaciones están disponibles para realizar en una entidad, y permitir al usuario elegir entre las operaciones disponibles.

La IGU d e b e a d a pt a r r e s p o n s a b l e m e n te s u display a la autorización disponible para el usuario actual. No debe mostrar la misma paleta de operaciones disponibles a todos los usuarios sin facilitar una guía visual para saber que sub-set de operaciones están disponibles para el usuario actual.

Por ejemplo, un menú de contexto contiene una lista complete de operaciones que pueden ser llevadas a cabo en una entidad de un tipo particular. Si el usuario presente no tiene los controles de acceso pertinentes para realizar una de estas operaciones para la entidad seleccionada, entones esa opción debe ser sombreada o retirada del menú. No debe ser necesario para un usuario iniciar una operación antes de ser informado de que no está disponible porque el usuario no tiene suficiente control de acceso.

R101.4.11

El SDCM debe tener la función de búsqueda disponible para los usuarios desde cualquier vista o pantalla, con excepción de las pantallas de configuración y diálogos modales.

El usuario no debe tener que navegar a una pantalla o vista especial para realizar una búsqueda.

R101.4.12

El SDCM debe permitir a los usuarios construir gráficamente búsqueda de preguntas y criterio de búsqueda compleja, seleccionando los términos de búsqueda y buscando las entidades, como se requiere.

A los usuarios de sistemas de archivo con una IGU no se les debe exigir registrar scripts de búsqueda usando un teclado o usar un lenguaje de expresión de búsqueda.

Por ejemplo, para construir un criterio de búsqueda, “Fecha de Origen/Hora es anterior al 1 de abril del 2010”, la IGU podría permitir al usuario escoger la definición del elemento de metadatos, “Fecha de Origen/Hora” de una lista, seleccionar el término de búsqueda, “es anterior a” de otro control sensible al contexto, y luego “1 de abril del 2010” encontrándolo y escogiéndolo de un calendario pop-up.

R101.4.13

El SDCM debe permitir a los usuarios configurar gráficamente los resultados de la búsqueda, incluyendo los elementos de metadatos para ser mostrados, y como se deben ordenar los resultados.

Ver también R10.4.18. El configurar gráficamente los resultados de búsqueda puede incluir el arrastrar y soltar columnas para reordenarlas o dar click en los títulos de las columnas para ordenar mediante ese elemento de metadatos. La IGU debe también apoyar gráficamente la paginación (o el equivalente) de los resultados de búsqueda bajo R10.4.19.

R101.4.14


El SDCM debe permitir a los usuarios autorizados guardar sets de resultados de búsqueda en diferentes formatos de documentos, y potencialmente capturarlos como documentos.

La forma documental de resultados de búsqueda, debe ser similar a un informe detallado, bajo R10.4.24. Por ejemplo, guardar los resultados en un archivo de datos CSV o un archivo de datos PDF. El SDCM puede también estar en condición de capturar directamente los resultados de la búsqueda c o m o u n a r c h i v o , pero este nivel de funcionalidad no se incluye en los servicios básicos del MoReq2010®.

R101.4.15

El SDCM debe permitir a los usuarios autorizados inspeccionar y realizar operaciones en entidades directamente de los resultados de búsqueda.

Cuando la IGU muestre los resultados de una búsqueda entonces las entidades mostradas en la lista deben tener el mismo nivel de funcionalidad como lo tienen en otras partes de la interface. En otras palabras, el usuario debe estar en condición de inspeccionar sus metadatos, navegar en ellos, llevar a cabo operaciones, y así sucesivamente; todo esto sin tener que cambiar de los resultados de la búsqueda a una vista diferente. Ver también R101.4.17.

R101.4.16

El SDCM debe permitir a los usuarios crear accesos directos a entidades que puedan ser compartidos con otros usuarios.

Un acceso directo es una referencia externa a un entidad en el SDCM que puede ser usada para iniciar la apertura de la IGU en una vista particular y mostrando la entidad referida por el acceso directo.

Un ejemplo de un acceso directo es un hipervínculo URI. L o s u s u a r i o s d e b e n e s t a r e n c o n d i c i ó n d e g u a r d a r l o s a c c e s o s d i r e c t o s e n s u e n t o r n o l o c a l y c o m p a r t i r l o s c o n o t r o s u s u a r i o s d e l a IGU ,por ejemplo enviándolos en emails.

R101.4.17

El SDCM debe permitir a un usuario seleccionar un set de entidades del mismo tipo desde el display general, y desde los resultados de la búsqueda, bajo R101.4.13, así como de manera colectiva:

• Reclasificarlos con la misma clase , bajo R6.5.4 o R6.5.12;• Trasladarlos a la misma matriz, bajo R6.5.8 o R6.5.13;• Cambiar sus cronogramas de eliminación al mismo cronograma de eliminación, bajo R6.5.15;• Llevar a cabo revisión de los mismos, bajo R8.4.17, cancelar su transferencia o destrucción, bajo R8.4.18, o confirmar su transferencia o destrucción, bajo R8.4.19 y R8.4.20;

• Asociarlos con el mismo dominio de eliminación, bajo R9.4.3;• Exportarlos, bajo R11.4.3 y R101.4.19; o• Crear un solo acceso directo a un set de múltiples entidades en lugar de a

una entidad individual, bajo R101.4.16.

El MoReq2010® no especifica cómo se deben seleccionar las entidades múltiples a partir de los resultados de búsqueda.


R101.4.18

El SDCM debe suministrar una interface especializada para usuarios autorizados para que participen y completen el proceso de eliminación descrito en 8. Servicio de Cronograma de Eliminación.

En particular, la interface debe permitir a los usuarios navegar e inspeccionar todos los documentos activos que estén a tiempo de ser eliminados, sin tener que realizar una consulta de búsqueda, bajo R8.4.16, incluyendo el permitirles ser agrupados de varias formas, como se ha descrito. La interface debe también facilitar las distintas acciones de eliminación descritas en R8.4.17, R8.4.18, R8.4.19 y R8.4.20, especialmente permitiéndoles ser ejecutados a través de grupos nominados de documentos.

Un comportamiento deseable para esta interface, que no es necesario para el cumplimiento con MoReq2010® incluye:

• Estar en condición de planear anticipadamente los documentos venideros listos para eliminación por día, semana y mes;

• Recopilar, ver y trazar gráficamente estadísticas sobre el rendimiento de la acción de eliminación y promediar el tiempo empleado para llevar a cabo varias acciones de eliminación; y

• Gestionar dominios de eliminación, incluyendo que documentos están siendo mantenidos en la actualidad y determinar que tanto tiempo llevan vencidos para destrucción.

R101.4.19

El SDCM debe suministrar una interface especializada para usuarios autorizados para llevar a cabo el proceso de exportac ión descri to en 11. Servicio de exportación.

En particular la interface debería facilitar lo siguiente:

• Permitir a un usuario conformar una lista de entidades para exportar, bajo R11.4.3, posiblemente seleccionándolos y pasándolos a una lista, bajo R101.4.17;

• Permitir a un usuario seleccionar opciones de exportación, como en R11.4.2;

• Permitir a un usuario iniciar la exportación, monitorear su desarrollo e interrumpirla y reanudarla, bajo R11.4.7; y

• Dar al usuario feedback inmediato sobre cualquier error encontrado y el éxito ó falla de la exportación.

R101.4.20

El SDCM debe suministrar feedback a los usuarios que han iniciado operaciones prolongadas y prever para los usuarios el poder interrumpir cancelar operaciones prolongadas antes de que se hayan completado.

La interface debe específicamente:

• Suministrar feedback al usuario de que el comando ha sido recibido en menos de un segundo, preferiblemente alrededor de 0.1 de segundo para hacer sentir al usuario que la interface responde;

• Suministrar feedback de que la aplicación está procesando la orden si no ha sido terminada en menos de 2 segundos, con un círculo giratorio o un cursor reloj de arena; y

• Mostrar un indicador de progreso y permitir al usuario cancelar el comando si no ha sido completado en menos de 10 segundos.

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 225 of 520Un ejemplo de una operación que pueda ser prolongada y requiera de estas medidas es cuando el usuario inicia una búsqueda.

R101.4.21

Cuando las operaciones no tengan éxito, e l SDCM mensajes de error útiles que expliquen al usuario la naturaleza del error, que sucedió y como proceder.

El SDCM no debe permitir que operaciones iniciadas fallen sin informar al usuario. De la misma manera, los mensajes de error deben ser redactados para que sean claramente entendidos por los usuarios con poca o ninguna experiencia técnica y deben indicar al usuario que hacer acerca del error de modo que el usuario pueda continuar confiadamente.

Note que los mensajes que son meramente informativos o que son advertencias pero no errores deben ser claramente diferenciados de los mensajes de error para no alarmar a los usuarios inadvertidamente.

Los mensajes de error deben ser suministrados en una IGU además del registro de operaciones fallidas, bajo R2.4.8, y no son un sustituto del presente requerimiento.

R101.4.22

El SDCM debe suministrar ayuda fácilmente accesible desde sus pantallas y vistas, incluyendo desde sus diálogos modales, para usuarios que:

• No saben navegar su interface gráfica de usuario;• No entienden la consecuencia de una operación;• No saben crear entidades;• No saben modificar metadatos;• No saben construir consultas de búsqueda y criterios de búsqueda, especialmente aquellas que son complejas,• No saben dónde encontrar los controles para acciones y operaciones,• No saben que hacer acerca de los errores del sistema, y• Quieren aprender más acerca del sistema.

La ayuda puede ser suministrada de muchas maneras, incluyendo instrucciones, manuales, preguntas frecuentes, asistentes y tutorías.La ayuda debe estar relacionada con el proceso que el usuario está llevando a cabo. Más detalle es suministrado en el requerimiento no-funcional N101.5.11.

101.5 Requerimientos no Funcionales

N101.5.1

El tipo de interface gráfica de usuario usada dependerá del entorno de la operación y la plataforma.

Adicional a las repuestas a N12.3.1 y N12.6.1, que tipos de IGU does soporta el sistema de documentos y en que interfaces y sistemas operativos se encuentran disponibles estas interfaces?

N101.5.2

Las buenas IGUs t i e n e n una razón de ser que ofrece consistencia a través de la interface. E l u s u a r i o a p r e n d e a e s p e r a r d e l a IGU que responda de cierta forma. La IGU puede usar íconos para representar diferentes tipos y estados de entidad. La IGU también hará fácil ver la diferencia entre entidades activas e inactivas, ó funciones que se pueden llevar a cabo y aquellas que

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 226 of 520no.

Para cada una de las IGUs relacionadas bajo N101.5.1, que es el enfoque de diseño tomado por la IGU, incluyendo:

• Cómo hace uso de elementos gráficos tales como íconos e imágenes?• Cómo mantiene consistencia través de la interface?• Cómo ayuda al usuario a realizar funciones?

De ejemplos cuando sea necesario.

N101.5.3

La ergonomía es un juicio importante aunque subjetivo de todas las IGUs. Por ejemplo, cuantos clicks y movimientos del mouse se necesitan para realizar una función comúnmente usada? Las mejores IGUs son descritas frecuentemente como amigables e intuitivas para usar.

Cual es el promedio y el mayor número de acciones del usuario (por ejemplo, clicks d e l mouse ó toques del dedo) requeridos para acceder cualquier pantalla ó dialogo en la interface del sistema de documentos, ó completar cualquiera de las funciones MoReq2010® de la vista por defecto ó pantalla principal (home screen) de la aplicación?:

• Crer un archive en una agrupacion?• Busacar una entidad por su tipo usando un solo criterio de búsqueda?• Inspeccionar los metadatos de una entidad en un set de resultados de búsqueda?• Navegar desde el primer archivo hasta el último en una agrupacion de 100 documentos?

(La respuesta debería esbozar lo que es la vista por defecto ó pantalla principal, y lo que es cada una de las acciones del usuario, que son requeridas para llevar a cabo una función típica y describir una función que emplea un número promedio de acciones de usuario, así como la función que requiere el mayor número de acciones del usuario.)

N101.5.4

Una IGU puede usar gestos comunes correspondientes a la interface para permitir al usuario realizar funciones. Por ejemplo, puede permitir que los documentos sean capturados arrastrando y soltando documentos de datos desde el computador del usuario.

Cómo usa la IGU acciones comunes, tales como desplazamiento y zoom, de manera apropiada para ayudar a que el sistema de documentos sea más fácil de usar y útil?

N101.5.5

Una IGU frecuentemente soportará la personalización del usuario. Elementos alternativos de la IGU, tales como colores, diseño, fuentes y tamaños de fuente pueden también estar disponibles en diferentes dispositivos, tales como desktops, notebooks, tablets y smartphones. El usuario tal vez desee configurar estas opciones de personalización de manera diferente para cada factor de forma. La personalización requiere que estos elementos, una vez cambiados sean salvados y permanezcan con el usuario particular de sesión en sesión y de dispositivo a dispositivo, como el usuario lo seleccione.

Existen muchas formas en las cuales un usuario puede personalizar una IGU, puede involucrar algunas o todas las siguientes opciones:

• Inclusión en la interface de listas de entidades usadas recientemente, ver N101.5.8;• Inclusión en la interface de una lista de entidades favoritas, ver N101.5.9;

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 227 of 520• Habilidad para configurar colores, fuentes y tamaños de fuente de la pantalla;• Habilidad para reordenar elementos de la pantalla, vistas y columnas;• Habilidad para configurar un default personal criterio de ordenación para listas y vistas;• Habilidad para especificar la vista donde abrirá la aplicación ó tener la aplicación

siempre abierta en la vista más reciente;• Mantener seguimiento de la ubicación del usuario en la aplicación usando una ruta de navegación ó su equivalente;• Permitir a los usuarios navegar de Nuevo a pantallas y vistas previas, ver N101.5.8; y• Suministrar una habilidad para crear búsquedas personales guardadas y definiciones de

informes guardados, ver R10.4.23 y R10.4.27.

De que formas puede ser personalizada la IGU para satisfacer usuarios individuales, y pueden estas configuraciones ser guardadas o salvadas como un default personal del usuario?

N101.5.6

También se pueden configurar las alertas auditivas y notificaciones.

Usa la IGU alertas auditivas y notificaciones, y pueden las configuraciones de alertas auditivas, notificaciones y volumen ser individualmente ajustadas y personalizadas bajo N101.5.5?

N101.5.7

Puede ser posible navegar en la IGU y realizar funciones usando comandos de voz solamente.

Responde la IGU a comandos de voz y, si es así, cómo es la cobertura de los comandos de voz comparada con la funcionalidad requerida por MoReq2010®?

N101.5.8

Muchas IGUs almacenan los sitios que un usuario visita y las entidades a las que un usuario entra. Esta lista proporciona un medio para que los usuarios retornen a entidades que ellos han creado, inspeccionado ó modificado recientemente sin tener que buscar o navegar para encontrarlas.

Proporciona el sistema de documentos acceso fácil a entidades recientemente visitadas a través de la IGU de manera que el usuario pueda encontrarlas y acceder a ellas luego sin tener que buscar?

N101.5.9

Algunas IGUs permiten a los usuarios adicionar entidades a una lista de favoritos. Esto permite a los usuarios encontrar y acceder estas entidades favoritas más fácilmente sin tener que navegar o buscar para encontrarlas. Esta es una característica potencialmente importante porque los usuarios pueden necesitar frecuentemente tener acceso solamente a un pequeño número de agrupacioneses para realizar la mayor parte de su trabajo diario capturando, declarando y remitiendo a los documentos. Muchos usuarios desearán mantener estas agrupacioneses a la mano, en cambio de tener que buscarlas constantemente. Otro buen uso de la lista de favoritos es mantener salvados búsquedas e informes que son regularmente ejecutados por el usuario, ver R10.4.23 y R10.4.27.

Permite el sistema de documentos a los usuarios mantener una lista de entidades favoritas y acceder a ellas fácilmente a través de la IGU?

N101.5.10

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 228 of 520Es importante que las notificaciones informativas y los mensajes de error a los usuarios sean inteligibles, informativos y amigables. Cada notificación, mensaje ó dialogo deberá también indicar las acciones disponibles para los usuarios, y cuando sea posible, sugerir que hacer en seguida.

Cómo maneja la IGU las notificaciones de usuario, condiciones de error y funciones fallidas; y son los mensajes a los usuarios útiles sugiriendo una solución ó un curso de acción?

N101.5.11

El grado de ayuda y asistencia suministrado por la IGU bajo R101.4.22 es extremadamente importante. Cuando sea posible, la ayuda debe ser sensible al contexto. La ayuda no está necesariamente restringida a la información basada en el texto, puede contener imágenes y diagramas, videos incrustados, tutorías en línea y otras técnicas de aprendizaje.

Además de R101.4.22, que tipos de ayuda en línea están disponibles a través de la IGU, y en diferentes partes de la IGU, y cómo es esto útil ayudando a los usuarios a llevar a cabo funciones y aprender acerca del sistema de documentos?

101.6 Glosario de Términos

Término Explicación y relación con conceptos generales

Pantalla de Configuración

(sustantivo) “ajustes” de pantalla ó vista destinada principalmente a ayudar a configurar el SDCM, pero no usada en las operaciones diarias. Esto puede incluir opciones que los usuarios regularmente no encuentran.

Ver también pantalla.

Dialogo (sustantivo) ver diálogo modal.

Exhibir (verbo) Mostrar a un usuario de una IGU, especialmente presentando información en una pantalla. Una IGU puede mostrar varias entidades como texto, imágenes ó íconos, ó una combinación de cualquiera de éstos. Relaciones entre entidades pueden ser mostradas usando elementos gráficos como líneas y flechas, ó pueden ser evidentes por su ordenamiento y proximidad.



Mensaje de error (sustantivo) Un indicador gráfico para un usuario para quien una función u operación particular ha fracasado, típicamente una función u operación que ha sido iniciada por el usuario. Existen varias maneras de suministrar un mensaje de error al usuario de una IGU, incluyendo un dialogo modal.

Retroalimentación (sustantivo) Ver feedback visual.

Gráfico (adjetivo) Principalmente visual, usando los atributos naturales y ventajas de una interface gráfica de usuario.

Interface Gráfica de Usuario

(sustantivo) Una interface a un sistema de información, usualmente abreviado a “IGU”, que presenta entidades y sus relaciones como imágenes, íconos, e indicadores visuales así como también usando texto. Una IGU puede presentar información en diferentes ventanas o pantallas. Los usuarios pueden manipular los objetos que son mostrados en la IGU usando una variedad de métodos de entrada incluyendo teclados, mouse y otros dispositivos de señalización, así como a través del tacto y los gestos. Una IGU típicamente permite a los usuarios seleccionar una entidad, o entidades, y realizar operaciones en ella.

IGU (sigla) Una interface gráfica de usuario.

Pantalla de inicio (sustantivo) La página de destino ó vista de un SDCM que un usuario no especializado puede ver por default. Desde la pantalla de inicio un usuario puede esperar poder inmediatamente navegar, buscar e inspeccionar las entidades en el SDCM. Dependiendo del propósito del SDCM, el usuario puede también esperar crear documentos y acceso al contenido de documentos desde esta vista.


Diálogo modal (sustantivo) Una notificación, usualmente en forma de window pop-up, que hay que reconoce, o desechar, o tomar alguna acción antes de que el usuario pueda continuar usando la IGU.

Navegar (verbo) Cambiar pantallas o vistas, navegar las relaciones entre entitdades, inspeccionar las entidades, y cambiar la entidad que es el centro de la IGU por manipulación directa de los objetos de la pantalla.



Personalización (concepto) Cambiar elcarácter y experiencia de una interface stándard de usuario y personalizándola al gusto personal del usuario. Muchas aplicaciones proveen opciones para reordenar una pantalla en una IGU para reflejar la preferencia personal, por ejemplo, cambiando el tamaño, color, posición y fuentes usadas por los objetos de la pantalla. Cuando el usuario invierte tiempo y esfuerzo personalizando es importante que el SDCM “recuerde” estos cambios de manera que puedan ser reusados en la próxima sesión.

Pantalla (sustantivo) Una pantalla, una vista, una ventana o una interface, dependiendo de la naturaleza de la IGU. cada aplicación de IGU es típicamente hecha de varios screens diferentes con diferentes funciones. En los requerimientos funcionales y nofuncionales se prevén por lo menos cuatro tipos diferentes de screen o interface:

• Configuración de pantalla,• Pantalla de inicio,• Interface especializada de eliminación, e• Interface especializada de exportación.

Debe tenerse en cuenta que éstas son hipótesis de diseño basadas en el agrupamiento de diferentes tipos de funcionalidad que la IGU debe apoyar. Su intención no es imponer restricciones innecesarias en el diseñador de la IGU ni en el proveedor del SDCM, siempre y cuando la aplicación en cierta forma coherentemente facilite estos diferentes aspectos para gestionar y usar un sistema de documentos.

Acceso directo (sustantivo) Un hiperenlace URI u otra referencia externa a una entidad o entidades en un SDCM que puede ser compartido con otros usuarios. Por ejemplo, un usuario puede enviar un email a otro, conteniendo un acceso directo a un archivo, en lugar de enviar el contenido del archivo como un anexo. Cuando se inicia el acceso directo accede el SDCM y permite al usuario hallar inmediatamente la entidad.



Interface especializada de eliminación

(sustantivo) Una interface que facilita el proceso de eliminación. Normalmente los administradores de documentos necesitan involucrarse con éste proceso para llevar a cabo las siguientes actividades de forma regular:

• Anticipar, monitorear y gestionar los documentos próximos a eliminar;

• Realizar revisiones y registrar las decisiones de las revisiones;• Asegurar que las transferencias sean completadas con éxito y confirmadas;• Ejecutar y confirmar la destrucción del contenido de los documentos cuando se requiera confirmación manual; • Cerrar agrupaciones cuando sea apropiado ; y• Responder a las alertas.

Existen otras muchas actividades periféricas que también podrían ser incluidas en ésta actividad especializada, como crear y levantar la retención de la eliminación, la gestión de programación de la eliminación, etc.


Interface especializada de exportación

(sustantivo) Una interface que facilita el Proceso de exportación. Corrientemente los usuarios autorizados necesitarán hacer lo siguiente:

• Seleccionar documentos y otras entidades para exportar, basados posiblemente en exportaciones previas o en si las entidades han sido actualizadas desde la última vez que fueron exportadas;

• Suministrar un comentario de exportación explicando la exportación, y posiblemente un nombre para el archivo de

datos de exportación y otros detalles;• Determinar a donde exportar el archivo de datos, esto podría ser una ubicación de red de almacenamiento, otro sistema de negocios, a través de un canal cifrado en internet, o similar;• Iniciar y monitorear la exportación;• Luego de la terminación éxitosa , posiblemente continúe La gestión de la exportación y cualquier exportación anterior en una ubicación segura.

Las tareas específicas y la naturaleza de la interface dependerán de la solución individual del SDCM.



Vista (sustantivo) Ver pantalla.

(verbo) inspeccionar Visualmente.

Ver también inspeccionar.


Retroalimentación Visual

(sustantivo) Una de las atracciones de una IGU es que los usuarios sienten que están de verdad manipulando objetos reales en vez de simplemente representaciones gráficas bidimensionales de entidades lógicas. Como resultado, es importante que la IGU sea sensible y el feedback visual es esencial para la experiencia del usuario. Si los usuarios realizan una función y parece no suceder nada, incluso si es solo por unos segundos, entonces la experiencia del usuario puede ser seriamente degradada.

Ventana (sustantivo) Ver pantalla.


102. Interface de Aplicación de Programación (IAP)

102.1 Información del Módulo

Nombre del Módulo Interface de Aplicación de Programación (IAP)

Versión del Módulo 1.0

Implementa identificadorDe módulo (ver M14.4.41)

654633ec-8b17-4a3c-a483-436ee2bd506a



102.2 Conceptos Clave

102.2.1 Acerca de las interfaces de aplicación de programación

Una interface de aplicación de programación o IAP es una interface publicada y estandarizada para un sistema de información, como un sistema de archivo, que permite a otro software interactuar con él. Existen muchos tipos de IAPs para diferentes lenguajes de programación, plataformas y entramados. Un ejemplo de una IAP es un conjunto de una ó más definiciones de servicio web.

La provisión de una IAP evita la necesidad de un sistema de documentos para proveer directamente para cualquier usuario humano. El “usuario” del SDCM es efectivamente el sistema externo. Un usuario humano puede interactuar con el SDCM indirectamente a través del sistema externo ó la interacción puede ser totalmente automatizada. Por ejemplo, un sistema de almacenamiento puede interconectar con un sistema de archives a través de una IAP para automáticamente guardar facturas, entrega de expedientes y órdenes de compra conforme se hayan producido recibido. En éste ejemplo, las agrupacioneses pueden ser creadas automáticamente cuando cuentas de nuevos clientes sean registradas en el sistema de almacenamiento y ser cerradas cuando las cuentas de los clientes sean borradas; las clases y cronogramas de eliminación pueden ser pre-configuradas y aplicadas automáticamente; y puede haber poca ó ninguna interacción directa con el sistema de documentos, excepto por ó a través del sistema de almacenamiento.

El presente módulo contiene requerimientos para un SDCM que implementa una IAP.

102.2.2 Cumplimiento Técnico

El Req2010® define una IAP como una colección de “métodos” que pueden ser evocados por una aplicación externa. Para un SDCM, estos métodos implantan la funcionalidad descrita para la especificación del MoReq2010®. Es importante que un SDCM tenga un conjunto completo IAP si va a ser certificado como compatible con éste módulo.

Usualmente, cada función del MoReq2010® corresponderá a una sola llamada de método en el conjunto de la IAP, y no debe ser necesario a través de la IAP llamar más de un método para realizar una sola función definida por la especificación.

Se deben incluir suficientes métodos en el conjunto IAP para proporcionar una gama completa de funcionalidad para por lo menos un servicio del MoReq2010®, o un conjunto

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 234 of 520de servicios, ver R2.4.6.

Algunos sistemas de documentos pueden proporcionar solamente conjuntos parciales IAP los cuales incluyen solamente parte de la funcionalidad especificada por el MoReq2010

®. Cuando esto suceda los req uerimientos de presente módulo pueden proporcionar una guía útil para las expectativas del MoReq2010

® alrededor del suministro de una IAP, pero un sistema de documentos que parcialmente confiable para un servicio determinado, ó un conjunto de servicios, en otro tipo de interface además de su IAP, no puede ser certificado para cumplimiento bajo las disposiciones del presente módulo.

Para evaluar la calidad e integridad de un conjunto de IAP, el proveedor debe proporcionar un centro de pruebas acreditado con un manual para su IAP describiendo:

• Cómo las aplicaciones de terceros hallan y se conectan a la IAP; y• Los métodos del conjunto de la IAP incluyendo pre y post-condiciones.

Además de lo anterior, los proveedores que deseen que sus conjuntos IAP sean probados para cumplimiento deben proporcionar al centro de pruebas un instrumento de prueba o concha para permitir que la prueba se lleve a cabo. Los centros de prueba acreditados no deben escribir sus aplicaciones de terceros para facilitar la prueba de un conjunto de IAP.

102.2.3 Consideraciones del conjunto de IAP

Los conjuntos de IAP son escritos para diferentes propósitos. A veces los proveedores pretenden que sean interfaces de propósito general y animar aplicaciones de terceros que sean escritas apoyándolos. En otras ocasiones se pretende que proporcionen una estrecha integración con un solo producto de un tercero, quizás uno que no tiene reconocimiento en la gestión de funcionalidad de documentos. En el último caso, la IAP generalmente es patentada y el acceso de terceros no es recomendado por parte de los proveedores.

En cualquiera de los dos casos, la presencia de interacción vía una IAP no deberá eximir un SDCM de la responsabilidad de asegurar que:

• Se le de a los documentos un adecuado contexto de negocios a través de una clasificación adecuada;• Que el historial contenga adecuada información de auditoría acerca de que usuario

realizó una función particular;• Que los controles de acceso sean establecidos y mantenidos, y los usuarios no

autorizados no puedan acceder y manipular las entidades en el SDCM;• Que el proceso de eliminación descrito en 9. Servicio de Cronograma de

Eliminación sea adecuadamente gestionado y que las decisiones adecuadas de eliminación sean tomadas oportunamente; y

• Que los archives de otras entidades puedan ser exportados totalmente desde el SDCM, como se especifica en 13. Servicio de Exportación.

En particular, los conjuntos de IAP pueden ser problemáticos atribuyendo acciones en el sistema de documentos a usuarios particulares. Por ésta razón, no obstante la aplicación externa es técnicamente el usuario del sistema de documentos, se debe tener cuidado de que el sistema externo suministre información vía la IAP relacionada con quien fue el usuario real que inició la acción que condujo a que la llamada a la IAP fuera iniciada.

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 235 of 520102.4 Requerimientos Funcionales

R102.4.1

De acuerdo con el requerimiento de servicios básicos R2.4.6, el SDCM debe implantar una Interface de Aplicación de Programación (IAP) que contenga un conjunto de métodos que permitan a los usuarios autorizados acceder a la funcionalidad total especificada por el servicio o conjunto de servicios, bajo

R2.4.1.

El término “IAP” describe cualquier interface que es accedida por una aplicación de cliente u otro sistema de negocios, en lugar de por un operador humano. Un operador humano puede interconectarse con el sistema de negocios y manipular directamente entidades en el SDCM, pero no existe interacción directa con la gente.

Para ser certificado como compatible con el MoReq2010, la IAP no debe implantar solamente una parte de la funcionalidad especificada por el MoReq2010® para el servicio o conjunto de servicios cubiertos.

R102.4.2

El SDCM tiene que apoyar llamadas multi-usuario, asincrónicas a los métodos en su conjunto IAP.

Un usuario, aplicación ó hilo accediendo el SDCM vía una llamada de método no debe bloquear a otros usuarios, aplicaciones ó hilos, para acceder simultáneamente el SDCM y hacer llamadas de método.

R102.4.3

El SDCM debe asegurarse que cada llamada de método, bajo R102.4.1, es realizada por un usuario autenticado y que todas las funciones y eventos son atribuidas a un usuario individual del SDCM autorizado para llevar a cabo esa función para la entidad en la cual es realizada.

No es suficiente para todas las funciones realizadas en un SDCM ser atribuidas a un solo usuario, siendo ese usuario el servicio externo que llama la IAP. Esto no proporciona suficiente contexto para una eficiente rendición de cuentas cuando se construya ó interprete la historia de eventos.

R102.4.4

El SDCM debe asegurarse que cada llamada de método, bajo R102.4.1, retorne un código de error que indique el éxito o falla de la llamada.

El proceso de llamada, aplicación ó sistema no debería tener que hacer una segunda llamada de método para hallar el resultado de una llamada de método anterior.

El MoReq2010® no especifica que llamadas de método ó códigos error deberían ser usados por una IAP.

R102.4.5

El SDCM debe proporcionar un método que retorne a información suficiente sobre el error para el código de error retornado bajo R102.4.4.

La información sobre el error deberá ser la misma, ó equivalente, a la retornada bajo R2.4.8. Nótese que esto no remplaza el requerimiento para un n SDCM de mantener un registro de errores bajo R2.4.7.

R102.4.6

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 236 of 520El SDCM debe proporcionar un método ó métodos que retornen, para cualquier entidad, las operaciones admisibles para ese usuario actual con respecto a esa entidad.

El MoReq2010® no especifica cómo se deben implantar ese método ó métodos. E l s aber acerca de las operaciones admisibles para cualquier entidad dada permite al usuario actual de la IAP hallar que métodos pueden ser llamados para la entidad sin tener que llamar específicamente cada operación.

102.5 Requerimientos no funcionales

N102.5.1

El sistema de documentos puede apoyar gran número de diferentes tipos de IAP y arquitecturas. Por ejemplo, servicios de la web, REST, lenguajes de programación (Java, C++, Python, etc.), Microsoft .NET entramado, SOA, etc.

Que tipo(s) de IAP apoya el sistema de documentos?

N102.5.2

El sistema de documentos puede desempeñarse en diferentes plataformas como aparece bajo, N12.6.1. El sistema de documentos IAP, sin embargo, puede estar disponible en las mismas plataformas, ó puede ser soportado en plataformas separadas. Por ejemplo, el sistema de archives puede funcionar en un servidor Linux pero proporcionar un conjunto Windows IAPt.

Examples of different IAP platforms include, Google App Engine, Amazon EC2, Microsoft WindowsAzure, Microsoft Windows, Linux, Mac OS X, Google Android, Apple iOS, etc.

Para que plataformas proporciona conjuntos de IAP el sistema de documentos?

N102.5.3

El conjunto de IAP puede usar un protocolo específico, como, HTML, SOAP, RPC, TCP/IP, XML, etc.

Que protocolos industriales standard usa la IAP?

N102.5.4

Existe generalmente una curva de aprendizaje asociada con el uso de un conjunto IAP. Se debe suministrar documentación y adquirir un entorno de desarrollo. Las habilidades necesarias para el desarrollo de la IAP pueden ser obtenidas del proveedor ó de una organización que provea entrenamiento, educación y apoyo para la IAP. Alternativamente, la organización puede elegir tener aplicaciones basadas sobre IAP desarrolladas para ella por un tercero.

Además de N12.9.1 y N12.9.2, que habilidades, entrenamiento y educación se requieren para llegar a ser un desarrollador de IAP para el sistema de documentos y en donde se pueden adquirir?

N102.5.5

Puede que no sea necesariamente posible para cualquier desarrollador obtener licencia y usar la IAP, y desarrollar libremente nuevas aplicaciones basadas en la IAP, ni siquiera la organización que compra el sistema de documentos.

Es posible para cualquier elaborador desarrollar para el sistema de documentos IAP o

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 237 of 520tienen que curarse de alguna manera estos elaboradores?

N102.5.6

El conjunto de sistema de documentos IAP puede tener diferentes versiones a la versión del producto principal, ó puede incluso ser un conjunto de producto diferente, y puede ser gestionado de forma semi-independiente.

Separado para N12.14.1, que versión es usada por el conjunto IAP del sistema de documentos?

N102.5.7

Cada versión del sistema de documentos IAP puede agregar nuevos métodos y rechazar los antiguos. Esto debe ser gestionado para asegurar que las aplicaciones IAP ya no se ejecutan con éxito.

Para cada uno de los tipos de comunicado bajo N102.5.6, cómo son introducidas las nuevas llamadas de método en el conjunto del sistema de documentos IAP, y rechazadas las antiguas, y cómo son notificados de estos cambios los elaboradores?

N102.5.8

Un aspecto importante de cualquier conjunto de IAP es la compatibilidad con versiones anteriores.

En relación con N102.5.6 y N102.5.7, puede un código escrito para interconectar con una versión del conjunto IAP ir en contra de versiones anteriores, y bajo que restricciones de compatibilidad?

N102.5.9

Además del programa de apoyo para usuarios, a los e laboradores IAP se les puede brindar ayuda adicional y provisión de apoyo por separado por parte del proveedor.

Además de N12.15.3, N12.15.4, N12.15.5, N12.15.6 y N12.15.7, como es apoyado el conjunto de la IAP y existe una provisión separada para el programa de apoyo?

N102.5.10

El uso del conjunto de la IAP puede requerir garantías adicionales y puede estar sujeto a términos y condiciones adicionales.

Que garantías adicionales bajo N12.16.1, nivel de acuerdos de servicio adicional bajo N12.16.2, ó términos y condiciones adicionales bajo N12.16.3, aplican al conjunto del sistema de documentos de la IAP?




Operación permitida (sustantivo) Un método que puede ser llamado con respecto a una entidad particular por el usuario. El MoReq2010® no requiere que haya uno directo a una asignación entre un método en la IAP y una función que puede ser realizada en una entidad por un usuario autorizado. Por ésta razón, el término “operación permitida” es usado como una descripción más amplia e inclusiva de los métodos que pueden ser invocados por un usuario particular, en una entidad particular, en un momento particular. La razón para requerir que las operaciones permitidas puedan ser halladas es permitir al usuario de una IAP aprender que métodos pueden ser llamados sin tener que llamar a cada uno.

IAP (sigla) Interface de Aplicación de Programación.

Interface de Aplicación de Programación

(Sustantivo) Una interface de software que puede ser usada por una aplicación. Una IAP puede ser descrita como una “interface computador-computador” en contraste con una “interface humano-computador”. Cada IAP tiene una serie de métodos que una aplicación puede llamar. El conjunto completo de métodos incluidos en una IAP es llamado algunas veces “conjunto IAP”. Existen muchas tecnologías y protocolos diferentes que pueden ser usadas para proveer una IAP un SDCM. El MoReq2010® no requiere ninguna tecnología o protocolo particular, siempre que la IAP incluya cubrimiento total de la funcionalidad del servicio, ó paquete de servicios, al cual es aplicado.

Asincrónico (concepto) El principio de que una llamada a una IAP no bloqueará otras llamadas para ser recibidas y procesadas simultáneamente. El uso sincrónico de una IAP fuerza las aplicaciones a esperar que cada llamada se complete antes de que la próxima llamada pueda ser hecha. El uso asincrónico de una IAP significa que las aplicaciones no pueden predecir cuál de dos llamadas superpuestas se completará primero.

Llamada (verbo) Invoca un método el cual envía datos de entrada a una IAP los cuales son entonces procesados por el SDCM. Cada llamada a una IAP típicamente retornara un código de error y puede también retornar otros datos de salida.

Ver también método.

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 239 of 520Término Explicación y relación con conceptos generales

Código de error (sustantivo) Una indicación del éxito o fracaso de una llamada a un método. En el caso de una falla ó de solo éxito parcial, el código de error puede también ser un valor que indica la razón por la cual la llamada no tuvo éxito. Luego de una llamada fallida, y el retorno de un código de error, una IAP debe suministrar información suficiente del error si es solicitada.

Método (sustantivo) Una rutina o´ sub-rutina en la IAP la cual puede ser hallada programáticamente y después invocada por una llamada. Cada método llamado, si tiene éxito, ejecutará una acción, entrará o recuperará datos, ó cambiará alguna propiedad ó valor dentro del SDCM.

Ver también llamada.

Multi-usuario (concepto) Apoyo para múltiples usuarios simultáneos. Un SDCMNo debe permitir acceso a un solo usuario a la vez.


200. SERIES DE CLASIFICACIÓN

201. Clasificación Jerárquica

201.1 Información del Modulo

Nombre del Módulo Clasificación Jerárquica

Versión del Módulo 1.0

Implementa identificadorde módulo (ver M14.4.41)

5c772478-0a49-4391-a1d4-a5cd142a72d1



201.2 Concepto s clave

201.2.1 Estructura de la Clasificación Jerárquica

Muchas organizaciones usan la clasificación jerárquica como una manera simple pero ponderosa de desarrollar un esquema de clasificación para sus negocios. Las estructuras jerárquicas son fáciles de navegar haciendo las clases que contienen fáciles de navegar también.

En un esquema de clasificación jerárquica, las clases son organizadas en una estructura de árbol de varios niveles, como se muestra en la Figura 201a.

Un esquema típico de clasificación de árbol de varios niveles podría ser organizada por función de negocios, y luego dentro de cada función por actividad de negocio, y finalmente dentro de cada actividad por transacción. Sin embargo, los varios niveles son usados comúnmente para clasificación funcional, el MoReq2010® no limita la profundidad máxima de un esquema de clasificación jerárquica, y el MoReq2010® también permite variar el número de niveles a través de una sola estructura de clasificación jerárquica.

Como muestra la Figura 201a un esquema de clasificación jerárquica tiene una ó más clases de nivel superior representando las clasificaciones más amplias, ó más generales, como las funciones organizacionales. Una clase, como una clase de nivel superior, podría ser el padre (parent) de varias clases hijo (child)de nivel inferior. Las clases de nivel inferior representan clasificaciones más estrechas y específicas, como las actividades particulares de negocio y transacciones individuales realizadas en cada función organizacional. Una clase hijo debe tener únicamente una clase padre, y todas las clases excepto una clase de nivel superior debe tener un padre (parent). The ésta forma, la estructura jerárquica puede extenderse y llegar a la profundidad requerida.

Una clase padre en un esquema de clasificación jerárquica no se usa para clasificar agrupacioneses ó documentos. Solamente una clase sin clases hijo (child) debajo de ésta, representando la clasificación disponible más específica puede ser asociada con un archivo ó agrupacion. Una vez que una clase haya sido usada de ésta forma, para clasificar

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 241 of 520agrupaciones o documentos, ya no puede ser una clase padre agregándole clases hijo.

Figura 201a – Las características principales de una clasificación jerárquica son las clases de nivel superior, clases padre e hijo; la jerarquía puede extenderse a

cualquier profundidad pero la mayoría de esquemas de clasificación jerárquica tradicionales adoptan una jerarquía de tres niveles.

201.2.2 Herencia

Una de las principales ventajas de la clasificación jerárquica es que le permite a las clases hijo heredar los atributos de sus padres. E l MoReq2010® aprovecha esto, permitiendo a la herencia de una clase padre:

• Cronograma de eliminación por defecto, y• Dominios de eliminación asociados.

Si el SDCM implementa el servicio de función modelo, las clases hijo heredan:

• Listas de control de acceso.

Si el SDCM implementa el servicio de metadatos modelo, las clases hijo heredan t:

• Plantillas de agrupacion, y• Plantillas de archivo asociadas con la clase padre (si la hay).

201.2.3 Práctica Tradicional con la Clasificación Jerárquica

De acuerdo con especificaciones previas, como el MoReq2®, la clasificación fue siempre jerárquica and y fue aplicada siempre a agrupacioneses de raíz, únicamente. Este enfoque

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 242 of 520require que toda agrupacion hijo y todos los documentos lleven la misma clasificación como su agrupacion de raíz. Este enfoque tradicional se muestra en la Figura 201b.

El enfoque tradicional implica que, a lo largo del servicio de archivo, las agrupacioneses de documentos siempre serán homogéneas ó, en otras palabras, todo archivo en una agrupacion particular siempre haya sido generado por la misma función de negocios, actividad y transacción.

Como muestra la ilustración, el MoReq2010® continua apoyando éste enfoque para aquellas organizaciones que lo requieren.

Figure 201b – La clasificación jerárquica cuando es aplicada a una agrupacion de raíz es heredada como clasificación por defecto para todo los descendientes de esa agrupacion;

esto refleja el enfoque tradicional de clasificación combinada /jerarquías de agrupacion

Cuando se aplica la clasificación jerárquica únicamente a nivel de agrupacion de raíz, toda la estructura combinando clases, agrupacioneses y documentos puede ser conceptualizada como una jerarquía única. De ésta forma, la estructura descrita arriba en la Figura 201b es lógicamente idéntica a esa ilustrada en la Figura 1i (ver 1.4.5 Clasificación y agrupacion en el MoReq2010® servicios básicos), y muestra como el MoReq2010® puede ser usado para la conjunción jerárquica de clasificación y agrupacion, si así se desea.

201.2.4 Usos Alternativos de la Clasificación Jerárquica

La clasificación jerárquica en el MoReq2010® no está restringida, sin embargo, a representar los enfoques tradicionales de clasificación/agrupacion. En común con otros tipos de clasificación, las clases jerárquicas pueden ser usadas para anular la clasificación por defecto heredada de una agrupacion padre de una agrupacion hijo, ó archivo.

Esto sucede cuando una clase es aplicada directamente a una agrupacion particular hijo ó archivo rompiendo así la cadena de defecto de herencia de de la clasificación de agrupacioneses de raíz. Esto se ilustra en la Figura 201c.

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 243 of 520Permitiendo la anulación de la clasificación por defecto de una agrupacion hijo ó archivo individual, el MoReq2010® apoya agrupacioneses heterogéneas que contengan documentos con diferentes clases, como esas generadas como resultado de transacciones separadas de negocios, actividades ó incluso funciones.

Esto permite, por ejemplo, la creación de agrupaciones de proyectos, cuando todos los documentos relacionados con un proyecto particular realizados por una orgnización son agregados juntos, independientemente de que transacción los produce.

Figure 201c – La clasificación jerárquica también puede ser usada de manera no tradicional; para anular la clasificación por defecto a cualquier nivel aplicándola a

agrupacioneses hijo ó directamente a los documentos

En conjunto, las Figuras 201b y 201c demuestran la utilidad de la clasificación jerárquica y muestran como puede ser adoptada y usada tanto en los servicios de archivo tradicionales como en los no tradicionales.

201.2.5 Entidades de Clase Jerárquica

Las entidades e clase y sus atributos se definen en el numeral 5. Servicio de clasificación . Los servicios de clasificación que usan un esquema de clasificación jerárquica implementan un tipo especial de entidad de clase llamada una “clase jerárquica”. Las entidades de clase jerárquica se considera que son iguales en todo respecto a otras entidades de clase, excepto que ellas tienen sistema adicional de metadatos y son restringidas por reglas adicionales de comportamiento al cual otras clases no están sujetas.

Por ejemplo, las clases jerárquicas, diferentes a las clases de nivel superior, tienen clases padre (parent). Esto significa que una entidad de clase jerárquica incluirá su identificador de clase padre como parte de los metadatos de su sistema. Las clases que corresponden a otros tipos de esquema de clasificación no tienen identificadores de clase padre. Las reglas adicionales de comportamiento para clases jerárquicas están definidas por los requerimientos funcionales contenidos en el presente módulo.


201.2.6 Exportación de Esquemas de Clasificación Jerárquica

Cuando las clases son ordenadas en una jerarquía cada clase representa una clasificación más especializada que su clase padre. La clase padre también suministra el contexto más amplio para la clase hijo. El contexto completo es suministrado únicamente manteniendo las relaciones entre los niveles de jerarquía derivados de la clase de nivel superior. Estas relaciones deben ser preservadas cuando las clases jerárquicas son exportadas.

Las reglas de exportación descritas en 11. Servicio de exportación deben extenderse cuando se aplican a clases jerárquicas. Específicamente las clases jerárquicas extienden las definiciones de qué entidades son importantes para otras entidades bajo 11.2.9 Exportación de entidades importantes y que entidades son entidades incluidas bajo 11.2.10 Exportación de entidades incluidas.

Para las clases jerárquicas, las siguientes entidades son importantes:

• Cronograma de eliminación de la clase jerárquica;• Cualquier dominio de eliminación asociado con la clase jerárquica; and• La clase padre de la clase jerárquica, y cualquier clase ascendiente, hasta e incluyendo la clase de nivel superior.

Además, para las clases jerárquicas:

• Las entidades incluidas de clase jerárquica son clases hijo.

Estas reglas extendidas de exportación significan que cuando una clase jerárquica es totalmente exportada, sus clases descendientes deben ser exportadas totalmente con ella. Igualmente, las clases ascendientes de la clase jerárquica, desde su padre hasta la clase de nivel superior sobre ella, debe también ser exportada como marcadores de posición (place holder) para proveerla con el contexto necesario. Esto se muestra en la figura Figura 201d.

Figure 201d – Las clases descendientes de clases jerárquicas que son exportadas deben ser exportadas en su totalidad, mientras que las clases ascendientes de clases

jerárquicas deben sr exportadas como marcadores de posición.

Estas reglas de exportación extendidas también aplican cuando una agrupacion ó archivo es exportada en su totalidad y es clasificada con una clase jerárquica. De acuerdo con el

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 245 of 520numeral 11. Servicio de exportación, la clase jerárquica es una entidad importante y será exportada junto con la agrupacion ó archivo como un marcador de posición. Sin embargo,


Exportar una clase jerárquica única como marcador de posición, no es suficiente para suministrar el contexto total para la clasificación de la agrupacion ó archivo. Es necesario exportar todos los niveles de la jerarquía que apoya la clase jerárquica, desde su padre hasta la clase de nivel superior.

La figura 201e da un ejemplo de esto. En este ejemplo una agrupacion hijo es exportada desde el SDCM y su agrupacion padre es exportada como un marcador de posición. Como lo requiere 11. Servicio de exportación, La clase de agrupacion debe también ser exportada como un marcador de posición, independientemente de si es heredada ó aplicada directamente a la agrupacion que está siendo exportada.

Sin embargo, como lo muestra la Figura 201e, la clase usada para clasificar la agrupacion es una clase jerárquica con su propia clase padre bajo una clase de nivel superior. Todas éstas son clases importantes. En lugar de simplemente exportar la clase de exportación, es necesario, en este ejemplo, exportar todos los niveles de clasificación, incluyendo la clase, su clase padre y la clase de nivel superior, como marcadores de posición, para asegurar que el contexto total de la agrupacion sea suministrado.

Figure 201e – Los marcadores de posición (Placeholders) deben ser exportados para todas las clases jerárquicas hasta la clase de nivel superior que son ascendientes de la clase usada para clasificar agrupacioneses y documentos que están siendo exportados

totalmente.


R201.4.1

Un servicio de clasificación que implementa clases jerárquicas no debe implementar ninguno de los otros MoReq2010®, 200. Módulos de Clasificación de la Serie.

Nótese que un SDCM puede utilizar más de un servicio de clasificación, pero cada servicio de clasificación separado debe contener entidades que pertenezcan solamente a un sub-tipo de entidad de clasificación.


R201.4.2

El SDCM debe asegurar que además de los metadatos presentados en R5.4.2, l a s clases jerárquicas (E201.7.1) sean también creadas con el siguiente sistema de metadatos:

• Identificador de Clase Jerárquica Padre (M201.7.2).

Solamente las clases jerárquicas de nivel superior no tendrán un Identificador de Clase Padre. Las clases hijo pueden heredar sus cronogramas de eliminación y plantillas de sus clases padre.

Los esquemas de clasificación jerárquica deberán apoyar cualquier número de niveles de jerarquía y cualquier número de clases hijo que pertenezcan a una clase padre única.


R201.4.3

El SDCM debe asegurar que todas las clases jerárquicas creadas bajo R5.4.2 y R201.4.2, cumplan lo siguiente :

• Sean creadas sin clase padre como una clase de nivel superior, siempre y cuando estén asociadas con un cronograma de eliminación por defecto activo; ó

• Sean creadas en una clase padre activa que no haya sido usada nunca para clasificación.

Las clases jerárquicas que sean usadas para clasificar agrupacioneses y documentos no pueden llegar a ser clases padre. La Primera Marca de Tiempo (Timestamp) determina si una clase ha sido usada para clasificación.

Una clase jerárquica creada en una clase padre puede heredar el identificador por defecto del cronograma de eliminación y las plantillas de su padre. Todas las clases de nivel superior deben tener un identificador de crononograma de eliminación por defecto.

Referencia de Función: F201.7.4

R201.4.4

Además de R5.4.4, el SDCM debe permitir una clase jerárquica, excepto una clase de nivel superior, heredar su cronograma de eliminación por defecto de clase padre, en lugar de solicitar a un usuario autorizado que la suministre.

El elemento de metadatos, Identificador de Cronograma de Eliminación por Defecto no es requerido para clases jerárquicas, aparte de las clases de nivel superior sin clase padre. Ver también R201.4.3 y R201.4.5.

R201.4.5

Para cualquier clase jerárquica activa, incluyendo una clase de nivel superior, el SDCM debe permitir a un usuario autorizado moverla, ya sea:

• A una clase padre activa que no haya sido usada nunca para clasificación de modo que retenga su cronograma de eliminación original;

• A una clase padre activa que no haya sido usada nunca para clasificación de modo que herede el cronograma de eliminación de su nuevo padre; ó

• Para que se convierta en una clase de nivel superior en tanto que retiene su cronograma de eliminación y plantillas previas.

Para retener el cronograma de eliminación previo de la clase jerárquica, el SDCM debe asegurar que

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 248 of 520un identificador por defecto del cronograma de eliminación sea adicionado a los metadatos de la clase durante la operación de movimiento.

Para heredar el cronograma de eliminación de su nuevo padre, el SDCM debe eliminar de la clase cualquier Identificador por Defecto del Cronograma de Eliminación durante la operación de movimiento.

Nótese que cambiar el cronograma de eliminación de una clase tendrá un efecto cascada en todos los documentos activos clasificados por esa clase, como se describe en R5.4.4.

Refeencias de función: F201.7.3, F201.7.5

R201.4.6

El SDCM debe permitir únicamente una clase jerárquica sin clases hijo para ser usada para clasificar agrupacioneses ó documentos.

Una clase padre, que tenga una ó más clases hijo, puede no ser aplicada a una agrupacion ó archivo .

Cuando una clase jerárquica se aplica por primera vez a cualquier agrupacion ó archivo su Prime

Marca de tiempo (Timestamp), ver R5.4.2, debe ser programada por el SDCM y ya no puede ser una

clase padre bajo R201.4.3 ó R201.4.5.

Referencias de función: F14.5.20, F14.5.138

R201.4.7

El SDCM debe permitir a una clase jerárquica ser borrada bajo R5.4.5 si es una clase padre con una ó más clases hijo.

Los hijos de la clase jerárquica deben ser borrados primero ó movidos antes de que la clase jerárquica pueda ser borrada.


R201.4.8

El SDCM debe permitir a una clase jerárquica ser destruida bajo R5.4.6 si tiene una ó más clases hijo activas.

Una clase jerárquica activa no puede ser hijo ó descendiente de una clase residual. Las clases hijo deben ser destruidas primero, ó concurrentemente, con la clase jerárquica.


R201.4.9

Sujeto a R2.4.22, y además de R5.4.7, El SDCM debe permitir a un usuario autorizado navegar e inspecciona las clases jerárquicas por lo menos de las siguientes maneras:

• Navegar de una clase padre a sus clases hijo e inspeccionar sus metadatos, y• Navegar de una clase hijo a su clase padre e inspeccionar sus metadatos.

Los terminos “navegar ( “browse”) e “inspeccionar” (“inspect”) están definidos en 13. Glosario de

Términos.



R201.4.10

Cuando el SDCM implementa el servicio de función de modelo (ver 4. Servicio de Función de Modelo) entonces, además de R4.5.11 y sujeto a R4.5.10, el SDCM debe permitir a una clase jerárquica hijo heredar funciones activas que han sido concedidas a usuarios activos y grupos de su clase padre.

Las reglas específicas de herencia usadas por el servicio de función de modelo, listadas en la razón fundamental a R4.5.11, deberían ser ampliadas así:

• Las clases jerárquicas hijo heredan de sus clases padre.

Cuando el SDCM no implementa el servicio de función de modelo debe demostrar funcionalidad similar ó equivalente bajo 4.2.4 Cómo cumplir los requerimientos alternativos (tipo B).

R201.4.11

Cuando el SDCM implementa el servicio modelo de metadatos (ver 7. Servicio Modelo e Metadatos), y una plantilla ha sido asociada con una clase jerárquica usando el Identificador de Plantilla de Clase, bajo R7.5.14 ó R7.5.15, entonces la plantilla debe ser aplicada automáticamente, bajo R7.5.18, a cualquier agrupacion o archivo creado con esa clase jerárquica ó con cualquiera de sus clases hijo ó descendientes.

Una plantilla de agrupacion ó puede ser asociada con una clase de nivel superior, ó una clase padre, y será entonces aplicada automáticamente a todas las agrupacioneses y documentos clasificados por cualquier descendiente de esa clase.

Cuando el SDCM no implementa el servicio modelo de metadatos debe demostrar funcionalidad similar ó equivalente bajo 7.2.4 Cómo cumplir los requerimientos alternativos (tipo B).

Referencias de función: F14.5.5, F14.5.121

R201.4.12

El SDCM debe permitir a un usuario autorizado agrupar documentos activos bajo R8.4.16 y realizar funciones relacionadas con la eliminación bajo R8.4.17, R8.4.18, R8.4.19 y R8.4.20 para cualquier clase jerárquica.

Cuando la clase jerárquica es una clase padre entonces la función debe aplicar a todos los archives que son clasificados por cualquiera de los descendientes de la clase jerárquica.

Referencias de función: F14.5.41, F14.5.116, F14.5.117, F14.5.118, F14.5.119, F14.5.120, F14.5.124, F14.5.131, F14.5.177

R201.4.13

Cuando un dominio activo de eliminación es asociado con una clase jerárquica, bajo R9.4.3, el SDCM debe, además de las otras cláusulas de R9.4.4, evitar la destrucción de cualquier archivo que:

• Haya sido clasificado con una clase jerárquica que es un hijo ó descendiente de una clase jerárquica asociada con el cronograma de eliminación.

La asociación de un dominio de eliminación con una clase jerárquica que sea una clase de nivel superior, ó una clase padre, debería tener el mismo efecto de asociar el dominio de eliminación individualmente con cada clase hijo ó descendiente de esa clase.

R201.4.14

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 250 of 520El SDCM debe permitir a un usuario autorizado buscar y encontrar agrupacioneses y/o documentos que son clasificados por cualquier descendiente de una clase jerárquica nominada.

Este requisito extiende R6.5.18 para permitir una búsqueda por una clase nominada para encontrar una agrupacion ó archivo cuando la clase nominada es una clase jerárquica que no es la clase de la entidad pero es el ascendiente de la clase de entidad.


R201.4.15

Cuando las clases jerárquicas son exportadas en su totalidad bajo R11.4.3, entonces el SDCM debe también exportar sus clases hijo y descendiente en su totalidad, como entidades incluidas

Ver 11.2.10 Exportación de Entidades Incluidas y 201.2.6 Exportación de esquemas de clasificación jerárquica para una explicación de entidades incluidas en exportación y su relación con la clasificación jerárquica.


R201.4.16

Cuando clases jerárquicas son exportadas en su totalidad, ó como marcadores de posición, bajo R11.4.3, entonces el SDCM debe también exportar los marcadores de posición para sus clases padre y ascendiente, como entidades importantes.

Ver 11.2.9 Exportación de entidades importantes y 201.2.6 Exportación de esquema de clasificación jerárquica para una explicación de entidades importantes en exportación y su relación con la clasificación jerárquica.


201.5 Requerimientos NO-funcionales

N201.5.1

Los esquemas de clasificación jerárquica pueden imponer limitaciones internas en el número de clases jerárquicas ó niveles de jerarquía apoyados.

Cuales son los límites técnicos en el servicio de clasificación para cada uno de los siguientes:

• El número de clases jerárquicas que puede gestionar?• El número de de clases de nivel superior que pueden ser adicionadas al servicio de clasificación?• El número de clases hijo que pueden ser adicionadas a una clase padre?• La profundidad ó número de niveles de clases bajo una clase de nivel superior?




Clase hijo (sustantivo) Cualquier clase jerárquica que no es una

clase de nivel superior. Ver también hijo, clase

jerárquica, padre, padre/hijorelación, clase padre y clase de nivel superior.


Clase jerárquica (entidad) Un sub-tipo de clase que permite que un esquema de clasificación sea ordenado en una estructura jerárquica. Cada clase, excepto una Clase de nivel superior, tiene una clase padre y puede tener clases hijo.

Ver también clase y jerárquico.

Multi-nivel (concepto) Especialmente con relación a un esquema de clasificación jerárquica, una estructura jerárquica en la cual cada nivel, bajo una clase de nivel superior representa un concepto particular. Por ejemplo, en un esquema de clasificación típico de tres niveles, las clases de nivel superior pudieran representar funciones de negocios, las clases hijo de las clases de nivel superior representarían entonces actividades de negocios, en tanto que las clases nieto de las clases de nivel superior representan transacciones de negocios. Esta disposición de clases es también conocida algunas veces como “esquema de clasificación funcional”.

Clase padre (sustantivo) Cualquier clase jerárquica que contiene clases hijo. en el MoReq2010® una clase padre no puede ser usada para clasificar agrupacioneses ó documentos.

Ver también. hijo, clase hijo, clase jerárquica, padre yRelación padre/hijo.

Clase de nivel superior (sustantivo) Una clase jerárquica que no es un hijo de otra clase jerárquica. Cada clase de nivel superior es creada directamente bajo el servicio de clasificación.

Ver también. clase jerárquica.

201.7 Información del Modelo

E201.7.1 Clase jerárquica 497

M201.7.2 Identificador jerárquico de la clase padre 498

F201.7.3 Clase jerárquica – Adicionar clase 499

F201.7.4 Clase jerárquica – Crear 500

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 252 of 520F201.7.5 Clase jerárquica – Retirar clase 501

E201.7.1 Clase jerárquica

Identificador de sistema

8e98092d-e20b-48ea-b3d6-ca75375590ee

Título Clase jerárquica


Descripción Definición de una clase jerárquica, como sub-tipo de clase usada en esquemas de clasificación estructurados jerárquicamente

Sub-tipo Clase (E14.2.2)

Servicio Servicio de Clasificación

Metadatos Adicionales del sistema

Como para clase (E14.2.2) más los siguientes Metadatos adicionales del sistema:

• Identificador Jerárquico de Clase Padre (M201.7.2)

El siguiente elemento de metadatos es opcional, excepto para clases de nivel superior, bajo R201.4.4:

• Identificador por defecto del cronograma de eliminación (M14.4.11)

Funciones Adicionales

Como para clase (E14.2.2) más las siguientes funciones adicionales:

• Clase jerárquica – Adicionar clase (F201.7.3)• Clase jerárquica – Retirar clase (F201.7.5)

La siguiente función remplaza crear - clase (F14.5.24):

• Clase jerárquica – Crear (F201.7.4)

Notas de uso • La nueva función Clase Jerárquica – Crear (F201.7.4) remplaza la función Clase - Crear (F14.5.24) para clases jerárquicas

• El identificador por defecto del Cronograma de Eliminación (M14.4.11) es heredado de la clase padre a menos que sea invalidado y obligatorio para clases de nivel superior

• Un servicio de clasificación para clases jerárquicas clases puede no apoyar simultáneamente otros tipos de clases, bajo R201.4.1

M201.7.2 Identificador Jerárquico de Clase Padre


caa1ff78-8cf9-40ac-9e2f-6ca75b87637e

Título Identificadodr Jerárquico de Clase Padre

Descripción La clase padre para una clase jerárquica

Tipo de Entidad Clase jerárquica (E201.7.1)

Min. de Ocurrencias 0 (para clases de nivel superior)

1 (para clases hijo)

Max. de Ocurrencias

0 (para clases de nivel superior)

1 (para clases hijo)


Modificable? Si, (moviendo la clase)

Referencia de entidad?

Si.

Se refiere al tipo Clase jerárquica (E201.7.1)

Tipo de datos UUID

F201.7.3 Clase Jerárquica - Adicionar Clase


9ccb3ff0-b225-42bc-9edc-e05ed74547a5

Título Clase Jerárquica - Adicionar Clase

Descripción Adiciona una clase hijo a la clase jerárquica moviéndola de un nivel de clase superior a su ´padre anterior



El siguiente elemento de metadatos perteneciente a la clase hijo participante será modificada:

• Identificador Jerárquico de Clase Padre (M201.7.2)

De los requerimientos funcionales

R201.4.5

propósito • Control de Acceso• Generación de Evento

Metadatos del evento adicional (ver R2.4.16)

• Identificador de padre Anterior Participante (M14.4.76)• Identificador de Padre Nuevo Participante (M14.4.75)• Identificador de Clase Participante (M14.4.65)• Comentario del Evento (M14.4.25)

Notas de uso • Esta función es realizada siempre en conjunto con F201.7.5Clase Jerárquica – Retirar Clase

• Antes de que un usuario pueda retirar una clase, el usuario debe tener la autoridad para realizar esta función en el padre nuevo, así como la autoridad para retirar la clase de su padre anterior o de ser una clase de nivel superior• Para retirar una clase jerárquica de modo que sea una clase de nivel superior, el usuario debe tener la autoridad para realizar esta función para el servicio de clasificación en su conjunto• Esta función solo aplica para adicionar clases hijo retirándolas de

cualquier parte, no aplica para adicionar clases hijo creándolas en la clase jerárquica (ver F201.4.4 Clase Jerárquica - Crear)


F201.7.4 Clase Jerárquica - Crear


a148a5ee-58ab-4b7b-a925-bb6f426b0d7a

Título Clase Jerárquica - Crear

Descripción Crear una clase jerárquica


Metadatos de la entidad modificados

• Identificador de Sistema (M14.4.100)• Timestamp Creado (M14.4.9)• Fecha/Hora Originadas (M14.4.61)• Título (M14.4.104)• Descripción (M14.4.16)• Notas de Alcance (M14.4.97)• Identificador por defecto del Cronograma de Eliminación (M14.4.11)• Identificador Jerárquico de Clase Padre (M201.7.2)• Elementos contextuales de metadatos

Si se aplican elementos contextuales de metadatos de una plantilla la siguiente plantilla del elemento de metadatos puede ser modificada (si todavía no ha sido establecida):

• Primer Timestamp usado(M14.4.32)


R201.4.2, R201.4.3

próposito • Control de Acceso• Generación de Evento

Metadatos del evento adicional (see R2.4.16)

• Identificador de Clase Participante (M14.4.65)• Comentario del Evento (M14.4.25)• Registro de Cambio de Metadatos (D14.3.3)• Identificador de la Plantilla Aplicada (M14.4.2)

MoReq2010® – Volume 1 – Core Services & Plug-In Modules Page 245 of 520Notas de uso • La clase jerárquica puede ser creada como una clase de nivel superior,

en cuyo caso el Identificador Jerárquico de Clase Padre es omitido y el identificador por defecto del cronograma de eliminación viene a ser obligatorio•Si la clase jerárquica es creada como una clase hijo el Identificador Jerárquico de Clase Padre es obligatorio y el identificador por defecto del cronograma de eliminación viene a ser opcional

• La clase jerárquica puede ser creada con elementos contextuales de metadatos así como los elementos del sistema de metadatos enunciados• Si se adicionan elementos contextuales de metadatos de una plantilla el Identificador de la Plantilla Aplicada debe ser incluido en los metadatos del evento • Por cada elemento de metadatos establecido en la creación, excepto Identificador de Sistema y Timestamp Creado, se debe adicionar un Registro de Cambio de Metadatos al evento correspondiente


• Cuando los controles de acceso heredados de la clase son modificados en la creación entonces se deben generar eventos F14.5.33 Clase – Modifica ACL separados para cada cambio realizado en la lista de control de acceso

F201.7.5 Clase Jerárquica – Retirar Clase


2b0c7c88-ee72-4e83-87dd-ad9d98567789

Título Clase Jerárquica – Retirar Clase

Descripción Retira una clase hijo de clase jerárquica moviéndola a una clase de nivel superior ó a otra clase padre



Ver función relacionada F201.7.3 Clase Jerárquica – Agregar Clase


R201.4.5

Próposito Control de Acceso únicamente

Notas de Uso • Antes de que un usuario pueda mover una clase hijo fuera de la clase jerárquica, el usuario debe tener la autoridad para realizar esta función, así como la autoridad para agregar una clase al nuevo padre ó para hacerla clase de nivel superior

• Para trasladar una clase de nivel superior a una clase padre, el usuario debe tener la autoridad para realizar esta función para el servicio de clasificación en su conjunto• Esta función es realizada siempre en conjunto con F201.7.3

Clase Jerárquica –Agregar Clase , que describe los metadatos que son modificados y el evento que es generado

• Esta función no modifica metadatos ó genera un evento separadamente

Mo req2010 español 2

Education

Transcript of Mo req2010 español 2