viernes, 26 de abril de 2013

La estimación de tamaño de la solución de Arquitectura de información


Podemos hacer proyectos de cualquier tamaño. La humanidad va
 desarrollando su presencia en el sistema solar. Pero para hacer proyectos
 de cierta envergadura hay que aprender a estimar el tamaño.
Los Arquitectos de Información deben, entre otras cosas, aprender a
 estimar el tamaño de sus iniciativas al inicio de sus aplicaciones.

Hemos hablado de cómo podemos distinguir en el ciclo de vida de una solución de gestión cinco fases: Identificación, Diseño, Desarrollo, Implementación y Producción. En la fase de Identificación de la solución es donde hacemos la conceptualización de todo lo que hay que hacer: el levantamiento de la información, la determinación de los requisitos, la formulación de la visión y de los casos de uso, el modelo preliminar, el plan del proyecto. Entre estas primeras actividades, una de las cosas que hay que hacer son las estimaciones de tamaño: ¿De qué tamaño es este proyecto que vamos a realizar? ¿Cuántos recursos necesitamos? ¿Cuántas personas? ¿Cuánto tiempo? ¿Cómo hacemos esto en un proyecto de Arquitectura de Información?

No podemos hacer algo con una calidad aceptable si no tenemos idea de cuál es el tamaño de lo que haremos. El tamaño es crucial y tiene la dificultad de que debemos estimarlo en el inicio del proyecto. Es claro que siempre hay que hacer una primera aproximación que se ajustará en el camino a medida que se refinen los criterios. La experiencia, especialmente cuando es documentada, como en el caso de las personas y las organizaciones metódicas que llevan registro de su dedicación a cada proyecto, suele ayudar a hacer estimaciones mejores.

Los ingenieros de software estiman el tamaño de los proyectos según distintas metodologías y, si bien hay discusiones y puntos de vista diferentes, es claro que tener métodos que puedan aplicarse consistentemente suele ser mejor que no tenerlos y comenzar de nuevo, desde cero, cada vez. Pero como hemos visto, muchos proyectos de gestión de información se implementan hoy día sin necesidad de hacer desarrollo de software.

La Arquitectura de Información es una profesión en plena gestación, derivada de las nuevas oportunidades que abrieron las tecnologías de la información emergentes, particularmente la Web, por ello carece de un cuerpo de conocimientos estabilizado y por ello no hay métodos de estimación de tamaño ampliamente reconocidos.

¿Cómo hacer pues la estimación inicial en un proyecto de Arquitectura de información? Desde nuestro punto de vista un lugar razonable para la iniciar un proceso de estimación es el Modelo preliminar de información del que hablamos las últimas dos semanas (Ver 1 y 2). Los factores a considerar que hacen a un proyecto más grande que otro debemos buscarlos allí, así como en el recorrido de las cinco dimensiones claves de los proyectos a cargo de Arquitectos de Información: Estructura de Información, Funcionalidad, Navegación, Comunidades e Imagen (Ver).

En el marco de lo planteado, en nuestro próximo post nos referiremos en forma concreta a cómo afrontar, con un cierto método, pragmático pero sistemático, las estimaciones de tamaño en un proyecto de Arquitectura de Información.

viernes, 19 de abril de 2013

Más sobre el modelo preliminar de información



El objetivo de un modelo preliminar de información es facilitar la estimación
 de tamaño de la solución que se desarrollará
Cuando se comienza a definir una solución de gestión de información, se debe desarrollar un modelo preliminar de información. El objetivo de este modelo preliminar, como apuntamos la semana pasada, no es el modelo en si mismo como facilitador de la construcción o desarrollo de la solución o de sus prototipos, sino el permitir la estimación del tamaño de la solución, lo cual es necesario para las estimaciones de tiempo y de recursos necesarios. Es la manera en que trabajan los Arquitectos de Información, con una metodología que difiere de las que tradicionalmente usan los ingenieros y que tiene ventajas semánticas al facilitar la comunicación de los distintos roles que se involucran en un proyecto.

Además de estimar tamaño, tiempo y recursos, cuando se define un proyecto al inicio de su ciclo de vida se requiere determinar riegos y posibles grandes dificultades. En esto también el tener un modelo preliminar tiene la ventaja de proporcionar una vista concreta, así sea bajo una perspectiva sin mayores detalles, de lo que será la solución que se proyecta.

Diseñar un modelo preliminar no es, por tanto, modelar en detalles la aplicación, sino describir sucintamente sus componentes más fundamentales: la lista de los objetos de información que se requieren, sus campos, las asociaciones entre ellos y las salidas especiales que se necesitan.

Siempre debe considerarse que un modelo preliminar es sólo un esbozo de solución ya que no es hasta que se haga el diseño detallado que se tendrá una idea más precisa.

La información de la que se extrae el modelo preliminar es el levantamiento de información y los casos de uso (Ver Conceptualización de la información y casos de uso).

En síntesis, el método que usan los Arquitectos de Información al elaborar el Modelo preliminar de información puede resumirse de la siguiente manera:

1. La descripción de las características principales del sistema usando una semántica de información (Ver Semántica de información)
2. Enumerar las entradas y salidas de la aplicación
3. Determinar los usuarios directos e indirectos
4. Encontrar las interacciones principales entre los objetos de información y los usuarios (Ver La escritura de casos de uso)
5. Describir sucintamente los casos de uso (Ver Corto y simple de entender es mejor)
6. Elaborar las lista preliminar de objetos de información, sus campos y sus asociaciones (ver La lista de objetos de información y el Arquitecto de Información)
7. Estimar el tamaño del proyecto, en sus diferentes perspectivas: personas, tiempo, recursos.

viernes, 12 de abril de 2013

El modelo preliminar de información


El Modelo Preliminar de Información tiene la virtud de
representar la solución a un problema de gestión de información
en forma simplificada, facilitando la comunicación de los
aspectos esenciales entre los actores involucrados
Hace algún tiempo, conversando en el contexto del modelado de información, estuvimos hablando de cómo los Arquitectos de Información construyen modelos de gestión de información usando una semántica de información de forma muy diferente a como los ingenieros trabajan, ya que estos segundos construyen sus modelos a partir de una semántica de datos. La diferencia no es trivial, no necesariamente se entiende a la primera y tiene implicaciones metodológicas. Queremos volver un poco al tema pero con otra perspectiva, ya que esta vez estamos trabajando el ciclo de vida de las aplicaciones de gestión y nos encontramos en la fase inicial, la definición de la solución. ¿Qué implica definir la solución con una semántica de información?

El lenguaje de un Arquitecto de información que define soluciones de gestión se construye a partir de un concepto clave: los Objetos de información, las estructuras o legos que se combinan en la funcionalidad de la aplicación y que definen en forma particular los cimientos del problema y de su solución (Ver Estructuras de información, qué son y para qué se usan y Propiedades de objetos de información). Hemos señalado lo importante que es la definición temprana de la lista de objetos de información (ver) que definen la aplicación. Esta lista es clave para tener idea de la complejidad del problema que encaramos.

Metodológicamente una primera lista de objetos de información debe realizarse, lo más rápido que se pueda, en la fase de definición o conceptualización de la solución, la primera de las fases del ciclo de vida de la solución (ver).

Cabe la pregunta de si es adecuado elaborar una lista de objetos de información desde el principio, en un momento en que, cómo no se ha diseñado aún la solución, carecemos de muchos de los detalles que afloran más tarde, en el momento del diseño. La respuesta es que si bien la precisión en la lista de objetos de información, su confección definitiva, es un tema central en la fase modelado de la solución, ocurre que al principio del ciclo de vida necesitamos tener una idea del tamaño del proyecto que vamos a acometer y es muy difícil afrontar esta tarea sin estimar de alguna forma cuán grande es la estructura de información que manejaremos.

En Arquitectura de Información el tamaño de una estructura de información viene dado esencialmente por la cantidad de objetos de información, la complejidad de sus propiedades, la cantidad de interrelaciones o asociaciones entre ellos y una estimación de un aspecto muy concreto de la funcionalidad: el número de salidas especiales que necesitaremos.

Este trabajo es el que llamamos Modelo preliminar de información, y se suele representar en un diagrama que es mucho más sencillo, menos cargado y por tanto más comunicativo para todos los involucrados que el que usan los ingenieros para representar las estructuras de datos, que resulta demasiado técnico y sofisticado para ser compartido por los roles no especialistas en informática.

El objetivo del Modelo preliminar de información no es la perfección del modelo como representación de la aplicación, sino la comunicación de los aspectos esenciales y la comprensión del tamaño de la solución. Volveremos un poco más sobre este modelo en nuestro próximo post.

viernes, 5 de abril de 2013

La escritura de casos de uso


Explicar un proceso no tiene por que ser demasiado complicado
En nuestros últimos post hemos estado hablando sobre los casos de uso: un importante instrumento de comunicación de lo esencial de un proceso de gestión de información: los actores que intervienen, los pasos que realizan y las decisiones principales que toman. Hemos hablado sobre su valor en las distintas etapas del ciclo de vida de una solución, sobre la importancia del seguimiento de sus cambios y la relación con la calidad de la solución, sobre los problemas y las polémicas que se presentan cuando se documentan en exceso los procesos, aportando más confusión que claridad. Queremos cerrar estas conversaciones con unas recomendaciones sencillas acerca de cómo escribirlos.

En primer lugar es bueno observar que no es conveniente creer que hay una receta válida para todos los casos. Lo que hay son experiencias utiles que muchas veces pueden funcionar.

Una de la primera recomendaciones es identificar los actores, las entradas y las salidas claves de un proceso. Recordemos que los actores pueden ser personas o sistemas o módulos programados. Identificar las entradas y salidas principales suele ser sencillo, porque las salidas principales son normalmente la razón de ser del proceso y porque las entradas son los insumos que se requieren. Esas entradas y salidas tienen actores vinculados.

Lo siguiente es descubrir los pasos intermedios. Suelen ser de cuatro tipos básicos: Solicitar información al actor, Proporcionar información al actor, hacer un trabajo en nombre del actor, tomar una decisión. Obviamente las frases y relaciones concretas son las que describen lo específico.

Sorprendentemente estas orientaciones suelen ser suficientes para trabajar y explicar casi cualquier proceso. Al menos cuando se trabaja en Arquitectura de información. No se requiere abundar con muchos detalles la descripción de un caso de uso ya que como vimos la semana pasada (ver Corto y simple de entender es mejor) mucha información puede ser demasiada información. La interfaz de usuario, los formatos, los requisitos no funcionales (ver Después de la visión viene la lista de requisitos), las fórmulas o las reglas de negocio pueden ser relevantes en el plan de trabajo con el que se desarrolla una solución, pero estorban al comprender el proceso y describir los casos de uso.

Cuando de explicar un proceso se trata, es importante centrarse y lo que interesa en la descripción de un proceso es cuándo el usuario o el sistema proporciona información, cuándo el usuario o el sistema la solicita, cuándo el sistema realiza un cierto procesamiento y cuándo el usuario o el sistema toma una decisión que compromete el flujo posterior del proceso.

Así trabajan los Arquitectos de información, de una manera naturalmente ágil y eficiente, escribiendo casos de uso cortos y comprensibles, que evitan la hiperdocumentación al tiempo que logran la efectividad que se requiere para una solución bien diseñada, desarrollada e implantada. Como señala Martin Fowler, escribir casos de uso largos, durante semanas, más que un buena señal, es un indicador de que la descripción que se espera y necesita, no se está haciendo bien.