Cap.10_Puesta_en_marcha

Error! Use the Home tab to apply Título 1 to the text that you want to appear here.
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 ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 1 de 6
Error! Use the Home tab to apply Título 1 to the text that you want to appear here.
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.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 2 de 6
Error! Use the Home tab to apply Título 1 to the text that you want to appear here.

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 este simple
ejercicio se demuestra este punto.

La sub-estimación de las pruebas necesarias: relacionado con los puntos
anteriores está éste, en el cual al estimar las pruebas necesarias para un
producto de software normalmente no se piensa en más de un 2% ó 3% del
tiempo de desarrollo, mientras que todo ciclo de pruebas debiera abarcar al
menos un 30%.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 3 de 6
Error! Use the Home tab to apply Título 1 to the text that you want to appear here.
I.2. MANEJO DE ERRORES
Ahora bien, si ya se está embarcado en esto es evidente que se deberá hacer
frente a numerosos errores en el producto que se está entregando.
Al momento de presentarse un error es imprescindible mostrar una actitud
comprensiva hacia el usuario.
Es usual pretender ocultar la falla intentando buscar el problema fuera de
nuestro círculo de influencia. Dicho de otra forma, es una costumbre tratar de culpar al
usuario de la falla, aduciendo desconocimiento en el uso del sistema, problemas en la
especificación original, etcétera.
Sin embargo, es imprescindible en aras del trabajo en equipo y del logro de los
objetivos estratégicos de la institución en la cual se está trabajando, que la actitud del
profesional de la informática sea esencialmente proactiva en este punto, ya que el
usuario, al sentirse inculpado, podría caer en un ostracismo defensivo, el cual finalmente
se nos tornaría en un problema para nuestro desempeño ya que, y esto nunca lo debemos
olvidar quienes trabajamos en unidades de servicio, el usuario es imprescindible para
nuestro desempeño y una buena relación con ellos será, sin lugar a dudas, un factor
determinante en el éxito de nuestras empresas profesionales.
La actitud proactiva se demuestra con frases como las siguientes:

Por favor toma registro detallado del error para poder revisarlo. Yo te diré
qué es lo que me hace falta.

Te invito a que revisemos los documentos de especificación para
asegurarnos que ambos entendimos lo mismo.

Esto no fue parte de la especificación inicial, pero podemos estudiarlo para
la siguiente versión del sistema.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 4 de 6
Error! Use the Home tab to apply Título 1 to the text that you want to appear here.

Ese problema le corresponde resolverlo a otras personas del equipo, pero
déjame tomar nota para contactarlos y preocuparme de que se resuelva.

Y un largo etcétera...
En términos más concretos y resumidos, se trata de demostrar una permanente
disposición al trabajo en equipo y a resolver los problemas, no a soslayarlos o a derivar
la responsabilidad.
I.3. ACEPTACIÓN DEL CLIENTE INTERNO (RESPONSABILIDADES
COMPARTIDAS)
Una vez completado el proceso de definición, desarrollo, pruebas y marcha
blanca (vale decir, la fabricación) del producto de software, se procede, a través de un
mecanismo formal previamente definido, a cerrar el ciclo mediante una recepción de
parte del usuario.
En general, en el documento de entrega (acta de término) se dejan explícitos
aquellos puntos pendientes del desarrollo.
Lo que corresponde es, como en todo orden de cosas, tener una base
predefinida exigible. Esta base corresponderá a la especificación de requerimientos
hecha en las fases más tempranas del ciclo de vida.
Si se logró una buena definición de requerimientos en el comienzo del trabajo
entonces el nivel de satisfacción del cliente será mayor.
Ahora bien, como se mencionó durante el transcurso de este trabajo, la
definición de requerimientos suele presentar numerosas deficiencias, en particular
respecto a la completitud de las mismas. Si a esto incorporamos las otras variables,
como las reducciones en las estimaciones de plazo, aceleraciones del trabajo producto de
presiones, etc., entonces es poco probable que el cliente se manifieste satisfecho con el
producto final.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 5 de 6
Error! Use the Home tab to apply Título 1 to the text that you want to appear here.
Por el cliente en este caso entendemos a los usuarios reales de un producto de
software, ya que lo acostumbrado es que los niveles jerárquicos superiores concuerden
(entre ellos) que el sistema es justamente lo que uno esperaba recibir y el otro esperaba
entregar.
En este caso el profesional de informática debe cumplir con el rol de defender
lo construido como lo solicitado. Para ello se debe tener un conocimiento cabal de la
especificación de requerimientos y sus modificaciones posteriores, procurando siempre
tener respaldo escrito (grabado) de las solicitudes.
El ciclo de vida de los proyectos TI: una visión empírica
Marco Antonio Rossel
Página 6 de 6