viernes, 31 de mayo de 2013

Cuánto pesa la imagen y los requisitos adicionales en el tamaño de un proyecto de Arquitectura de Información

En ocasiones la imagen incide en el tamaño
y la agenda de los proyectos de AI.
 En muchos casos, sin embargo,
el impacto es mínimo.
Todo gerente de servicios de información está interesado en hacer proyectos de mejora de sus servicios, todo Arquitecto de Información también. Como hemos estado conversando, al inicio del ciclo de vida de estos proyectos, se realiza una estimación del tamaño de los mismos. Para esta estimación se toma en cuenta la estructura de información, la funcionalidad, la navegación, las comunidades y seguridad. Ahora bien, cabe preguntarse por el impacto de la imagen y la estética en el tamaño del proyecto. ¿Cuáles son los casos que se presentan? También podemos preguntarnos por el impacto de requisitos adicionales que hubiera que tomar en cuenta en una estimación de tamaño. Esto es lo que hacemos en este post.

Imagen
Las consideraciones estéticas, de imagen y estilo requeridas por un proyecto, pueden ser importantes o no como para afectar las estimaciones de tamaño del proyecto a realizar. No hay una respuesta universalmente válida.

Algunos proyectos requieren de iconos originales y una imagen muy particular en el sitio Web que no puede simplemente resolverse con los iconos y estilos estándares disponibles en el equipo desarrollador y sus herramientas habituales de trabajo. En estos casos debe estimarse la cantidad de inversión en imagen que se necesita contando la cantidad de iconos necesarios y multiplicando por un estimado del tiempo con el que se trabaja el desarrollo de uno de estos íconos. Analogamente se puede proceder para los estilos. Debe tomarse en cuenta que normalmente esta actividad implica revisiones y aprobaciones por lo que no se trata sólo de un mero trabajo de creación de imagen. Hay que incluir la coordinación que se requiere desde la organización.

Debe notarse, eso si, que esto no ocurre siempre. Por ejemplo, algunos proyectos, aunque requieren de elementos y consideraciones de imagen y estética, como un aspecto básico que se maneja en todas las soluciones de Arquitectura de Información, son iniciativas esencialmente corporativas y por tanto usan las definiciones previas de la institución y los iconos y estilos institucionales previamente definidos. En  este caso la imagen no afecta significativamente la agenda del proyecto, ni los recursos que se necesitan para su desarrollo, por lo que su impacto puede ser pasado por alto, en la actividad de estimación de tamaño, sin que esto traiga mayores inconvenientes.

Requisitos adicionales
Algunas soluciones se caracterizan por requerir consideraciones de diseño adicionales, como por ejemplo vistas diferentes con comunidades diferentes en una misma base de información. Lo que se impone como método es, por tanto, revisar todos los requisitos y ver si alguno de ellos implica un trabajo adicional que deba ser estimado especialmente, de una forma o de otra, ya que no puede considerarse incluido en las otras figuras de mérito para la estimación que hemos mencionado en nuestros últimos post (Ver: Cómo estimar el tamaño de un proyecto de Arquitectura de Información: la estructura y  La funcionalidad en la estimación del tamaño de un proyecto de Arquitectura de Información)

viernes, 24 de mayo de 2013

Más sobre la funcionalidad al estimar el tamaño de un proyecto

En el plan de un proyecto de gestión de información hay que
 buscar ciertos números que nos hablan del tamaño del proyecto

Hemos visto que el tamaño de un proyecto de gestión de información es determinado en gran media por la complejidad de la estructura de información a manejar, condensada en tres números: la cantidad de objetos de información, la cantidad de metadatos o variables internas que se distinguen y la cantidad de asociaciones estructurales entre ellos. Hace quince días vimos el impacto de la entrada de datos en la estimación de tamaño del proyecto y la semana pasada comentamos sobre la navegación y la cantidad de comunidades a gestionar. Hoy queremos señalar cómo, en el desarrollo de la funcionalidad, el tamaño del proyecto depende también del número de salidas, el número de formas de consulta avanzadas, el número de casos de uso y el número de servicios de alerta.

Número de salidas
Todo proceso de gestión de información tiene distintos tipos de salidas: resumidas, detalladas, abreviadas, cartográficas, tablas, etc (Ver Diseño de Tipos de salidas). Cada salida normalmente requiere de diseño, prueba y validación y, por tanto, inversión de tiempo de desarrollo. De allí que el número de salidas diferentes es otro dato que suma en la consideración del tamaño de un proyecto de gestión de información.

Número de formas de consultas avanzadas
Es natural que las herramientas de desarrollo con las que trabajamos la Arquitectura de información incluyan un motor de búsqueda que haga que las consultas simples, con una única caja de entrada en la que el usuario coloca sus palabras claves, no sean un factor que ocupe en forma significativa tiempo de desarrollo, ya que éstas funcionan como un servicio que resulta prácticamente automático desde las herramientas de desarrollo usualmente usadas. El caso de cajas de búsquedas simples sólo debe considerarse si se pretendiera desarrollar software, cosa que por lo general debe evitarse.

Un caso diferente son las consultas avanzadas, especializadas que deban construirse e implementarse como parte de la solución. Típicamente estas tiene múltiples cajas y/o elementos, lo que implica un gran número de pruebas de casos y por ello, el número de consultas avanzadas requeridas es también un dato a incorporar en la estimación del tamaño del proyecto de gestión de información.

Número de casos de uso
Los casos de uso (ver) tienen que ver con las actividades que deben realizarse en un proceso de gestión. Cada caso de uso, requiere una inversión de tiempo de conceptualización, modelado, construcción, prueba y transferencia por lo que el número de casos de uso es otro aspecto de la funcionalidad que suma en la consideración del tamaño de un proyecto.

Servicios de alertas
Los servicios de alertas que disparan acciones cada vez que ocurre una cierta condición son otro de los aspectos a tomar en cuenta cuando se estima el tamaño de un proyecto de gestión de información.


En síntesis, en lo que respecta a funcionalidad, un proyecto puede ser más o menos grande según el número de formas de entrada especiales, de salidas, de consultas avanzadas, de casos de uso y de servicios de alertas. Resulta conveniente para los Arquitectos de información que desarrollan nsoluciones fijarse en estos números y registrar sus datos históricos para así poder hacer cada vez mejores estimaciones.

viernes, 17 de mayo de 2013

Impacto de la navegación y las comunidades en el tamaño de un proyecto de Arquitectura de información


La cantidad de comunidades con las que se trabaja en un
proyecto de gestión de información debe considerarse al
estimar el tamaño de la solución y los recursos necesarios
para desarrollarla
Todos los proyectos de gestión de información están destinados a comunidades. A veces estas son pocas y a veces son muchas. A veces muy interrelacionadas y otras veces poco. ¿De que forma debe un gerente o un arquitecto de información considerarlas al momento de estimar el tamaño de un proyecto? ¿Qué otros aspectos o figuras de mérito adicionales a los que hemos estado conversando en las últimas semanas debemos tomar en cuenta? Continuamos así en este post la conversación sobre la planificación de las soluciones de gestión de información, particularmente en lo que respecta a las apreciaciones del volumen de trabajo que se requerirá para desarrollarlas.

Antes de examinar el tema de la relación entre comunidades y tamaño de una solución veamos por qué la navegación, siendo tan importante, no aporta figuras de mérito especiales en las estimaciones de recursos necesarios.

Navegación
Si bien la navegación es una de las dimensiones siempre presentes y sofisticadas en todo proyecto de Arquitectura de información, su complejidad está normalmente vinculada, en forma directa, a la complejidad de la estructura de información y la funcionalidad que se construye, por lo que no suele ser necesario tener indicadores especiales para estimar el impacto de la navegación en las consideraciones de tamaño de proyecto.

Esto no quiere decir que no necesitemos tiempo para diseñar, construir y probar la navegación, sino que para estimar este tiempo no necesitamos recolectar figuras de merito adicionales a las tomamos para estimar la estructura de información y funcionalidad.

Número de Comunidades y asociaciones
El caso de las comunidades es muy diferente. De hecho, algunos proyectos se vuelven complejos precisamente más por la cantidad de comunidades que deben manejarse que por la complejidad de la estructura de información con las que éstas deben trabajar.

Las comunidades implican consideraciones especiales de seguridad que deben definirse. Cada comunidad debe cruzarse con todos los otros objetos de información y comunidades, por lo que su aporte a la complejidad de un proyecto de Arquitectura es, por lo menos, la de un objeto de información complejo y el número de comunidades con la que se trabajará es, sin duda, un indicador relevante en la estimación del tamaño de los proyectos de gestión de información.

Nótese adicionalmente que pueden existir asociaciones entre comunidades o entre comunidades y objetos de información que no representen comunidades y que éstas deben contabilizarse como cualquier otra asociación entre objetos de información a la hora de estimar el tamaño de proyectos de gestión de información.

En un próximo post revisaremos el impacto de la imagen y de algunos requisitos adicionales a tomar en cuenta cuando queremos tener una idea de cuántas horas de trabajo necesitamos para lograr implementar una solución.

viernes, 10 de mayo de 2013

La funcionalidad en la estimación del tamaño de un proyecto de Arquitectura de Información


La estructura de los objetos de informaciónn no es lo único que incide
 en el tamaño de un proyecto de Arquitectura de Información.
También algunos elementos de la funcionalidad deben tomarse en cuenta
El problema de la estimación de tamaño de un proyecto de Arquitectura de información es un asunto complejo que debe resolverse en la fase de identificación, la primera del ciclo de vida de la aplicación, donde se realiza toda la conceptualización y planificación de un proyecto que se diseña y se desarrolla para culminar con la entrada en producción de una nueva solución de gestión. La semana pasada vimos como con algunas variables simples de la estructura de Información: la cantidad de objetos de información, la cantidad de metadatos de éstos y la cantidad de asociaciones entre los objetos de información, podemos hacer una estimación de tamaño razonable. Hoy queremos detenernos en otros elementos que pueden afectar significativamente el tamaño del proyecto, pero que dependen más bien de otra dimensión del trabajo del Arquitecto de Información: la funcionalidad.

En efecto, el tamaño de la actividad de desarrollo que construye una solución de gestión de información no es sólo dado por la complejidad de la estructura de objetos que deben manejarse. Tiene que ver también con las especificaciones de lo que debe hacerse con ellos, la cantidad de entradas y de salidas diferentes, de consultas no estándares que deben diseñarse, el número de casos de uso (Ver Conceptualización de la solución y casos de uso) y servicios de alerta a implementar en la aplicación. Vamos a referirnos a las formas de entrada en este post y dejamos los otros elementos de la funcionalidad para uno siguiente.

Número de formas de entrada especiales
Típicamente, cada objeto de información requiere de una forma de entrada desde la cual debe ingresarse la información. Si esto simplemente debe hacerse para cada objeto de información, la complejidad puede estimarse, al igual que en el caso de la estructura, desde el número de objetos de información.

Sin embargo, en la práctica se presentan otras situaciones, siendo las más comunes el uso de formas de entrada complejas que requieren el ingreso de dos o más objetos de información en una única forma o de distintas formas de ingreso para un mismo tipo de objeto de información.

Un ejemplo simple que ilustra estas situaciones es el caso de carga de directorios que incluyen a personas e instituciones. Una actividad común en muchos proyectos. En un directorio cuando registramos una institución debemos registrar información no compleja: el nombre, la dirección física, la dirección electrónica, etc. Pero cuando registramos los datos de una persona el caso es diferente, porque sus datos pueden incluir la información de la institución donde trabaja. Esto hace que la institución simplemente debe ser seleccionada desde la lista de instituciones previamente cargadas o, si no ha sido introducida antes, se debe hacerlo como un paréntesis mientras se llenan los datos de la persona.

En cualquier caso es una situación de diseño y de desarrollo especial y el tiempo para realizar este trabajo de implementar en la solución final formas de entrada complejas debe incluirse en la estimación de tamaño del proyecto.

Otro caso que puede presentarse es que un objeto de información tenga una única forma de entrada, que no involucre tampoco otros objetos de información, pero que en si misma sea una forma relativamente compleja, por lo que debe considerarse como una entrada especial que requiere ponderar su tamaño con un peso mayor al de una forma estándar, debido a su dificultad.

Tenemos pues tres casos en la consideración de formas de entrada especiales en la estimación de tamaño de proyecto: el ingreso de varios objetos en una forma, distintas formas de ingreso para un mismo objeto de información y el de formas de entrada intrínsecamente complejas en un mismo objeto de información. La suma del número de estos casos debe considerarse en la estimaciones de tamaño.


viernes, 3 de mayo de 2013

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.