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.