PUESTA EN MARCHA

PUESTA EN MARCHA

La reforma que es grande para un país puede ser minúscula para otro. Esta diferente evaluación que a una misma reforma atribuiríamos en dos naciones distintas no sería, sin embargo, caprichosa. Una misma y única razón nos llevará a llamar aquí pequeño lo que allí llamamos grande. En ambos casos medimos el tamaño de la reforma con la misma unidad de medida. ¿Cuál? Muy sencillo: la cantidad de cosas que en cada país necesiten ser reformadas. Donde casi todo está bien, una pequeña modificación será de gran importancia. Donde casi todo está mal, esa misma modificación resultará imperceptible.

José Ortega y Gasset, ”La Redención de las Provincias II”, Reforma del Estado o Reforma de la Sociedad

Una vez que se logra la satisfacción de parte del usuario, y ya superadas todas las consideraciones políticas de las aprobaciones, las presiones ejercidas desde las diferentes esferas relacionadas con el proyecto y estando convenientemente ocultos los errores y deficiencias que se acordó mantener, llega la tan esperada etapa de poner el sistema en producción, conocido en la teoría como puesta en marcha.

Evidentemente, dentro de la ingenuidad o más bien candor propio de un principiante, se espera que esta parte del proyecto sea prácticamente transparente, ágil, dinámica y dentro de todo lo planificado.

De nuevo, nada más alejado de la realidad.

El primer considerando erróneo en este punto se refiere precisamente a la ausencia de una planificación específicamente diseñada para la implantación del sistema/producto.

Al no considerar la necesidad de planificar esta etapa se suceden una seguidilla de errores que en numerosas ocasiones obligan a rehacer el camino andado en numerosas oportunidades, con la evidente pérdida de tiempo y desazón de parte de los usuarios, que dados los atrasos generados durante las etapas previas del desarrollo, ya hace bastante tiempo que tienen su paciencia más que agotada.

I.1. MARCHA BLANCA ("PRUEBA EN PRODUCCIÓN")

Los modelos teóricos son majaderos en indicar que los elementos de software desarrollados deben ser sometidos a pruebas exhaustivas antes de ser puestos en producción, de tal forma de determinar con antelación si el sistema/producto funcionará cumpliendo con lo esperado, no fallará durante su operación normal y además no afectará el correcto desempeño de otros sistemas con los que se relacione (contabilidad, gestión, facturación, etc.).

No obstante esta exigencia de las metodologías teóricas, bastante razonable por lo demás, la realidad suele situarse bastante alejada.

Varios son los factores que inciden en que la teoría no pueda ser aplicada a cabalidad en este aspecto, a saber:

• La no-exigencia de planes de prueba a los desarrolladores al momento de realizar el diseño: pocas son las organizaciones que se preocupan de las pruebas a realizar sobre un sistema al momento de diseñarlo, y al momento de realizar las pruebas los tiempos comprometidos son tales que solo es posible realizar una prueba mínima, casi siempre tendiente a demostrar que el sistema opera en forma aislada.

• Inexistencia de ambientes de prueba símiles de producción: es altamente complicado levantar ambientes de prueba con esta característica, ya que implica una gran cantidad de recursos.

Estos esquemas, denominados ambientes Q&A, permitirían a los usuarios (ojo, no al desarrollador) realizar todas las pruebas necesarias sobre un sistema, de tal forma de determinar no sólo que el producto cumple con lo esperado, sino además que el mismo no afecte negativamente otros sistemas (típicamente centralizadores como los sistemas contables).

• La omisión de la etapa de pruebas de la planificación del proyecto: por costumbre, mal hábito o simple método personal de trabajo, suele lisa y llanamente omitirse la etapa de pruebas de software del proceso de planificación.

Esto es tan evidente que basta con un simple ejercicio mental para tomar conciencia de este hecho. Imagine el lector que debe desarrollar un programa que sea capaz de leer, insertar, modificar y eliminar elementos de una tabla Oracle (un mantenedor típico).

Si actúa con honestidad en la elaboración de su respuesta, es decir de su estimación, podrá percatarse de que en su primera aproximación no tomó en cuenta realizar pruebas de su mantenedor. Extrapolando

...