Mensaje de Navidad 2013

Nos vemos de nuevo en enero 2014, después de la llegada de los reyes.

Recomendaciones para la implementación de una solución

La fase de implementación o de transicición puede ser más complicada de lo que
aparenta en la planificación. Pero hay recomedaciones que pueden ayudar y que
los gerentes deben tomar en cuenta

Durante todo el año hemos descrito el ciclo de vida de las aplicaciones desarrolladas con buenas prácticas de calidad y  una correcta Arquitectura de información como un espiral que transita cinco fases: Definición, Diseño, Desarrollo, Implementación y Producción. La semana pasada entramos en los problemas que se originan al intentar implementar una solución previamente desarrollada y vimos que, con independencia de la completitud, lo ingenioso y lo bien realizado que estén el trabajo de diseño y la labor de desarrollo de una solución, siempre habrá posibilidades de que se presenten problemas en la implementación porque los ambientes de desarrollo y producción son diferentes, incluso cuando aparentan no serlos en sus indicadores nominales y en las planificaciones.

Siendo así de incierta, la fase de implementación tiene una particular relevancia de la que es conveniente estar conscientes: hasta que no logre su cometido los usuarios no sentirán (y con razón desde su perspectiva) que el trabajo de desarrollo fue realizado, porque, para todo efecto práctico, una solución que no está operativa es una solución que no existe.

Ante esta complejidad podemos preguntarnos si se puede hacer algo para disminuir los riesgos de tener sorpresas durante la fase de transición. La respuesta es que si, que si bien nunca se pueden eliminar totalmente los riesgos, si se pueden minimizar si se realizan cinco cosas que un gerente debe recordar siempre al momento de planificar la implementación dentro de un proyecto.

Se trata de cinco recomendaciones básicas que podemos hacer para la fase de transición. En esta oportunidad las enumeraremos e introduciremos muy brevemente y dejaremos para siguientes ocasiones la ampliación con más detalles. Las recomendaciones son:

1. Establecer explicitamente los criterios de validación
2. Validar la aplicación en el servidor de desarrollo
3. Comenzar la transición en forma temprana, antes de concluir la construcción.
4. Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción
5. Considerar que algunos ajustes pueden ser hechos durante la etapa de producción

Establecer explicitamente los criterios de validación
Tener claro los criterios que debe cumplir la solución construida para poder considerar la tarea realizada elimina subjetividad en las decisiones y una peligrosa fuente de malos entendidos entre las personas involucradas.

Validar la aplicación en el servidor de desarrollo:
Cada cambio de ambiente operativo introduce nuevos posibles puntos de falla e involucra otras personas por lo que es importante tener los criterios de aceptación bien definidos antes de pasar de un ambiente de trabajo a otros.

Comenzar la transición en forma temprana, antes de concluir la construcción:
Hay tareas de transición que pueden hacerse cuando aún se está construyendo y resulta recomendable realizarlas así, cada vez que sea posible.

Hacer la transición en dos etapas: primero a un servidor de preproducción y luego al servidor de producción:
Cuando no hay ambientes de preproducción en las instituciones hay más riesgos. Cuando los hay, se debe usarlos sistemáticamente.

Considerar que algunos ajustes pueden ser hechos durante la etapa de producción:
No se debe jugar al todo o nada. Es importante siempre un poco de flexibilidad en el camino que conduce a una transición plena al ambiente de operaciones final.

Estas cuatro recomendaciones básicas merecen comentarios adicionales. En siguientes oportunidades ampliaremos los detalles…

La implementación de una solución

Llevar una aplicación desarrollada al ambiente de producción
es una tarea que luce simple pero que puede ser bastante compleja

Con alguna frecuencia los desarrolladores jóvenes piensan que la construcción de la aplicación es el final de la complejidad, casi el último recodo del difícil camino de crear una nueva solución y, por tanto, el fin de los problemas técnicos de envergadura. Ojalá fuera así, pero muchas veces no lo es. No es lo mismo una solución construida que una solución en producción. Entre la aplicación desarrollada y la solución habilitada en condiciones  reales, útil a los usuarios y a la institución para los cuales fue desarrollada media un trabajo, el de la fase de implementación o de transición. Cuando no se ha hecho la tarea luce como sencilla, pero el trabajo no siempre es tan simple como aparenta y el camino de la transición suele estar lleno de sorpresas. Aunque en algunos casos la transición al ambiente de producción puede hacerse en un tiempo relativamente corto, a menudo surgen inconvenientes e imprevistos por lo que la fase de implementación requiere el concurso de competencias técnicas y gerenciales.

Con toda una fauna diversa de variables de hardware y de software, de capas y de interdependencias, el hacer que una aplicación de mediana complejidad trabaje en un segundo servidor, en el ambiente de producción de la institución de destino, es un trabajo en el cual pueden surgir imponderables que en ocasiones pueden hacer que una tarea supuesta a realizarse en horas se tenga que realizar en días, incluso en semanas, y luego de vencer toda una serie de dificultades.

El origen de los problemas tiene que ver con que el ambiente de desarrollo, en el cual trabajan los constructores nunca es exactamente igual al ambiente final en el que la solución desarrollada debe operar. La implementación no es copiar archivos, generar las condiciones iniciales en las bases de datos y configuraciones de la aplicación y pulsar un icono de invocación. Muchas veces es así la teoría, pero la práctica puede ser distante de ese desiderátum.

Todos los sistemas tienen versiones y subversiones, las condiciones de uso de una plataforma operativa cambian después que se han instalado y desinstalado capas de software, los discos se llenan, las plataformas de producción pueden implicar múltiples servidores con necesidades adicionales de establecimiento de permisos en ellos, hay cortafuegos y antivirus que pueden están presentes en producción y no haber sido considerados durante el desarrollo, los estándares de la industria al final dependen de sus implementaciones y esto hace que no todos los supuestos estándares siempre se comporten consistentemente, algunos servidores pueden requerir de pasos de configuración que los implementadores no tienen registrados en sus procedimientos, el ambiente de producción tiene una historia previa que es muy diferente de la de los ambientes de producción, la ingenuidad de algunos técnicos los lleva a veces a pensar que un cambio en la subversión de un paquete es algo trivial que debe resultar irrelevante, la burocracia administrativa de la red de destino puede marcar pautas que generan retrasos, en fin, cualquier variable ignorada o de apariencia intrascendente en una planificación puede saltar al momento de implementar lo que ya está desarrollado.

Lo triste del caso es que para los usuarios finales y las contrapartes de los desarrolladores la solución no existe si no está implementada, por muy grande que haya sido el trabajo de los constructores y por muy completa y eficiente que haya sido la fase de desarrollo.

Los componentes básicos de una aplicación moderna incluyen interacciones con el sistema operativo, el sistema de archivos, el sistema de gestión de bases de datos, el servidor de Web, el o los servicios de páginas Web dinámicas, el o los sistemas de mensajería y el uso de determinados clientes Web. Todo ello son posibles puntos que podrían generar  dificultades al momento de hacer la transición de una aplicación desarrollada al ambiente de producción. Debido a lo señalado el trabajo de hacer una transición desde el ambiente de desarrollo al de producción es una fase delicada, compleja y llena de posibles puntos de fallas, por lo que tendremos que hablar más sobre ella…

La inteligencia de las personas no garantiza los resultados

Mejor equipos geniales que personas geniales.
Los mejores resultados no los producen las personas inteligentes,
sino los equipos de alto desempeño.

La semana pasada estuvimos hablando de las buenas prácticas de trabajo durante el desarrollo de soluciones de gestión de información producidas con tecnologías de la información y conceptos de Arquitectura de información. La conclusión incluyó el énfasis necesario que hay que hacer en los métodos, en los procedimientos definidos y gestionados, en la mejora continua de procesos, realimentado la organización que desarrolla con el análisis permanente de los resultados, buenos o mejorables, de cada tarea. Quedó la pregunta planteada de si, como muchas veces se cree, lo que se necesita es contar con las personas particularmente inteligentes, al punto de hacer ésto el centro casi exclusivo de la atención, dado que hay una cierta consciencia de que los resultados que se obtienen desde una persona u otra son muy variables. La respuesta que dábamos es que no es así y que la garantía final de buenos resultados estaba en métodos y procesos. Es el punto donde continuamos hoy.

Aclaremos de entrada que no queremos decir que cuando hay métodos y procedimientos los resultados sean siempre buenos o que las personas no se equivocarán. Los errores y los problemas son siempre inevitables. Lo que afirmamos es que cuando se hace el trabajo bien, dentro de procedimientos maduros, métodos definidos y mejora continua de procedimientos a partir del análisis permanente de lo que puede ser mejorado, los resultados satisfactorios tienden a ser la norma y, si los métodos y procedimientos se mejoran constantemente, los buenos resultados será cada vez más repetibles, gestionados y el desarrollo será así optimizado.

A veces se cree que las personas brillantes es lo que hay que buscar en los equipos. Esta creencia es un error que tiene sus fundamentos. Es cierto que una persona genial puede hacer veinte veces más que una promedio (No hay error ni exageración en la afirmación. Una persona bien competente puede hacer el doble o el triple de una promedio. Pero una muy competente puede producir diez o veinte veces más). Pero hay dos elementos que hay que tomar en cuenta. Uno que las virtudes de un equipo son siempre mayores a las de las personas, por lo que es mejor contar con gente que sabe trabajar con otros en equipos de alto desempeño, que descansar sobre resultados impredecibles productos de las mentes geniales.

Por otro lado, la manera de prevenir los problemas ligados a los errores humanos no es trabajando con personas que no se equivocan, sino con procedimientos a pruebas de errores que hacen evidentes las fallas y disparan las actividades que generan correctivos.

Los métodos y los procedimientos realizados por equipos integrados y bien coordinados son los que conducen las buenas experiencias. A su vez, las experiencias (buenas y malas) deben usarse para refinar los métodos. Es decir, si hay algo que falló, los constructores deben preguntarse cómo pueden evitar esa falla en el futuro. De qué manera pueden mejorarse los métodos de trabajo y los procedimientos para que los problemas analizados no se presenten o, al menos, los resultados indeseados se detecten con poco esfuerzo en forma temprana.

Cuando nos damos el tiempo para hacer este tipo de reflexión, y analizamos, concluimos y producimos mejoras a los métodos y procesos como una práctica recurrente, los buenos resultados se repiten sistemáticamente.

Los métodos para construir

La construccíón de muros de piedra y de soluciones de tecnologías
de la información se realiza mejor y produce buenos resultados
si se trabaja con métodos y se siguen procedimientos
que son analizados y revisados
(Fotografía tomada de http://www.themarthablog.com)

Para construir buenas soluciones de gestión de información es importante, crucial en nuestra opinión, tener un método. Probablemente un conjunto de métodos enmarcados dentro de una metodología consistente. Esto es tan importante que decirlo debería resultar una trivialidad. Sin embargo, en la práctica, son muchos los casos en que el uso de metodologías no es lo que priva. La presión que ejerce la necesidad urgente de resultados, descontextualizada de qué es lo que asegura los buenos logros y evita el retrabajo, el deslumbramiento que producen ciertas herramientas, el desconocimiento de las prácticas elementales de gestión de la calidad de algunos desarrolladores y organizaciones, la ausencia de cultura de procesos, son algunos de los elementos que inciden en que se no sean pocos los casos en que se trabaje sin métodos ni metodologías.

La verdad es que los hechos están allí y las buenas prácticas internacionales muestran que si se desea garantizar buenos resultados, productos del trabajo satisfactorios y conforme a especificaciones y un cumplimiento razonable de los calendarios, es importante trabajar con métodos y diseñar, mejorar y seguir procesos.

Toda buena solución desarrollada con herramientas de tecnologías de la información es siempre el producto de una serie de interacciones e iteraciones. Interacciones entre todas las personas involucradas que hacen sus aportes respectivos en cada una de las fases de proyecto e iteraciones dentro del equipo de desarrollo refinando por aproximaciones sucesivas un resultado que por definición nunca está acabado, dado que siempre es perfectible y se tiene conciencia de que puede mejorarse, en su presentación, en su facilidad de uso, en su funcionalidad, en su flexibilidad, en su adaptación al usuario, etc. Todo esto dando por descontando el cumplimiento de los requisitos que fueron planteados en las fases tempranas del proyecto.

Si las cosas son así, tiene que haber un criterio para decidir cuando la construcción está lista para ser entregada y que debe pasarse a la etapa de transición con el objeto de que, finalizada ésta, la solución construida pueda entrar en producción. Este criterio es la validación final, donde los constructores, sus contrapartes y los usuarios certifican que la solución construida está lista para transferirse al ambiente de preproducción.

Pero ocurre en el camino, que mientras se construye, e incluso durante la transición, las iteraciones continúan. Es por ello que el uso de métodos y procesos es fundamental. Métodos y procesos es la única garantía de mejoras continuas en el refinamiento sucesivo que mencionamos. Si no hay métodos, en cualquier momento, en cualquier iteración, alguno de los desarrolladores hará algo mal con consecuencias negativas ya que puede que los malos resultados no sean detectados hasta muy tarde en el tiempo y en los cronogramas.

Es por ello que los métodos y los procesos hacen diferencias, especialmente cuando la organización que los usa los revisa y mejora constantemente. Muchos constructores, inadecuadamente, se confían y se dejan llevar por la apreciación de que se tiene en un instante un buen resultado. Lamentablemente estos buenos resultados son seguidos estadísticamente, en las próximas iteraciones, por los malos, ya que la concentración en los productos y no en los métodos y procesos hace que los problemas, inconsistencias y errores, inevitables en el tiempo, no sean detectados y corregidos.

Tener personas competentes ayuda a la producción de buenos resultados, pero no sustituye la necesidad de colocar el acento en los métodos y la mejora continua basada en procedimientos y procesos como lo expondremos con más detalles en una próxima oportunidad.

Pruebas de comunidades y seguridad

La importancia de probar la seguridad salta a la vista,
pero hay algunos detalles que conocen los
 Arquitectos de información de experiencia que vale la pena revisar

Coherentes con el discurso general que hemos mantenido de que una aplicación con una buena Arquitectura de Información tiene cinco dimensiones: Estructura, Funcionalidad, Navegación, Seguridad y Estética y que todo lo que se construye en la fase de desarrollo debe probarse, y habiendo hablado ya de las pruebas de las tres primeras y de la última, dedicaremos el día de hoy a hablar del importante e insoslayable tema de las pruebas de seguridad. La importancia salta a la vista, pero hay algunos detalles que conocen los Arquitectos de información de experiencia que vale la pena examinar.

Las pruebas de seguridad deben permitirnos corroborar que la solución que se construyó cumple a cabalidad las especificaciones que la fase de diseño legó a la fase de desarrollo en cuanto a los perfiles de las comunidades de usuarios que usará la solución automatizada en la que trabajamos. Cuando esto es así es posible confiar en los resultados y operar con la aplicación construida en forma segura y consistente.

Cuando el proceso de desarrollo es guiado con una Arquitectura de Información definida y bien establecida, (ver Las cinco dimensiones de la Arquitectura...) y se usan herramientas apropiadas, la funcionalidad debe poder desarrollarse con independencia de las comunidades de usuarios y la seguridad. El énfasis cuando se trabaja con la funcionalidad es que todos los casos de uso definidos se comporten según lo especificado en el diseño, por eso, salvo las pruebas que involucran la funcionalidad que está dirigida al público anónimo no identificado, es válido, en las primeras etapas de la fase de construcción, hacer las pruebas funcionales sin reparar en los permisos. Esto equivale a hacer verificaciones de resultados operando el sistema con la figura de un administrador o súper usuario al que le es permitido hacer todo tipo de cambios.

Lo que se establece durante el proceso de construcción de la seguridad es precisamente qué es lo que cada comunidad de usuarios puede hacer con cada objeto de información y esto debe poder definirse y redefinirse para cada comunidad sin afectar adicionalmente las otras dimensiones del desarrollo y las otras comunidades. Simplemente se recorre cada perfil de usuario y se establece qué puede hacer y qué no puede hacer y, de nuevo, si las herramientas de desarrollo usan criterios de Arquitectura de Información, los resultados deben cumplir las especificaciones diseñadas.

Las pruebas de seguridad deben alinearse también con los casos de uso (ver Conceptualización de la solución y casos de uso). Para cada comunidad hay que probar que puede hacer lo que está definido que puede hacer en cada caso de uso que es válido para ella. También hay que probar que no puede hacer lo que está definido que no puede hacer. Son dos tipos de pruebas que son complementarias porque se no sustituyen entre sí.

Es muy importante cuando se vayan a hacer las pruebas de comunidades y seguridad llevar un registro de cada prueba y cada resultado y dejarlo grabado como línea base debido a que es imprescindible en un desarrollo confiable que estas pruebas con cada comunidad se automaticen ya que, en ningún momento, debería haber dudas acerca de la confiabilidad con que se trabaja al usar una aplicación. Resulta imprescindible por tanto poder ejecutar  las pruebas de seguridad cada vez que se cambie cualquier variable involucrada en el sistema, así se trate de un elemento aparentemente intrascendente. Esto debe convertirse en un hábito.

Un error de algunos desarrolladores nóveles es suponer que como se probó para dos comunidades y todo trabajó bien se puede extrapolar el buen esultado y suponer que todo seguirá trabajando bien con las restantes que son del mismo tipo. Esto no es necesariamente cierto y lo razonable es probar con cada comunidad de usuarios y automatizar las pruebas para que el hacerlas con todas no sea limitado por el tiempo y el trabajo que tales pruebas involucran.

Probar la estética

La funcionalidad y la estética se interrelacionan, pero deben poder
desarrollarse y probarse en forma paralela.
(la imagen que muestra aspectos de estética y funcionalidad en un
vehículo eléctrico esta tomada de checkeredflag.com)

La semana pasada comentábamos que la frase de que todo lo que se construye cuando se realiza una solución de gestión de información debe probarse incluye no sólo lo meramente funcional y los aspectos más informáticos como la estructura de información y la seguridad, sino también características que tradicionalmente no se consideraban objetos de pruebas sistemáticas como la navegación y la estética. Dedicamos en esa oportunidad nuestro post a las pruebas de la navegación, por lo que hoy nos centraremos en la conversación sobre las pruebas de la estética.

Sobre el papel de la imagen y la estética ya hemos hablado en otras oportunidades (Ver por ejemplo: ¿Por qué considerar la estética?, Imagen y estética: la quinta dimensión en Arquitectura de Información, El diseño de la imagen y la estética y La imagen y la Estética deben ser paralelas).

Es para todos claro que la estética trasmite y representa la imagen institucional, pero su rol va más allá de la institucionalidad ya que según como se implemente puede hacer más usable o menos usable una aplicación. Por ejemplo, un encabezado institucional grande en la pantalla puede hacer la salida muy elegante y bonita, pero quizás quita demasiado espacio útil y obliga al usuario a desplazarse abajo y arriba para ver contenidos, enlaces o botones, dificultando con ello el uso. Todo esto aunque la funcionalidad esté correcta.

Al igual que ocurre con aspectos como la navegación, es importante que las personas que construyen la estética puedan moverse y hacer cambios con independencia de quienes implementan la funcionalidad. Esto hace el desarrollo de una solución de gestión de información más eficiente y versátil. También tiene impacto en el mantenimiento y las modificaciones que se pueden hacer más adelante para acoplar, por ejemplo, una aplicación a un cambio de imagen institucional o a una campaña circunstancial. Es muy diferente en esos casos el poder tener o no la confianza de que la tarea puede realizarse y probarse sin el concurso de los constructores de la funcionalidad, pero estando seguros de que lo que se hizo no trae implicaciones indeseadas.

Hay, por supuesto, una prueba final que debe hacerse presentado la estética a quienes deben aprobar la imagen institucional. Pero mientras se construye la aplicación hay elementos ligados a la estética que deben tomarse en cuenta: la separación de contenidos y estilos, por ejemplo.

La fase de construcción exige el respeto a la disciplina en los nombres que se dan a cada cosa. Los Arquitectos de información saben que durante la fase de diseño deben definir los campos, los objetos de información, sus códigos y sus nombres. También el uso de bases de datos requiere de una normalización de los nombres de tablas y campos. Así, los encargados profesionalmente de la estética deben saber que estilos de presentación de la información (en la práctica presente especificados en lenguaje CSS) deben ser normalizados para facilitar el trabajo de desarrollo de hoy, así como el de los cambios que vendrán mañana.

Poder atender sugerencias de cambios sin tener que temer a implicaciones que impactan la funcionalidad es una capacidad de las aplicaciones con una buena Arquitectura de información que, entre otras cosas, requiere que se tenga siempre a la mano la posibilidad de validar el funcionamiento correcto de todos los servicios después de un cambio de imagen y estética y no trabajar sólo con la presunción de inocencia de estos cambios.

Probar la navegación

La prueba final de la navegación debe hacerse con usuarios reales,
emulando procesos reales y usando datos reales
 (imagen tomada de http://es.kioskea.net)

En las explicaciones de la fase de desarrollo dentro del ciclo de vida de una solución de gestión de información, llegamos a la actividad de pruebas diciendo que todo lo que se construye debe probarse. Dimos algunas pautas sobre cómo probar la estructura de información y la funcionalidad. Hoy queremos comenzar a referirnos a dimensiones diferentes, que no suelen ser muy consideradas por muchos constructores al hablar de pruebas, pero que siendo consistentes con nuestro discurso de que todo debe probarse, hay que tomarlas en cuenta también. Es el caso de la navegación y a la estética. Dedicaremos el post de hoy a las pruebas de la navegación y dejaremos para uno siguiente las pruebas de la estética.

En un sistema bien desarrollado desde el punto de vista de Arquitectura de Información la navegación y la estética agrupan características que deben poder ser desarrolladas como dimensiones, es decir, en forma independiente de la funcionalidad. ¿Qué significa esto y por qué es importante?

Significa que con toda la estructura de información desarrollada y con toda la funcionalidad implementada debe ser posible realizar cambios en la navegación o la estética de un sistema sin afectar el funcionamiento correcto de la aplicación. Los cambios en la navegación y estética deben poder ser realizados por personas diferentes a las que definen la estructura de información y la funcionalidad y el funcionamiento correcto debe poder validarse realizando pruebas automáticas, como lo mencionamos en días pasados (Ver Pruebas durante la construcción de una solución). Esto es importante para asegurar la calidad y el mantenimiento futuro de la solución.

La navegación es una capacidad que nos facilita (¡o nos dificulta!) usar un sistema. Nos permite que pasemos de una actividad a la siguiente, de una pantalla de resultados a la otra que sigue como parte del proceso. La navegación se expresa a través de distintos tipos de menús y opciones que son colocados en los diferentes lugares de la pantalla. Hemos hablado de ella en otras oportunidades (ver por ejemplo: Mucho que aprender sobre navegación, Las Áreas básicas de la salida, Los cinco menús modernos, En la Derecha, el menú de opciones complementarias).

Durante el proceso de construcción podemos darnos cuenta que algunos caminos de navegación resultan más sencillos si colocamos (o, a veces, si quitamos) opciones y enlaces. El trabajo de apreciar lo que facilita o entorpece la navegación normalmente lo hace mejor un Arquitecto de Información que un programador o un constructor sin experiencia en los problemas de navegación. De allí que el manejar la navegación con independencia de la funcionalidad facilita el trabajo tanto de unos como de otros. Permite el avance paralelo de la solución y facilita la realización de los cambios que se hacen durante la fase construcción para atender las sugerencias de los distintos involucrados en el proyecto.

Al final del camino la prueba crítica que debe pasar la navegación construida debe ser el presentarle el sistema a usuarios reales y solicitarles que usen la aplicación para hacer actividades que emulen los procesos reales usando datos reales (Ver Los datos para probar). Al hacer esto se debe observar cómo trabajan, escuchar sus observaciones y atender sus preguntas. Eso permitirá entender los esquemas naturales de navegación para esos usuarios. Una vez mas, la actividad de pruebas así realizada con los usuarios debe grabarse para incorporarla a las pruebas automatizadas.

Pruebas de estructura y funcionalidad

Al igual que cuando se hacen obras físicas, cuando se construyen
soluciones digitales debe hacerse distintos grupos de prueba.
La fotografía está tomada de la sección de Estructuras
 resistentes a terremotos de la Wikipedia

La semana pasada estuvimos hablando acerca de la importancia de la actividad de pruebas durante la fase de desarrollo para asegurar la confiabilidad de la solución que se construye. Señalamos todo lo que había que probar: estructura de información, funcionalidad, navegación, seguridad, estética, pero hicimos el énfasis en la necesidad de disponer de un plataforma que permita la realización regular, y metódica de  pruebas automáticas. Hoy continuaremos hablando acerca de aspectos vinculados a las pruebas que todo gerente de información debe conocer, pero dirigiremos nuestro foco a comentar los distintos elementos que deben probarse, señalando algunas estrategias generales para hacerlo en el caso de la estructura de información y la funcionalidad.

Pruebas de la estructura de información
Cuando la gente piensa en pruebas, generalmente piensa en las pruebas de funcionalidad. Cómo saber si la aplicación desarrollada o en desarrollo cumple o no con un determinado requisito funcional. Pero, como hemos señalado (ver Pruebas durante la construcción de una solución), la funcionalidad no es todo lo que se prueba. ¿Cómo, por ejemplo, se puede probar la estructura de información? Si los objetos de información creados, los metadatos distinguidos en ellos y las relaciones o asociaciones entre estos objetos fueron construidos correctamente, de acuerdo con lo planificado, o si hay omisiones que se pasaron por alto en el camino?

La respuesta se obtiene a través de la comparación entre lo diseñado y lo creado. La estructura de información se condensa en tablas, si se dispone de una plataforma que pueda sacar estas tablas del prototipo desarrollado, se puede comparar estas tablas del prototipo con las tablas producidas durante el diseño. De esta forma se puede saber si todo la estructura ha sido creada alineada con el diseño o, en caso contrario, cuáles son las diferencias entre lo inicialmente diseñado y lo finalmente construido.

Una vez más la comparación debe realizarse con pruebas automáticas ya que los seres humanos somos más lentos y pasamos por alto muchos detalles por lo que somos demasiado propensos a error como para realizar tareas de comparación confiables. En lugar de ello las pruebas se realizan a través de la creación de una línea base que establece de alguna forma el producto deseado y una línea de comparación que señala lo obtenido. Ambas deben entonces poder ser comparadas automáticamente con una herramienta que señale con precisión las diferencias. Sobre estas diferencias entre lo diseñado y lo construido  las capacidades humanas si pueden emitir juicio para determinar si son aceptables, porque representan cambios esperados o discrepancias que no impactan el resultado operacional, si son anomalías que deben orientarnos hacia acciones correctivas o diferencias que deben ser analizadas con más detenimiento para ver si se clasifican en el primer grupo o en el segundo.

Pruebas de funcionalidad
En cuanto a la funcionalidad la mejor manera de probarla es a través de los casos de uso. Si estos fueron bien diseñados, de cada caso de uso deben derivarse uno o varios casos de prueba. Cada caso de prueba establece un comportamiento funcional que crea un resultado.

La primera vez la prueba del prototipo se realiza en forma manual y se compara lo obtenido con lo que se esperaba por diseño. Independientemente de lo acertado o no del resultado, este se graba en uno o varios archivos y se establece así una línea base que sirve para mejorar o para verificar el funcionamiento. A partir de este punto de inicio, las pruebas de cada caso de uso deben ser realizadas contra la línea base generada. Si el resultado inicial no estaba bien y el nuevo resultado si lo está, la línea base debe cambiarse. Si el resultado generado previamente si estaba bien la línea base sirve como criterio de verificación de buen funcionamiento de cada nuevo resultado obtenido.

Un conjunto de pruebas confiable se construye de esta manera. Así se realizan decenas, centenares o incluso miles de pruebas automáticas y se conoce cuando y en qué proporción el sistema está mejorando, convergiendo hacia una aplicación correcta y sin errores apreciables. Si los casos de uso están bien diseñados, el prototipo probado iterativamente convergerá adecuadamente. Si los caso de uso tienen insuficiencias, los casos de prueba las tendrán y la aplicación no será confiable.

Pruebas durante la construcción de una solución

Cuando se trabaja desarrollando servicios que operan con
tecnologías de la información siempre hay que probar todo lo que se desarrolla. Además hay
que hacerlo múltiples veces. La caricatura es uno de esos chistes que circulan por Internet:
 "Razones para dejar de probar" (tomado de http://cartoontester.blogspot.com)

Una de las actividades fundamentales que se realiza durante la fase de desarrollo de una solución es la de pruebas. Los profesionales que trabajan con soluciones que implican o requieren del uso de tecnologías de la información saben que todo lo que se construye debe ser probado. Después de que se varía algo hay que volver a probar todo. Pero las pruebas no deben ser algo artesanal, aleatorio, esporádico. Antes bien deben ser actividades  metódicas, sistemáticas y regulares que dejan resultados predefinidos, y que por tanto permiten a gerentes, líderes y coordinadores medir sí o no se está convergiendo hacia una solución que funcionará y cumplirá con todos los requisitos diseñados previamente. ¿Qué se prueba? ¿Cuántas veces se prueba? ¿Cómo se prueba? ¿Con qué se prueba? Son preguntas cuyas respuestas deben estar claras para todos los gerentes y participantes del desarrollo de una solución.

Durante la construcción deben probarse la estructura de información, la funcionalidad, la navegación, la seguridad e incluso la estética. Estas pruebas toman tiempo y consumen recursos y por eso deben ser consideradas durante la planificación del proyecto. Cuando no son incluidas en la planeación es común que luego no se realizan cabalmente porque no se dispone de recursos o tiempo suficiente para hacerlas. Esto es uno de los errores más frecuentes y perniciosos de los desarrollos que no son realizados profesionalmente.

¿Con que datos se prueba? Como hemos señalado anteriormente (ver Los datos para probar), los datos que se usan para hacer pruebas deben producirse durante la fase de diseño. No debe trabajarse con lo que se le ocurre, sin mayores criterios, a las personas que construyen la solución. Debe garantizarse que todos los casos de uso (ver Conceptualización de una solución y casos de uso) se cumplen y que todos los requisitos funcionales son satisfechos. Para ello quienes mejor conocen estas exigencias previas a la fase de desarrollo deben establecer los datos de prueba. Si así se hace, la aplicación resultará en un producto confiable.

Durante todo el desarrollo, e incluso, más allá, durante las fases de implementación y producción siempre ocurren cambios o eventualidades en las condiciones en que se trabajan que requieren volver a probar. Si las pruebas se realizan manualmente, éstas tomarán mucho tiempo y serán poco confiables. Por esta razón en el desarrollo profesional siempre se incluye los recursos y el tiempo para establecer y realizar pruebas automáticas. Un computador puede hacer centenares de pruebas en unas horas, o en unos minutos, una persona no. Un computador puede distinguir con precisión un cambio en un elemento de una salida que una persona puede pasar por alto. Por eso las pruebas manuales no son recomendables: resultan incompletas, inexactas y sus resultados son finalmente aleatorios.

Obviamente no es lo automático en si mismo lo que da calidad a las pruebas. Las pruebas deben ser bien diseñadas, implementadas y realizadas. Cuando así se hace, es cuando cumplen con su función y garantizan la calidad. De otra forma serán poco más que un saludo a la bandera.

Ante un cambio de variable, una nueva característica, un cambio en uno de los elementos de la infraestructura, la mejor decisión es volver a probar todo. Incluso ante un cambio de apariencia completamente inofensiva, el texto de un mensaje, el cambio de posición de un elemento de la pantalla, es conveniente volver a probar. Si las pruebas son algo manual este desiderátum es irrealizable. Si las pruebas están diseñadas, establecidas para su ejecución automática, siempre entonadas y listas para realizarse, se pueden hacer muchas veces, se harán sin dificultad cada vez que hay un cambio y, en muchos casos, pueden hacerse como una actividad de fondo sin impactar las actividades principales, visibles frontalmente.

Las actividades de la fase de construcción

La fase de construcción bien realizada
hace entrar en realidad diseños complejos.
En la ejecución más que en la planificación
 está la debilidad de muchos proyectos...

A la fase de construcción llegamos con un diseño de la solución que queremos. Hemos señalado que un buen modelo, con criterios de Arquitectura de Información, es crucial, pero como apuntamos la semana pasada, suele ser importante construir rápidamente un prototipo que pueda refinarse a través de una secuencia continua de actividades, o que pueda ser la base de un desarrollo de software a la medida que lo concrete siguiendo los procedimientos establecidos de esta rama de la ingeniería. En este post queremos conversar acerca de las actividades de la fase de construcción de una solución de gestión de información.

El desarrollo de la solución es la parte de su ciclo de vida donde ésa se vuelve palpable (Ver La fase de desarrollo o Construcción). No es un proceso lineal, sino un proceso iterativo a través de ciclos que permiten avanzar hacia la concreción de la solución que se desea. El equipo de trabajo que realiza el modelado de la solución no necesariamente es el mismo que el que realiza la construcción. Si este es el caso, es conveniente que haya una comunicación fluida entre ambos equipos.

Una herramienta de desarrollo de prototipos con Arquitecturas de Información definidas permite generar un prototipo a partir de especificaciones del modelo de información: estructura de información, funcionalidad, navegación, comunidades y seguridad, imagen y estética. A medida que la construcción avanza, todas estas actividades pueden realizarse en paralelo. Pero inicialmente hay un orden para el proceso de desarrollo.

Lo primero que debe configurarse y definirse es la estructura de información: Los objetos de información que intervendrán, todos sus campos (metadatos) y sus propiedades. Con este trabajo realizado pueden definirse las asociaciones que existen en los distintos objetos de información, lo cual marca mucha de las interacciones que se realizarán automáticamente en la solución (Ver Estructuras de información. Qué son y para qué se usan).

La definición de la estructura de información permite definir la funcionalidad, las restantes interacciones que debe haber entre los objetos de información (Ver Funcionalidad: La segunda dimensión). Particularmente importantes son las definiciones de las entradas de datos, ya que al habilitarlas podemos comenzar a usar el prototipo haciendo pruebas al diseño, pero esta vez como aplicación ejecutable. Es probable que las entradas y salidas estándares creadas por un generador de aplicaciones moderno a partir de la estructuras de información definidas resulten suficientes inicialmente. Si éste no es el caso, puede considerarse una pequeña variación a partir de ellas.

Con un embrión formado por una estructura de información, un esquema preliminar de entrada y salida que permite introducir y visualizar datos reales y por tanto probar con la data que suministraron los diseñadores de la solución es un paso gigante. Aquí pueden comenzar a detectarse omisiones del diseño, o la incompletitud de sus datos de prueba. El camino a seguir consiste en refinar sucesivamente lo que serán las entradas y salidas principales del sistema asegurándose que la data disponible es suficiente para activar todos los casos de la solución.

Lo interesante para un Gerente de información es entender que la combinación Estructura de información – Funcionalidad puede definir un primer esqueleto de la aplicación que se desarrollará y por tanto puede ser nuestro primer prototipo funcional. Esta aplicación embrionaria no da la idea integral de la solución que se construirá, pero tiene la virtud de que puede usarse como una versión ejecutable que permite cargar y visualizar datos reales permitiendo que los involucrados (más allá del equipo de desarrollo) puedan palpar más dinámicamente las bases estructurales y funcionales de la futura solución.

A partir del prototipo funcional el camino se abre en un trabajo que debe abarcar las cinco dimensiones de la Arquitectura de información ( Ver Las 5 dimensiones...), añadiendo el trabajo de navegación, la definición de los usuarios, la seguridad, la imagen y la estética. Cada dimensión puede trabajarse con independencia, incluso por personas diferentes y, si las herramientas y los procedimientos son adecuados, el producto de trabajo de cada participante de la construcción debe sumarse en un servidor que permitirá que el equipo involucrado en el proyecto y, en particular el líder del desarrollo, pueda hacer seguimiento del estado actual de la construcción.

La Fase de Desarrollo o Construcción

Construcción del estadium olímpico de Londres:
La construcción es la fase en la  que entra en la realidad lo que se ha diseñado.
¡Siempre hay nuevas decisiones para tomar!.

Una vez que se ha hecho el modelo de información de una solución, el reto es hacer realidad la aplicación. Encontrar un camino razonablemente eficiente en tiempo y en recursos para tener trabajando el prototipo de la solución que se ha diseñado. Siempre hay varias alternativas para hacer esto y no todas son iguales en orientación, esfuerzo y resultados. Las organizaciones deben resolver el problema de escoger los desarrolladores y la estrategia de desarrollo. Independientemente del camino y el equipo que se seleccione, la fase de desarrollo es crítica porque en definitiva es en ella en la que se construye la solución, por eso también se le llama fase de construcción.

El ciclo de vida de un proyecto de gestión de información pasa, como hemos señalado, a través de cinco etapas: Identificación, Diseño, Desarrollo, Implementación y Producción (Ver El ciclo de vida de una solución de gestión de información y Desarrollo, Implementación y Producción en un proyecto con Arquitectura de Información).

La fase de desarrollo suele ser percibida como la que permite que todo lo que se ha diseñado entre en la realidad. Es importante que sea una continuación del modelado, que los constructores de la solución partan y respeten el diseño realizado en la fase precedente. Asimismo, también es recomendable una cierta flexibilidad para implementar cambios en el modelo, porque es natural que en esta fase se detecten aspectos que fueron omitidos en el diseño o que aporten nuevas ideas que nacen desde elementos técnicos del esfuerzo de construcción.

Las nuevas propuestas que surgen en el equipo de desarrollo deben ser consideradas y evaluadas. Hay que estar pendientes de su impacto en los calendarios y en los recursos requeridos (Ver Los cronogramas después del modelado) para mantener a todos los involucrados alineados en el proceso de construcción y el proyecto bajo control. Siempre hay riesgos que hay que gestionar con planes de mitigación de eventualidades (Ver Las fechas de un proyecto bien formulado son probabilísticas), pero un rigidez excesiva respecto a la planificación suele ser mas perjudicial que beneficiosa para el proyecto.

Como el producto de la fase de diseño, el modelo de información que la aplicación debe implementar, es en definitiva una abstracción, mientras que el producto de la fase de construcción es una solución que debe funcionar en el mundo real, es muy importante que la estrategia de desarrollo contemple una vía rápida para que los usuarios y el equipo de proyecto puedan visualizar un prototipo funcional. La primera versión de este prototipo puede carecer de aspectos cruciales para la implementación definitiva, pero el mérito es que concreta la solución pretendida en algo que se puede ver y casi operar y por esta razón, incluso cuando se quiera hacer un desarrollo de software a la medida, en proyectos de cierta envergadura suele ser conveniente considerar el uso de alguna herramienta que permita una construcción rápida de un prototipo funcional.

Este prototipo funcional permitirá a algunos usuarios claves, de pensamiento más concreto y sin formación tecnológica, pero con un gran conocimiento de los procesos institucionales, aumentar su participación en el proyecto. Pero además de concretizar las conversaciones de los involucrados, disponer de un prototipo también tiene la virtud de establecer un norte para los desarrolladores que van a concretar la aplicación final. Con el prototipo hay dos maneras básicas de acometer el desarrollo. Una, refinarlo progresivamente, usando la herramienta de Arquitectura de información usada para hacer realidad el primer prototipo y eventualmente programar módulos complementarios requeridos. Dos, usar el prototipo como referencia concreta y desarrollar la aplicación como software a la medida.

Como hemos mencionado en distintas oportunidades, una aplicación hecha con Arquitectura de información tiene cinco dimensiones sobre las que hay que trabajar: estructura, funcionalidad, navegación, comunidades y seguridad e imagen y estética (Ver Las 5 dimensiones de la Arquitectura de Información ). La fase de desarrollo, realizada con herramientas modernas, permite un trabajo paralelo en estas dimensiones.

En un próximo post nos detendremos un poco más en las actividades que deben realizarse en la fase de construcción de soluciones desarrolladas con criterios de Arquitectura de Información..

Las fechas de un proyecto bien formulado son probabilísticas

En un proyecto sofisticado siempre hay condiciones que requieren
reevaluar los cronogramas, los riesgos y los planes de mitigación

Algunos procesos de desarrollo de soluciones de gestión de información son delicados y hay que tomarse el tiempo necesario para minimizar las probabilidades de que ocurran ciertos problemas, aguas abajo, debido a una mala construcción realizada aguas arriba. Algunos gerentes sienten mucha necesidad de correr hacia la entrada en producción de sus soluciones. Y se entiende. Las demoras suelen tener implicaciones económicas importantes. No les falta razón cuando aquilatan la importancia de cumplir los cronogramas y ahorrar costos. Los procesos fuera de control, abiertos y sin hitos que cumplir en el tiempo son ineficientes e indeseables. Pero no manejar riesgos es un sinsentido y, mientras más grande e importante es un proyecto, mayores son las razones para gestionarlos. No se debe pretender cumplir los cronogramas ignorando riesgos. En este contexto hay que tomar en cuenta que las fechas de cualquier desarrollo no trivial no son determinísticas, sino probabilísticas.

Es idílico pensar que un proyecto grande y sofisticado puede desarrollarse sin contratiempos o consideraciones de riesgos. Cuando la NASA desarrolla una misión espacial, sabe que la fecha de lanzamiento no es precisa, sino que es un hito que debe ocurrir después de otros y que debe manejarse como un período cuya precisión se plantea en términos probabilísticos. Mientras más cercano se está de un hito, es más fácil cerrar los intervalos de tiempo, pero ni siquiera al acercarse al final de una etapa las consideraciones son absolutamente predecibles. Incluso el día anterior al lanzamiento hay variables que pueden no estar determinadas. Cuando ya todo está desarrollado, probado y preparado, lo que se sabe es que la partida de la nave será al día siguiente, con alta probabilidad. Un fenómeno de condiciones meteorológicas inadecuadas o un inconveniente de salud de una de las personas críticas, por sólo colocar un par de ejemplos, podría llevar a una suspensión temporal del despegue y exigir un nuevo retraso.

Si las fechas de un proyecto son naturalmente probabilísticas, no expresa sapiencia sino inexperiencia, ingenuidad o ignorancia el pensar o intentar que con puro voluntarismo se pueden pasar por alto los riesgos asociados a la construcción de una solución y cumplir así, llueva, truene o relampaguee, un cronograma que erróneamente se ha planteado en forma determinística.

Con el tiempo, uno va acumulando experiencias sobre buenas y malas prácticas. Hemos visto gerentes ignorar los riegos de saltarse actividades necesarias pretendiendo ahorrar tiempo y recursos, con la triste consecuencia de obtener el efecto contrario, alargar los calendarios y los gastos cuando se presentan las fallas como consecuencia de omisiones y malas decisiones. Alternativamente los tiempos hay que gestionarlos. Administrar etapas y cronogramas de proyectos implica, entre otras actividades, un análisis permanente de determinación de riesgos. Las buenas prácticas de gestión de la calidad recomiendan considerar y reconsiderar los eventuales planes de mitigación, así como explorar alternativas de mejoras que surgen en el camino y que por alguna razón no fueron consideradas inicialmente.

Cuando hay análisis de gestión de conocimiento se pueden descubrir nuevos aspectos que se deben tomar en cuenta en una solución y esto puede ocurrir en cualquier fase del proceso. Ignorar estos factores no es la mejor práctica. Incluir permanentemente nuevos elementos tampoco lo es. El equilibrio está en un punto intermedio que los buenos gerentes deben medir.

Celebrar los cumpleaños de los hijos en fecha precisas es posible porque las acciones están tipificadas, las conocemos, las prevemos y las implementamos. Pero estos son procesos triviales. Un buen gerente conversa las situaciones con los desarrolladores, registra, mide, analiza y toma decisiones. No administra todos los procesos como si sólo se tratara de celebras los cumpleaños de los hijos.

Soluciones de gestión basadas en reglas de negocios

Desarrollar sistemas basados en reglas de negocios requiere
de Arquitectos de Información de gran experiencia

Lo que ocurre aguas arriba no sólo trae consecuencias, sino que, para bien o para mal, se amplifica aguas abajo. Las aplicaciones basadas en reglas de negocios son una alternativa que busca imprimir gran eficiencia a la gestión de información y el desarrollo de soluciones. Tiene la ventaja de que al implementar una gran cantidad de decisiones aguas arriba, facilitan y simplifican el control de los procesos aguas abajo. Obviamente, requieren de Arquitectos de información de gran experiencia para su desarrollo, ya que deben abstraerse las reglas de negocio que subyacen en la institución, muchas veces bajo la forma de conocimiento tácito. El desarrollo y la implementación también son delicados por la concentración que exige el efecto de amplificación mencionado.

Una solución basada en reglas de negocio puede implementarse desarrollando un software a la medida institucional, pero una mejor práctica muchas veces será el uso de alguna plataforma que permita gestionar la información en forma tal que la lectura de las reglas de negocio permita cambiar los flujos de trabajo.

¿Cuáles son los componentes que intervienen?
Un repositorio de reglas de negocio que normalmente tiene la capacidad de almacenar no sólo las reglas actuales sino la historia de las reglas que tuvieron vigencia en ciertos períodos.

Un mecanismo de captura de políticas y reglas de negocio, expresadas en una manera comprensible para las personas involucradas. Este mecanismo debe permitir la inserción, modificación, consulta y eliminación de reglas.

Un mecanismo dinámico de interpretación de estas reglas, capaz de cambiar la funcionalidad y el curso de las acciones según los valores contenidos en las reglas.

La integración de estos tres componentes permite realizar cambios en los procesos de negocios, incluso cambios estructurales, importantes, en forma rápida y fácil, sin que esto implique el desarrollo de software o de bases de datos, salvo los generados en forma automática por el propio sistema.

La posibilidad de hacer cambios en los procesos sin necesidad de desarrollar software constituye una oportunidad de diferenciación institucional ya que proporciona una alta capacidad de respuesta. También permite realizar auditorías basadas en los períodos de vigencias de las reglas.

Más que desarrolladores de software, este tipo de sistemas lo que requiere es de Arquitectos de información capaces de dirigir procesos de abstracción de la lógica implícita en los procesos de negocios institucionales trabajando en forma directa con el personal involucrado. Una vez abstraída, esta lógica plasmada en reglas puede usarse para un desarrollo de software convencional, pero su empleo en un sistema basado en reglas de negocio proporciona más agilidad y eficiencia ya que simplifica el proceso de introducir nuevos productos y servicios, así como cambios en los ya existentes.

Una vez implementada la solución, el personal de las unidades de negocio puede participar, dirigir, implementar y probar directamente los cambios, ya que no se requiere de programación.

Como consecuencia, las aplicaciones basadas en reglas de negocios se implementan en  forma más rápida y resultan de más fácil mantenimiento por lo que ahorran costos en forma significativa. No requieren los delicados, largos y onerosos procesos de desarrollo y prueba de software.

Las reglas de negocio como estrategia de desarrollo

La formulación explícita de reglas de negocio se usa hoy día como una
estrategia coompetitiva para desarrollar sistemas ágiles que responden
más rápidamente a situaciones cambiantes.
Es un proceso intensivo en conocimiento

El uso de Tecnologías de la Información es hoy día un “commodity”, es decir, un conocimiento que está generalizado y que por tanto es una condición necesaria en toda institución, pero no un diferenciador.  Uno de los problemas que tiene que enfrentar un gerente de tecnologías de la información es cómo efectivamente introducir capacidades y soluciones que efectivamente aporten diferenciadores en el desarrollo del quehacer cotidiano institucional. Si lo logra, la institución avanza y se distingue en su categoría. Si no lo logra, la institución sólo se mantendrá alrededor del promedio. Los sistemas de gestión de información basados en reglas de negocio son una de las estrategias que actualmente se usan para distinguirse.

La aproximación “tradicional” en las décadas pasadas estuvo basada en el desarrollo de software a la medida, construido para las necesidades institucionales. La estrategia funcionó, pero hoy día luce como un método insuficientemente dinámico para ser exitoso. Por un lado, suele ocurrir que los cambios en el entorno van mucho más rápido que el desarrollo de software institucional. Por otro lado, cuando se generalizan el uso de herramientas, métodos y prácticas hay una necesidad de nuevas estrategias para toda organización que quiere distinguirse en su sector.

Una buena solución programada no es fácil de construir. Tiene, como hemos visto, un ciclo de desarrollo (ver El ciclo de vida de una solución de gestión de información) que pasa por varias fases. Dentro de estas fáses, el análisis y el modelado de la información es algo ineludible. Sería un sinsentido intentar e incluso pensar en el desarrollo de una solución sin un buen análisis y modelado. Sería una navegación sin brújula que no llevaría a ninguna parte y que sólo ocasionaría gastos. El problema es que después de este trabajo en el dominio del problema y de la información, típicamente hay que implementar lo que la solución implica en el manejo de los datos y, por mucho que las bases de datos son herramientas consolidadas que ayudan a diseñar, modelar y construir aplicaciones, ellas trabajan en el dominpo de los datos y de allí que los procesos de desarrollo de soluciones son típicamente sofisticados y lentos.

Un proceso de información es un cambio que ocurre en el dominio de la información y de un modo natural implica muchos, quizá decenas o centenas de procesos de gestión de datos. Una relación de información conlleva, implícitas, numerosas relaciones de datos y un proceso de negocios, una gestión documental o transacción de flujo de trabajo simple, requiere de implementar numerosas relaciones de información. De allí la lentitud que es característica del desarrollo de las soluciones, la alta tasa de fallas y la gran cantidad de proyectos de tecnologías que se quedan a medio camino y que se cierran sin presentar resultados productivos.

Por eso es de gran ayuda si se logra automatizar el proceso mismo de modelado y construcción del manejo de datos de las soluciones de gestión de información. Esta es una estrategia que viene siendo usada por generadores de aplicaciones que tienen éxito en ciertos dominios verticales.

La formulación explícita de reglas de negocio y el desarrollo de sistemas y soluciones basados en ellas luce como una estrategia claramente diferenciadora, ágil y dinámica. Se trata analizar cada problema de negocio hasta abstraer el conocimiento que subyace y expresarlo en términos de reglas de negocio (ver Formulación de Reglas de negocios). Si luego se logra crear una capacidad de implementar soluciones directamente  a partir de estas reglas el camino se simplifica y la velocidad de implementación aumenta. No es un camino trivial, porque es muy intensivo en conocimiento. Pero es altamente productivo, un auténtico reto para Arquitectos de información, gerentes de negocios, de tecnologías y de información.

Aprender a generalizar: Los valores constantes en las reglas de negocio

Los Arquitectos de Información aprenden a generalizar los
valores constantes en la formulación de reglas de negocio

La semana pasada estuvimos hablando de la formulación de reglas de negocio como una de las estrategias que usan los Arquitectos y gerentes de información para definir o caracterizar las propiedades de un  sistema que deben estar presentes en una solución automatizada, independientemente de las tecnologías que se usen en la construcción de la aplicación. Hicimos una introducción general a lo que las reglas de negocio son y vimos que éstas podían formularse de muchas maneras, si bien en general se recomendaba hacerlo lo más simple y entendible posible. Esta semana queremos complementar un poco el tema de la formulación de reglas de negocio ampliando como, en algunos casos, aunque suene menos simple, debemos buscar la manera de generalizar algunas de nuestras afirmaciones cuando usamos valores constantes.

Valores constantes son números, fechas, cantidades, roles, que resultan puntualmente específicos y que, en el trabajo que nos ocupamos, suenan como valores que permanecen inalterables en el tiempo.

Precisamente lo que ocurres es que, como lo sabe la gente de mucha experiencia, estos valores constantes en muchos casos dejan de serlo. Debido a ello es conveniente que encontremos maneras en que estos valores constantes puedan ser formulados en forma de abstracción simple, por ejemplo, hablando del número máximo, número mínimo, monto crítico, monto máximo de otorgamiento, monto mínimo de transacción, fecha de caducidad de la oferta, período de vigencia, etc. Este tipo de formulación normalmente aumenta la vida del enunciado que le damos a la regla de negocio. Y sólo requiere algunas definiciones adicionales.

Por ejemplo, si decimos "el precio de un grupo de ítems es de un 20 % por encima del costo", la regla queda atada al valor 20%. Si decimos "el precio está definido como el costo multiplicado por el porcentaje de venta establecida en la temporada", estamos en presencia de una regla que puede mantener su vigencia durante varias temporadas, con varios valores de porcentajes definidos para ellas. Por supuesto, nada es gratis en la vida, el cambio requiere que nos demos el trabajo adicional de definir los porcentajes en cuestión para cada temporada. Pero esto es sólo un valor en un sitio establecido, no una formulación de una regla de negocio.

Si nos referimos a “los recaudos para el crédito menor de cinco millones”, estamos en presencia de una formulación de una regla donde la categoría clasificatoria (el crédito menor de cinco millones) queda atada, innecesariamente, a un valor constante. En cambio, si alternativamente formulamos: “los recaudos para el crédito simple son estos”, estamos usando un tipo de enunciado (el crédito simple) que seguramente será más duradero, con la obligación, eso sí, de apuntar en algún lado de algún documento, que el crédito simple es un crédito inferior a los cinco millones.

Con la práctica los Arquitectos de información aprenden de esta forma a redactar reglas de negocio simples, entendibles y con el nivel de abstracción adecuado para que sean más duraderas. Lo interesante es que estas reglas de negocio forman así un lenguaje común que permite al jefe y a los colaboradores, a los diseñadores de modelos y a los constructores, conversar y entenderse en las distintas fases del desarrollo de una solución de gestión de información.

Formulación de “Reglas de negocio”

La formulación de reglas de negocios no nos dice
cómo construir una solución, pero nos aclara en los procesos,
(qué es lo que hacemos) y por ello siempre son parte
(implícita o explícita) de la solución

Una de las técnicas modernas usadas por los Arquitectos de Información para construir modelos de información es la identificación de las reglas de negocio, aquellas características esenciales  que definen el manejo que se hace de la información en una institución dada. Esto es muy interesante porque las reglas de negocio son propiedades de los sistemas de información que son independientes de su implementación tecnológica e, idealmente, si están bien formuladas, son independientes de los valores puntuales de muchas propiedades con las que se gestiona la información en una institución. Atendiendo algunas preguntas que nos llegan a nuestro buzón, haremos un paréntesis para dedicar este post y quizá algún otro para describir un poco lo que estas reglas son y cuán útiles pueden resultar a gerentes de información, profesionales de la informática y arquitectos.

En primer lugar hay que aclarar es el uso de la palabra negocio. La palabra negocio en español tiene varios significados. Aquí la usamos en el primero de estos significados reseñado por el diccionario de la Real Academia de la Lengua Española. “Ocupación, quehacer o trabajo”. Por tanto una regla de negocio es, simplemente, un comportamiento general que se da en la información que manejamos en aquello de lo que nos ocupamos (No debe confundirse negocio con ocupaciones lucrativas, una acepción válida de la palabra en español, pero fuera de lugar en este contexto en la Arquitectura de Información).

Identificar una regla de negocio es descubrir una propiedad o comportamiento que tiene la gestión de información que realizamos.

Una regla de negocio, puede determinar cuándo una transacción puede o no realizarse. Por ejemplo: para que un trámite sea válido en una institución, es común que deben estar presentes varios documentos de soporte que se consideran obligatorios.

Una regla de negocio puede ser un refinamiento particular de una regla de negocio previa, más general. Por ejemplo, podemos decir que un documento está vigente cuando su fecha de caducidad es posterior a la fecha actual. Combinando los dos ejemplos anteriores: para realizar un cierto tipo de trámite requerimos que el otorgante (un rol) revise que estén presentes todos los documentos de una cierta lista de documentos obligatorios para ese tipo de trámites, pero validando además, que estos documentos estén vigentes.

Notemos que las reglas de negocio no son propiedades de una única formulación. Es decir, en una situación dada, puede haber varias declaraciones válidas para una misma regla de negocio. También puede haber reglas de negocio enunciadas en forma más simple o más compleja, más general o más particular. Debido a ello, la recomendación es que Arquitectos de información y gerentes formulen sus reglas en forma relativamente simple, limpia, es decir, lo más entendible posible por las otras personas.

Como solemos muchas veces recomendar, es bueno que nuestros lectores caigan en cuenta que las reglas de negocio son formulaciones que simplemente ayudan a entender mejor lo que hacemos con la información y son por tanto parte de la solución, independientemente de herramientas y tecnologías con que implementemos a ésta. Invertir tiempo en definir reglas de negocios no nos dice cómo construir una solución, pero nos aclara a nosotros mismos el qué es lo que hacemos o queremos hacer.

Los cronogramas después del modelado

Todo proyecto de gestión de información debe plantearse un cronograma
guía. Pero los ajustes después del diseño detallado son obligatorios ya que
las estimaciones hechas antes del análisis de los detalles del problema y la
solución son poco confiables.

Muchas personas creen que el ideal de un gerente es el cumplimiento estricto de todos los cronogramas que se plantean al inicio de un proyecto. La realidad no es así en el desarrollo de sistemas de información. Como veremos en el post de hoy, un gerente que cumpliera de esa forma los cronogramas de inicio de proyecto no sería un buen gerente, sino uno muy malo. De hecho es muy probable que, independientemente de las relaciones de autoridad que mantenga, inherentes a su cargo, alguien así sea muy poco acreditado en el juicio interno de quienes se relacionen con él: colegas, trabajadores, proveedores, clientes. Independientemente de las opiniones que se expresen en forma abierta, seguramente entre los relacionados comentarán acerca de la inflexibilidad, testarudez y dudosos conocimientos de integración y del ciclo de vida de los proyectos del amigo en cuestión. Eso es porque efectivamente, aunque muchos no los puedan verbalizar adecuadamente, hay  elementos dinámicos, propios del ciclo de vida del desarrollo de sistemas donde de veras hay evolución y creación de conocimientos y éstos necesariamente impactan los cronogramas iniciales.

Cómo hemos visto en otras oportunidades (ver por ejemplo El ciclo de vida... y Desarrollo, Implementación y Producción...), toda  nueva solución recorre un camino signado por distintas  fases: definición, diseño, desarrollo, implantación y producción.

En la fase de Definición se conceptualiza inicialmente el problema de información, en la fase de Diseño se trabaja con los detalles del modelo de información que se requiere, en la fase de Desarrollo se realiza la construcción del prototipo inicial de la solución, siguiendo las pautas que marca la fase de diseño y en la de Implementación se realiza la transición de la solución desde el equipo de desarrollo hacia el equipo que se encargará de él en la fase de Producción.

Si el problema no es trivial, si no se trata de un proyecto para seguir haciendo más de lo mismo y por tanto dejando todo sin mayores cambios, lo natural es que en el proceso iterativo de la fase de diseño o modelado se obtenga una mayor comprensión del problema y la solución ya que sólo después de todas sus actividades se logra una definición completa del alcance de un proyecto no elemental. Desde que es concebido hasta que se coloca en producción cada detalle de la solución debe ser sometida a pruebas de concepto de Arquitectura de Información para asegurar la calidad en su definición y/o implementación y este tipo de ajustes son naturales y recomendables, ya que mejoran el conocimiento incluido y la eficiencia del modelo de información a implementar.

Lo anterior significa que cualquier cronograma que se hubiese hecho al inicio del proyecto, antes del diseño detallado, es un cronograma realizado en un momento en el que el tamaño de la solución no podía estar bien definido precisamente por el desconocimiento de todos los elementos que nacen del análisis detallado de la información y la especificación del modelo de gestión. Las ideas iniciales son siempre demasiado bastas como para hacer estimaciones serias. Así como es poco confiable un médico que hace sus estimaciones definitivas antes de la biopsia necesaria para caracterizar un aparente tumor, así es poco confiable el profesional de la información que estima los recursos en forma definitiva y que pretende no hacer cambios en sus ideas después de caracterizar los detalles del problema y la solución.

Siempre que se trabaja con seriedad, los detalles de un buen análisis nos sugerirán una solución más larga o más corta, resuelta mejor con un procedimiento o con otro y por eso los cronogramas de un proyecto bien realizado deben ajustarse después del diseño detallado. No es impecabilidad sino inflexibilidad y  tozudez el ligar el éxito al cumplimiento de lo que se creía cuando no se tenían los detalles. Sería como el médico que se empeña en trabajar con la idea presumida inicialmente de un mal benigno después que se encontró, en el análisis, que el aparente tumor de su  paciente era un linfoma.

Si el proyecto no es pequeño y trivial, si es de mediano tamaño y no se trata de un proyecto que deja todos los procesos más o menos iguales, sino de una auténtica mejora, la sapiencia de la experiencia profesional comienza a brillar en el modelado, ya el que sabe sólo afirma categóricamente después que conoce.

¿A quién le notificamos los cambios?

En un sistema moderno los usuarios son participados en forma
permanente acerca de cada cambio que ocurre en los asuntos que
les conciernen. Pero hay detalles sofisticados en la definición
de estos procesos

No cabe duda que los sistemas de información modernos son más sofisticados que los que hacíamos en otras generaciones.  Es natural. Ahora podemos hacer más y lo hacemos. Los conocimientos y las tecnologías son más evolucionados.  Esa sofisticación se traduce para el usuario de aplicaciones modernas en que ahora, al menos en general,  hacer las cosas debe resultar más sencillo que antes. Pero  la sofisticación también incluye la complejidad. Es un hecho que ahora, en el rol de usuarios finales, podemos hacer cosas que antes no las considerábamos porque eran complicadas. Si cambiamos ahora el punto de vista a las perspectivas de los que construyen las aplicaciones, la sofisticación significa que hoy hay más cosas para especificar. Debemos hacernos preguntas sobre temas de los que antes quizá ni siquiera hablábamos. Es claro que alguna gente tiene ahora que preguntarse cuál es la mejor manera de construir y mantener un robot en la superficie de marte y que antes, cuando esto no existía como posibilidad,  la pregunta no se hacía. Con esta introducción hoy queremos profundizar a partir de una pregunta simple: ¿A quién le notificamos los cambios de estado que ocurren en un sistema?

Lo primero en que debemos hacernos conscientes es que los sistemas de información modernos notifican en forma sofisticada. Una premisa elemental es que todos los usuarios tienen, al menos, una dirección de correo electrónico y que, a través de ella, debe ser participado de los cambios que ocurren en la información de los sistemas y que tienen que ver con ellos.

Las experiencia de compra a través de la red, por ejemplo, nos muestra que al menos los cambios básicos, que el sistema reconoce que hicimos una orden, que nuestra orden fue despachada y que lo que ordenamos se considera entregado se nos informa por defecto en un sistema bien comportado. A partir de allí podemos enterarnos de estados intermedios de nuestra orden, por ejemplo, que lo que ordenamos está en tránsito entre un punto A y un punto B.  Así funciona un sistema moderno.

Notemos entonces de nuevo algunos aspectos de Arquitectura de información de los que hemos hablado: la información está constituida por objetos de información (ver Estructuras de información) y la dinámica de la información (ver Dinámicas de información) se traduce en que estos objetos cambian de estados (ver Transiciones de estado). De lo que se trata entonces es que un sistema moderno, sofisticado, debe informar acerca de las transiciones de estado a los usuarios involucrados (ver Diseño de notificaciones...). Si ahora tomamos la perspectiva del que diseña o del que construye una aplicación moderna debemos hacernos la pregunta de ¿A quiénes notificamos?

La respuesta también es sofisticada y tiene sus aristas. Cada estado definido dentro de un objeto de información de un sistema es un punto de llegada y un punto de partida. Los cambios son transiciones. Esas transiciones tienen que estar asociadas a comunidades de usuarios y lo normal (y el punto de partida por defecto) es informar en la ejecución de cada transición a todas las comunidades de usuarios asociadas a ella. Pero hay dinámicas de construcción de procesos dentro de estas dinámicas de producción (¡que sofisticación!): cuando estamos definiendo los mensajes a quienes debemos notificar es a los usuarios que participan en esta tarea, cuando creemos que los mensajes están listos debemos notificar a los validadores de los procesos, en principio, personas diferentes. Y cuando ya el proceso está definido, los mensajes deben llegar a las personas miembros de las comunidades involucradas en la transición misma (y no a los constructores y validadores de procesos).

La observación interesante es que todo esto es Arquitectura de información. Algo que no es software ni ingeniería sino diseño de procesos de información, de sistemas de información sofisticados, de esos que ahora podemos hacer y que hacemos y que socialmente marcan nuestra cotidianeidad de forma diferente. Los gerentes de información deben conocer la necesidad de este trabajo de Arquitectura de información en la fase de diseño de cualquier sistema moderno, independientemente de las herramientas de gestión de conocimiento, de información, de documentos o de software con la que vayan luego a construir sus sistemas.

Diseño de Notificaciones sobre las transiciones de estado

Las notificaciones acerca de los cambios de estado
deben ser realizadas como parte de un buen
 proceso de diseño de una buena solución

En los últimos post hemos estado conversando sobre aspectos vinculados al diseño de una solución de gestión de información dinámica. Hemos hecho algunos énfasis en la caracterización de los estados (valores críticos que definen donde los objetos de información se encuentran) y de las transiciones de estado: el salto que ocurre cuando en un objeto de información un estado cambia de un valor a otro. Hoy queremos referirnos al diseño de las notificaciones que debemos realizar para participarles a ciertos usuarios la necesidad de su atención a un cierto cambio ocurrido en la información que maneja un sistema.

Como hemos visto un estado es siempre, por definición, una propiedad de un objeto de información que es importante por alguna razón y por ello nos interesa no solamente conocer cuál es su valor, sino su historia de cambios. Probablemente quién hizo cado uno de los cambios previos y cuándo lo hizo. Estos cambios de valores sobre un metadato crítico lo llamamos transición de estado.

Cuando ocurre una transición de estado, por ejemplo, cuando un trámite es aprobado (¡o reprobado!), normalmente hay acciones que hay que realizar dentro de un sistema. Pero muy típicamente hay que avisarles a ciertos usuarios acerca del cambio sucedido, para que estén  en cuenta del mismo, o para que hagan algo.

El mecanismo universal que normalmente se usa para este tipo de avisos es el correo electrónico, si bien es común en algunos casos que los usuarios reciban en forma adicional un mensaje de texto vía teléfono celular.

Lo anterior tiene implicaciones para el trabajo de deben realizar los Arquitectos de Información en la fase de diseño de un sistema. Por supuesto, deben caracterizar los objetos de información con todos sus campos o metadatos. Entre ellos, deben identificar cuáles son estados (campos en los cuales interesan no sólo sus valores sino su historia).  Deben definir los valores posibles que pueden tomar estos campos (el lenguaje controlado) que se usará y las transiciones posibles, a que valores se puede ir desde cada valor previo del estado.

Además deben definir las comunidades (grupos de usuarios) que pueden cambiar estos valores y en ocasiones, que pueden asignar ciertos específicos valores, por ejemplo, aprobar, reprobar o delegar la aprobación.

Finalmente, los Arquitectos de información deben trabajar en las notificaciones: Los avisos de los cambios. Lo más típico es que cada estado tenga un conjunto de usuarios que lo escuchan y un conjunto de usuarios que pueden hacer los cambios. A ambos conjuntos hay que enviarles las notificaciones. Estas deben tener un encabezado, un conjunto de  destinatarios, un cuerpo y un pie. Estos valores deben ser especificados en el diseño de manera que los constructores sepan exactamente lo que deben hacer. El diseño de las notificaciones ante las transiciones de estado es, así pues, un aspecto más que debe completarse en la ejecución un buen procedimiento de diseño de una buena solución.