Diseño de una solución y la estructura de información

Para un Arquitecto de información es muy importante especificar el detalle
de lo que debe construirse. Sólo así no se tendrán sorpresas luego
de la fase de diseño de una solución de gestión de información

Recientemente iniciamos la conversación sobre los contenidos que deben estar presentes en el informe de la fase de diseño de una solución de gestión de información. Este informe debe ser realizado por el equipo técnico que esté a cargo de la Arquitectura de información y su objetivo es orientar a los desarrolladores e involucrados en el proyecto sobre qué es lo que debe construirse. El primero de estos contenidos fue el Mapa de objetos de información, un resumen gráfico de los objetos con los que se desarrollará la solución, conforme lo explicamos la semana pasada. Hoy queremos presentar otro de los elementos centrales en el diseño de una solución: el detalle de la estructura de objetos de información.

Estructura de información
La información del Mapa de objetos de información es útil para una primera comprensión de la aplicación que se construirá, pero es claramente insuficiente como especificación de lo que debe construirse. Los desarrolladores de la fase de construcción necesitan información detallada sobre cada objeto de información. Esto es por tanto un contenido esencial en el diseño de la solución.

En la sección de estructura de información del informe de diseño debe incluirse la descripción analítica de detalles de todos los objetos de información que intervienen en el proyecto. Es importante que sea realmente exhaustiva, para que no haya ambigüedad en lo que va a construirse.

Normalmente se presenta mejor bajo el formato de tablas donde se listan en secuencia los campos o metadatos que se distinguen en cada objeto de información. De cada campo hay que enunciar, además de su nombre, una pequeña descripción en un lenguaje de usuario final. De hecho, lo mejor es escribir como descripción la información que se proporcionará como ayuda a los usuarios finales cuando el campo se presente en la forma de entrada de datos ligada al objeto de información.

Otra información a incluir cuando sea pertinente es la referencia a los documentos de origen que proporcionan la información de estos campos. También alguna información que describa el carácter con el que el campo se usa: si se trata de un campo obligatorio, que siempre debe estar presente en el objeto de información, sugerido, es decir recomendable pero podría no estar presente, o simplemente complementario, para aportar información adicional cuando se tenga.

Adicionalmente en estas tablas de diseño detallado se incluye información que describe el uso de los campos o metadatos en el momento de presentar pantallas de salida: su presencia o no en las salidas de múltiples registros (salidas tabla o resumidas).

Para cada campo debe especificarse su naturaleza, es decir, si se trata o no de un campo clasificatorio, es decir, un campo cuyo contenido se usa para agrupar o separar en grupos a las distintas instancias de ese objeto de información, un campo de identificación, como un código o un título, que se usa para designar  o distinguir cada instancia de un tipo de objeto de las restantes, o un campo descriptivo, como un resumen, una colación, etc.

En el caso de un campo clasificatorio hay que especificar si es de lenguaje controlado o de lenguaje abierto, como los que se usan en la indexación social o folksonomías.

Finalmente es importante destacar que deben incluirse como campos especiales los que se derivan de las asociaciones de cada objeto con los otros objetos de información con los que están asociados.

Toda esta información será usada por los desarrolladores para construir la aplicación, con independencia del método y las herramientas que usen, de si se desarrollará software o no.