Cómo estimar el tamaño de un proyecto de Arquitectura de Información: la estructura

No importa lo difícil que estimar el tamaño de un proyecto
 parezca. Siempre hay que desarrollar métodos y analizar
 las experiencias consistentemente, para mejorar en el
 tiempo.

La semana pasada estuvimos conversando acerca de la estimaciones de tamaño de los proyectos de gestión de Información. Un tema de interés para los gerentes y para los desarrolladores de los mismos ya que es crucial tener una idea de lo que involucrará la realización de una determinada solución propuesta. Vimos por qué es necesario tener métodos consistentes que se puedan emplear sistemáticamente y como los practicantes de una profesión relativamente nueva, como la Arquitectura de Información (AI), tienen que desarrollar una experiencia sistémica para hacer estas estimaciones. Hoy entraremos en detalles metodológicos.

Finalizamos nuestro post de la semana pasada planteando que los elementos que debemos tomar en cuenta para estimar el tamaño de una solución deberíamos buscarlos en las diversas dimensiones (ver las 5  dimensiones de la Arquitectura de Información) que distinguimos en un proyecto de AI: Estructura de Información, Funcionalidad, Navegación, Comunidades e Imagen.

El primero de estos elementos, la estructura de un modelo de información, es particularmente relevante probablemente el principal, en la consideración del tamaño de un proyecto de AI (ver Estructuras de información. Qué son y para qué se usan). En esta estructura hay tres factores claves para el método que proponemos: el número de objetos de información, la cantidad de metadatos y el número de asociaciones estructurales.

El número de objetos de información
Los objetos de información son diferentes y por tanto requerirán recursos diferentes, pero en una primera aproximación el número de ellos habla mucho de la complejidad del proyecto. No es lo mismo automatizar un proceso en el que intervienen unos pocos objetos de información que una solución con un par de decenas de ellos. Cada objeto requerirá análisis, modelado, construcción, validación. Adicionalmente la complejidad de la estructura expresada en relaciones entre ellos crecerá si aumenta el número de objetos de información.

La cantidad de metadatos
Los metadatos o campos que distinguimos en cada tipo de objeto de información hablan de la complejidad de estos. Es diferente trabajar con objetos que tienen, digamos, siete campos o menos, que trabajar con objetos en los que distinguimos quince campos de metadatos. El número exacto no es relevante y es un poco arbitrario la cantidad que se toma como el límite que separa un objeto simple o estándar de uno complejo, sin embargo, cualquier cosa entre siete y doce luce razonable para establecer esta separación. Un objeto complejo puede considerarse que tiene el doble del tamaño de un objeto simple, para propósitos de estimación.

El número de asociaciones
Como hemos visto en otras oportunidades los objetos de información pueden tener asociaciones estructurales entre ellos. Estas son relaciones claves en los proyectos y suelen ser recíprocas: un tutor, una tesis y un estudiante tesista son objetos de información establemente vinculados. Una persona y la institución donde trabaja están también claramente relacionados, si bien el caracter de la relación puede ser temporal. Estos vínculos son en si mismo estructuras que se describen con metadatos y por ello tienen una dificultad de desarrollo equivalente a un objeto de información. Por ello deben contarse el número de asociaciones que se requieren y estimar su dificultad de desarrollo como el equivalente a uno o dos objetos de información simples.

Uniendo estas tres variables tenemos una estimación de tamaño para la estructura de información, que seguramente es expresiva en relación al tamaño global del proyecto. En nuestro próximo post hablaremos de la estimación de las otras dimensiones.