30.10.2012 Views

LIBRO.ARCHIVOS.IBEROAMERICANOS

LIBRO.ARCHIVOS.IBEROAMERICANOS

LIBRO.ARCHIVOS.IBEROAMERICANOS

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

2 Normativa de referencia<br />

50<br />

•<br />

•<br />

•<br />

•<br />

•<br />

•<br />

•<br />

•<br />

•<br />

•<br />

Administración de documentos y archivos. Textos fundamentales<br />

Establecer objetivos de funcionamiento y criterios de evaluación claros;<br />

Implicar y animar continuamente a los participantes en el proyecto piloto a utilizar el<br />

sistema;<br />

Realizar sesiones de trabajo de prototipo con el software antes de personalizarlo;<br />

Finalizar el diseño del sistema;<br />

Desarrollar una metodología de aceptación de la calidad;<br />

Expandir el piloto de manera incremental a otras áreas;<br />

Asegurar que los requisitos del piloto se pueden medir y son claramente comprendidos<br />

por los usuarios;<br />

Revisar proyectos similares para detectar potenciales problemas;<br />

Llevar a cabo tormentas de ideas en equipo para anticipar retos; o<br />

Desarrollar planes de contingencia para potenciales eventualidades<br />

3.1.6 Estructura de los requisitos<br />

En lo que concierne a los requisitos en sentido estricto, éstos se encuentran agrupados en<br />

bloques o conjuntos de alto nivel, bajo la forma de modelo conceptual, y que se explican<br />

y se describen gráficamente en el Módulo 2 de la especificación40 , y en cuya articulación,<br />

si bien no coincidente, parece resonar el ya mencionado modelo del continuo de los documentos<br />

(no olvidemos que la especificación, en su origen, fue un proyecto confinado al<br />

área geográfica de Australasia). En lo que sigue, presentamos el modelo gráfico y explicamos<br />

brevemente sus características.<br />

El modelo presenta cinco cajas de conjuntos o bloques de alto nivel, pero una de tales cajas,<br />

la relativa a diseño, en fondo gris y enmarcada en un cuadrado punteado, no corresponde a<br />

requisitos funcionales, sino a requisitos no funcionales –facilidad de uso, escalabilidad, interoperabilidad,<br />

funcionamiento, disponibilidad del sistema-, que quedan fuera del alcance<br />

de la especificación. Además, dentro de la caja “Mantener” aparece una sub-caja, también de<br />

color gris y punteada, correspondiente a la conservación a largo plazo, que, como se indicó,<br />

también queda fuera del alcance de la especificación. Por tanto, los requisitos se agrupan,<br />

tanto en el Módulo 2 como en el Módulo 3, en cuatro grandes bloques que podrían interpretarse<br />

como funciones contenedoras: crear, mantener, diseminar y administrar. Cada uno<br />

de estos contenedores se divide a su vez en lo que se podrían considerar funciones o procesos<br />

de gestión de documentos, y que son realmente los contenedores de los que dependen los<br />

requisitos, de la siguiente manera:<br />

•<br />

•<br />

Crear, que incluye los procesos capturar, identificar, clasificar (cada uno de los tres con<br />

sus correspondientes requisitos).<br />

Mantener, que incluye los procesos controles y seguridad; gestión de sistemas híbridos;<br />

retención, migración y disposición (igualmente con un cierto número de requisitos para<br />

cada uno de los tres bloques); conservación a largo plazo (fuera del modelo, en la medida<br />

en que necesita un conjunto específico de requisitos).<br />

39 Ob. cit., pp. 14-15.<br />

40 Principles and Functional Requirements for Records in Electronic Office Environments – Module 2…, pp. 16-22.<br />

39 .

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!