viernes, 28 de junio de 2013

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.

viernes, 21 de junio de 2013

Herramientas y contenidos para el diseño de un modelo de gestión del información

El Mapa de objetos de información debe ser uno de los contenidos presentes
en el informe de la Fase de Diseño de una solución de gestión de información.
Debe poder ser explicado y comprendido por todos los involucrados
Es común que nos pregunten por las herramientas para escribir un modelo de gestión de información, la forma que debe tener un documento así, resultado del diseño de una solución, las plantillas que deberían usarse en esta fase de modelado que debemos realizar antes de la construcción del primer prototipo funcional. La respuesta que damos normalmente es que lo que realmente define un buen diseño de gestión de información es la completitud de sus contenidos. En cuanto a la forma, hemos encontrado que mucha gente se siente cómoda leyendo el documento en formato de hoja electrónica de cálculo, dado que el diseño en general incluye muchas tablas y algunos gráficos y una cuantas referencias cruzadas en sus secciones. Pero esto es secundario. Lo que más importa es que los contenidos de diseño estén completos y que el documento pueda ser leído y entendido por todas las partes involucradas. Ampliamos a continuación un poco más.

La fase de diseño de la solucion de gestión de información debe producir información técnica, en el dominio de la solución. Es importante que esta información pueda ser explicada, comprendida y revisada por todos los involucrados en el problema y la solución. Los contenidos centrales del modelo que se debe producir en esta etapa incluyen el mapa de objetos de información, la estructura de objetos de información, las tablas de lenguaje controlado, los documentos electrónicos asociados, los diagramas de flujo de procesos, la especificación de los cambios de estado, los alertas, la permisología, la navegación, las consultas, las estadísticas y salidas y el acuerdo sobre los parámetros estéticos. Hablaremos a continuación del primero de  estos contenidos y dejaremos los siguientes para nuevas oportunidades.

El Mapa de objetos información
Es un gráfico que debe ilustrar los objetos de información que entran en juego en la solución. El objetivo es proporcionar una idea rápida de la estructura, complejidad y relaciones presentes en el sistema.

Los aprendices de Arquitectura de información que han estado ligados al diseño de software suelen preguntar si el mapa de objetos de información es lo que ellos llaman diagramas de clases. En efecto, los ingenieros de software están acostumbrados a manejar gráficamente una representación de la solución llamada así, pero cuando vemos las definiciones para la realización de éstos diagramas de clases notamos que están orientados mas a significantes de la construcción de software que a la comprensión estructural de la solución por personas ligadas a otros dominios de conocimiento. Son descripciones demasiado técnicas de ingeniería y por eso no resultan útiles para los gerentes y usuarios involucrados en un proyecto de información.

Los Arquitectos de información trabajan alternativamente con el mapa de objetos de información, de más alto nivel y por ello mucho más condensado, simple y cercano a la comprensión desde los dominios de conocimientos de todos los involucrados en la solución al problema de gestión de información en el que se está trabajando.


viernes, 14 de junio de 2013

El diseño de un modelo de información

Un buen diseño del modelo de gestión de informaicón es decisivo en la
construcción de una buena aplicación
(Imagen tomada de http://www.hdwallpapers.in)
Dentro de ciclo de vida de una solución de gestión de información la primera fase es la de definición del problema y la solución. Siempre es importante hacer bien este trabajo de conceptualización. Pero luego... ¿qué es lo que sigue? El diseño de la solución. El desarrollo de un modelo de información con las características apropiadas para resolver el problema de gestión. Esto implica desde modelar una estructura de información hasta definir los detalles del prototipo funcional que debemos construir. Es un trabajo que los Arquitectos de Información deben realizar.

En efecto, para lograr una solución bien construida se requiere un modelo de gestión de información bien diseñado. Y un modelo así requiere el trabajar en la cinco dimensiones sobre las que opera la Arquitectura de Información: La estructura de información, la funcionalidad, la navegación, las comunidades y la seguridad y la imagen y estética (Ver Las 5 dimensiones de la Arquitectura de Información).

La estructura de información
Debemos diseñar al detalle los objetos de información que requeriremos. En la fase de diseño no se trata sólo de la lista de objetos preliminar (ver La lista de objetos de información y el Arquitecto de Información,  El modelo preliminar de información y la Más sobre el modelo preliminar de información) que creamos en la fase de definición, sino del detalle. La lista completa de objetos, la lista completa de campos (metadatos) y las propiedades que distinguiremos en ellos, las asociaciones (vero estructuras de relacionamiento que distinguimos en el problema y la solución (Ver más sobre  Estructura de información).

La funcionalidad
Debemos modelar todas la entradas y salidas y todos los requerimientos que se desprendan de los distintos casos de uso. (ver más sobre Casos de uso) En particular hay que definir el vocabulario controlado que usaremos en el proyecto para cada uno de los clasificadores usados para los distintos objetos de información (ver) y para cada uno de los estados por los que estos pasarán cuando se implementen los procedimientos (Ver más sobre Funcionalidad).

La navegación
Debemos diseñar como los usuarios se moverán a través de la aplicación. Cuáles son los menús que debemos implantar y cuáles son las opciones que deben aparecer en ellos. Como usaremos las distintas secciones que aparecerán en las salidas (Ver más sobre Navegación).

Las comunidades y la seguridad
Se deben modelar las comunidades que deberán formar parte de la solución, incluyendo sus diversas características en cuanto al acceso a la información y a la funcionalidad. Debemos construir una matriz en la que cruzamos cada tipo de objeto de información con cada comunidad para definir lo que éstas últimas deben poder hacer con cada tipo de objeto: insertar, modificar, eliminar, consultar. Algunas asociaciones estructurales pueden implicar permisos y restricciones de seguridad adicionales (Ver más sobre Comunidades y Seguridad).

Imagen y estética
Debemos definir como manejaremos todo lo concerniente a la imagen de la aplicación y a los patrones de estética que se usarán (Ver más sobre Imagen y Estética).

viernes, 7 de junio de 2013

¿Qué pasos debemos dar inicialmente si queremos acometer un proyecto de gestión de información?

Al iniciar un proyecto de gestión de información es importante tener claro los
pasos  que deben darse durante la fase de conceptualización de la solución
En los próximos post queremos hablar sobre el diseño o construcción de modelos de información. Esto se corresponde a la segunda fase del desarrollo de una solución de gestión de información dentro de un concepto que llamamos ciclo de vida de una solución. Entraremos mejor en ese tema si cerramos bien el previo, la fase inicial o de definición de la solución, donde realizamos la conceptualización de lo que será el modelo y el proyecto. En función de ello queremos sintetizar aquí una guía de las actividades que deben hacerse durante la primera fase, definida en los términos de nuestros últimos post. Respondemos aquí, por tanto, a la pregunta del título: ¿Qué pasos debemos dar inicialmente si queremos acometer un proyecto de gestión de información?

Sobre el ciclo de vida de una solución puede leerse los siguientes post:



La primera fase define el problema a resolver y la solución que lo hará (ver Identificación de la solución que se desea). Ello supone la realización de las actividades de la siguiente guía:

Guía de actividades para la Definición de la solución de gestión


  1. Lo primero es informarse y documentarse sobre el problema a resolver. Es decir, realizar el levantamiento de información (ver: Obteniendo la información y Analizando la información)
  2. Lo segundo es definir la visión del proyecto (ver Identificación de la visión compartida en una propuesta de gestión de información y Un poco más sobre la visión: preguntas y respuestas pertinentes)
  3. Defina lo deseado en términos de los requisitos que debería satisfacer la solución (ver: Después de la visión viene la lista de requisitos)
  4. Refine su comprensión del problema de información que se desea solucionar: escribiendo los casos de      uso (ver: Conceptualización de la solución y casos de uso, Más sobre los caso de uso en el desarrollo de aplicaciones, Corto y simple de entender es mejor, La escritura de casos de uso)
  5. Defina el modelo preliminar: objetos de información, campos y asociaciones que requiere la solución (ver: El modelo preliminar de información, Más sobre el modelo preliminar de información)
  6. Realice el trabajo de estimación del tamaño del proyecto. Guarde su resultados para revisarlos posteriormente (ver: La estimación de tamaño de la solución de Arquitectura de Información, Cómo estimar el tamaño de un proyecto de Arquitectura de Información, La funcionalidad en la estimación del tamaño de un proyecto de Arquitectura de Información, Más sobre la funcionalidad al estimar el tamaño de un proyecto, Impacto de la navegación y las comunidades en el tamaño de un proyecto de Arquitectura de Información, Cuánto pesa la imagen y los requisitos adicionales en el tamaño de un proyecto de Arquitectura de Información)
  7. Realice el plan de proyecto a partir de las estimaciones obtenidas. Nuestra recomendación, bien sea que Ud. sea demandante u oferente de servicios, es que contrate inicialmente esta única fase, ya que sólo así tendrá una idea del tamaño del proyecto y lo que se hará (Ver: Por qué contratar sólo la conceptualización)