viernes, 31 de enero de 2014

Una implementación bien hecha se hace en dos etapas


Una implementación bien hecha se hace en dos pasos
 de características y objetivos diferentes:
transición de preproducción y transición de producción
En el ciclo de vida de una solución de gestión de información hay un momento en que la solución que se diseñó ya está construida y de lo que se trata es de implementarla, es decir, colocarla en producción. Esto es lo que se llama la fase de implementación o de transición y, como hemos visto en las últimas semanas, tiene sus complicaciones. Es normal referirse a ella como si se tratase de un acto único: “colocar el nuevo sistema en producción”. En realidad una implementación bien planificada y bien realizada debe hacerse en dos pasos, en dos etapas bien definidas, en las que el trabajo que se realiza y los objetivos que se persiguen son diferentes. Mencionamos hoy cuáles son estas dos etapas y desarrollamos en detales la primera, para dejar la siguiente a la semana próxima.

Las dos etapas son: la implementación en un servidor de preproducción y la implementación en el servidor de producción definitivo.

Si la organización que desarrolla la nueva solución no es la misma organización que la usará cotidianamente, es claro que la infraestructura que se dispone en la organización que desarrolla nunca es igual a la que se dispone en la institución destinataria. Incluso cuando se hacen esfuerzos para que así sea, incluso cuando los sistemas operativos son los mismos y cuando el hardware que se usa es básicamente el mismo, siempre hay diferencias prácticas en el conjunto de variables de infraestructura y en el de la historia de uso de las mismas. Estas diferencias hacen que no se pueda asegurar que el hecho de que la solución esté trabajando correctamente en los equipos de desarrollo sea una garantía de que la solución trabajará perfectamente la primera vez que se instale en la infraestructura de la organización destinataria. Esto lo hemos explicado en otras ocasiones y remitimos el lector a ellas (Ver por ejemplo, La implementación de una solución).

Cuando la solución se desarrolla dentro de una misma institución, la buena práctica es no usar un mismo servidor para hacer el desarrollo y para usar la aplicación en producción, y si estos servidores son diferentes, otra vez se hace presente el problema de que no es garantía para el funcionamiento en producción lo correcto del funcionamiento de la aplicación en el ambiente de desarrollo.

El objetivo de la implementación en un servidor de preproducción es asegurar el funcionamiento de la solución desarrollada en las instalaciones y la red de la organización destinataria, sin correr los riesgos que significa intentar una operación directa en producción. ¿Por qué probar y certificar primero en estas condiciones de preproducción? Porque la experiencia internacional muestra que el cambio de red es una variable demasiado fuerte en sus consecuencias como para sumarla con otros imponderables. También porque en preproducción se puede, sin mayores consecuencias, probar ciertas condiciones de estrés funcional, de contingencias eventuales, que en el servidor definitivo, con los datos definitivos y en producción no se podrían hacer sin afectar los procesos reales. Hay más libertad para sumar, borrar y eliminar registros completos, o información parcial, si a fin de cuentas, esto no trasciende ni tiene más repercusiones que la de validar el comportamiento de la solución. Finalmente la transición de preproducción permite hacer el entrenamiento de los futuros usuarios en forma adecuada.

El servidor de preproducción, así pues, permite hacer todas las pruebas, verificaciones y validaciones (ver Verificar y validar), probar todos los flujos y estados de la información, en condiciones casi reales, porque está en la red objetivo, si bien no se trabaja en producción.

En la red de la institución destinataria se podrán hacer pruebas con componentes cuya correcta interacción es necesario asegurar  (tales como antivirus, servidores de correo, servidores Web, servicios de directorio institucional, etc.). Este ambiente no siempre se puede reproducir o simular en forma fidedigna en la red de desarrollo.

Si la validación de preproducción (Ver La validación de una solución) es exitosa se puede entonces realizar la transición de producción con más confianza. Continuaremos la semana que viene hablando sobre ello.

viernes, 24 de enero de 2014

La implementación de la solución debe comenzarse antes de finalizarla


La implementación debe comenzarse antes de terminar la construcción
de la solución
Aunque suena raro lo planteado en el título de este post no hay error en la afirmación. Entonces, ¿Cómo es que podemos implementar una solución que no hemos terminado de desarrollar? La respuesta tiene que ver con el hecho que lo que dice el título no es que debemos realizar la implementación, sino que debemos comenzar a realizarla. Esto es algo que está bien establecido en las buenas prácticas internacionales y que los gerentes, arquitectos de información e ingenieros jóvenes a veces no manejan.

Como apuntamos hace algunas semanas (ver), la implementación de una solución está siempre llena de posibles puntos de falla porque las máquinas y el ambiente donde se desarrolla nunca reproducen exactamente las condiciones de operación que tendrá la solución en producción.

Las aplicaciones de teleinformación que se construyen hoy en día son cada vez más fáciles de usar por sus pretendidas audiencias, pero cada vez más complejas en su interior y en la articulación de sus  componentes, por lo que siempre hay variables de configuración de la infraestructura requerida y procesos de coordinación que deben asegurarse.  Una aplicación moderna requieren de un sistema operativo, un servidor de Web, probablemente una capa de gestión dinámica de páginas Web, sin duda un manejador de bases de datos y un servidor de correos,  una capa de seguridad informática (antivirus, cortafuegos, etc), quizá un sistema de gestión de  la autenticación, etc. Todos estos son sistemas previos que tienen versiones y necesidades de coordinación con capas de software anteriores, laterales y superiores, que deben existir y funcionar conforme a estas necesidades.

Debido a lo anterior, los posibles puntos de falla durante la transición a la producción se multiplican y un buen proceso de implementación debe comenzar antes de que el equipo de desarrollo haya concluido la fase de construcción de la solución. Dejar para el momento en que la aplicación esté construida la instalación, verificación y validación del buen desempeño de estos componentes es iniciar tarde, en forma arriesgada y en condiciones de estrés lo que puede asegurarse temprano, en forma segura y tranquila.

La recomendación, así pues, es comenzar a trabajar en un ambiente de preproducción instalando cada componente operativo que será necesario y asegurándose de que trabaja adecuadamente en coordinación con los otros. Esto implica siempre, para cada uno, una verificación y una validación (Ver Verficar y validar) . Para ello se deben tener criterios claros de cómo comprobar que el componente está trabajando. No simplemente realizar la carga del mismo, su instalación como programa genérico, sino asegurar su operación en las condiciones específicas que será requerida.

¿Por qué descubrir a última hora que, por ejemplo, el servidor de correos tiene una restricción que trabará el desempeño de la solución que se está creando?

En ocasiones hemos visto  repetirse los errores de la ingenuidad e inexperiencia como considerar que porque una capa de software ya trabaja en una aplicación anterior lo hará en esta, o dado que ya salió una nueva versión del sistema operativo entonces usémosla en lugar de la anterior,  y, por supuesto los errores de falta de planificación donde los criterios de validación de capas no están definidos y simplemente se espera que la globalidad de los componentes trabajen sin asegurar los pasos previos, o los errores del encuentro de culturas donde no se deja explícito qué es lo que se entiende como validación (Ver La validación de una solución).

viernes, 17 de enero de 2014

La validación de una solución

La validación en un proceso crítico, interactivo entre grupos diferentes,
una actividad neurálgica donde  hay encuentro de culturas
y presiones para finalizar. Por ello para su ejecución exitosa
se requiere una acertada planificación, acuerdos y métodos
Retomando la conversación sobre la fase de transición o de implementación de una solución, dentro del ciclo de vida de una aplicación de gestión de información, hemos comentado que hay dos actividades que marcan el paso del desarrollo a la implementación, de la construcción de la solución a la transición que permitirá finalmente su entrada en producción. Se trata de la verificación y la validación. La primera es un proceso al interior del grupo de desarrolladores y la describimos la semana pasada. La segunda, la validación, de la cual hablaremos hoy, es una actividad intergrupal delicada y crucial cuya complejidad para ser bien llevada requiere que se tomen las precauciones necesarias.

Si la verificación es un proceso interno que realizan los constructores de la solución, la validación es un proceso de interacción que debe involucrar a desarrolladores, usuarios y contrapartes. El grupo de personas que interactúan en ella trasciende así los límites del equipo de desarrollo y probablemente las fronteras institucionales ya que en muchos casos el personal de desarrollo es parte de una empresa externa a la institución destinataria. Esto significa que, independientemente de los temas técnicos, hay un encuentro de culturas y por ello se debe gestionar un lenguaje común que explicite, sin ambigüedades, los puntos críticos de los acuerdos que serán necesarios.

Es importante realizar la validación bajo un plan de trabajo predefinido y, una vez más, los casos de uso (Ver), convertidos en casos de prueba, suelen ser la guía necesaria para validar que la solución desarrollada está conforme a lo acordado.

Si no se realiza de esta manera pueden hacerse pruebas incompletas que lleven a conclusiones de satisfacción demasiado rápidas, pero más temprano que tarde hay que enfrentar problemas cuando cualquier disconformidad con lo pretendido salta a la vista. También se dan en ocasiones otros casos diferentes, por ejemplo la exageración del significado de un punto de falla encontrado sin tomar en cuenta lo aislado o lo especifico de ése, o que comiencen a salir nuevos requisitos formulados ad-hoc porque a algunos usuarios se les ocurren nuevas cosas, a veces intrascendentes, en ese momento.

Como puede haber presión financiera, de meta cumplida, o de calendario, estos inconvenientes pueden puede darse sin la cordialidad necesaria en el trabajo técnico. La manera de evitar estos problemas, así pues, está en los casos de uso y en los acuerdos acerca de los métodos.

En forma adicional a los casos de uso, es normal que la validación incluya el recorrido de todas las opciones de menú para asegurar que el comportamiento es uniforme y consistente. Cuando se hace bien se deben registrar todas las consultas realizadas y todos los resultados obtenidos con el objeto de poder repetir la validación en forma automática en caso de que haya algunas no conformidades que requieran volver a reiniciar la validación o en caso de que más adelante se necesite realizar un proceso de migración.
Es importante destacar que el recorrido de todos los casos de uso, de todas las opciones de menú y de las comunidades de trabajo involucradas críticamente en la aplicación es una tarea que puede consumir tiempo y así debe considerarse en la planificación.

En síntesis, cuando no hay un plan de trabajo definido para la validación el resultado es cualquier cosa. No se puede concluir nada acerca de la calidad y esto, en la práctica, se traduce en que más temprano que tarde aparecen problemas que los usuarios reportarán a los desarrolladores y que eventualmente, si no son bien llevados,  se traducen en tensiones entre los equipos involucrados. Así podemos concluir en que una verificación mal realizada o el no definir y acordar desde el principio lo que se realizará como validación es activar una bomba de tiempo potencial.

viernes, 10 de enero de 2014

Verificar y validar

La verificación y la validación no deben confundirse
Entrando en el tema de la fase de implementación de soluciones de gestión de información vimos, el año pasado, que hay muchas variables imponderables que generan incertidumbres en relación a las dificultades y los tiempos que requieren los procesos. Observamos en esa oportunidad que, sin embargo, hay cuatro recomendaciones básicas que permiten ganar seguridad en la tarea de convertir una aplicación desarrollada en una solución en operación. La primera de estas recomendaciones es validar la solución en el ambiente de desarrollo antes de iniciar el movimiento hacia los ambientes de producción. Para comprender lo que ésto significa es necesario comenzar por establecer la diferencia entre la verificación y la validación, dando por descontado que ambas son actividades necesarias, que deben realizarse y que no deben confundirse.

La verificación es un proceso interno realizado por los desarrolladores de cada aspecto, de cada actividad, de cada tarea en cada dimensión del desarrollo de una solución. A los constructores les corresponden verificar que lo que recién desarrollaron está correcto. Vale decir, que hicieron bien su trabajo. Las preguntas pertinentes son, así pues, ¿Cómo verificar? ¿Contra qué verificar? ¿Quiénes deben verificar?

La manera de verificar es, en cierta formulación, tan obvia que pareciera trivial. “Se compara lo obtenido con lo que se debería obtener”. Sin embargo, más veces de las que nos imaginamos no es completamente claro lo que se debe obtener y, en ese caso, la obviedad desaparece. Como en condiciones normales lo que se quería obtener se plasma durante la fase de diseño bajo la forma de requisitos y casos de uso (ver Conceptualización de la solución y casos de uso), la verificación implica que se debe comparar lo obtenido con la lista de requisitos y las especificaciones de los casos de uso. La ventaja de éstos es que proporcionan una lista de ordenada de puntos de verificación.

¿Cuándo se debe verificar lo desarrollado? Normalmente los desarrolladores hacen verificaciones parciales en los distintos momentos de la construcción de una solución, pero es imperativo hacer una verificación completa justo antes de la validación ya que esta última involucrará otras personas y procesos. En principio las verificaciones pueden repetirse con frecuencia en la medida en que la construcción se realiza. Para ello es importante ayudarse con herramientas que permiten el trabajo automático, ya que la automatización de las pruebas disminuye el tiempo de la tarea, mejora su calidad y permite detectar tempranamente situaciones de falla. Siempre hay casos donde las pruebas automatizadas no son posibles, pero sus beneficios son demasiados como para prescindir de ellas cuando son posibles.

Las normas elementales de la calidad de procesos recomiendan, finalmente, que toda tarea realizada por una persona debe ser revisada por otra diferente ya que de esta forma disminuyen significativamente las probabilidades de que la solución que se construye transporte errores. No es suficiente y no debe considerarse en ningún caso una verificación formal una revisión realizada por la misma persona que hizo el trabajo, porque muy típicamente las personas repiten las mismas omisiones y las mismas secuencias cuando revisan lo que ellas realizaron, por lo que en la auto revisión las probabilidades de error aumentan.

En nuestro próximo post hablaremos de la validación, distinguiendo ésta de la verificación. Para el éxito de la fase de implementación de una solución ambas son necesarias.