|
Error de Procesos en el Desarrollo de
Sistemas
José Enrique González Cornejo
Septiembre 2014
|
Resumen: El artículo es una reflexión acerca de los
posibles errores en el desarrollo y evolución de un sistema computacional. Generalmente, la culpa de
una falla se corta "por el hilo más delgado". Es decir,
la responsabilidad sería del programador, cuando en realidad, se trata de responsabilidades compartidas. En
efecto, por una parte ingenieros-gerentes de procesos en su
labor comercial realizan compromisos y tareas por fuera de las plataforma
que después traspasan. Esta práctica se repite y aumenta
los factores no controlables de variabilidad en el desarrollo. Por otra
parte, los errores propios de código o de confusiones o
lapsus del programador. En síntesis, las fallas en los procedimientos de control;
carencia de consolidación de un
lenguaje
estructurado de comunicación; confianzas desmedidas de los
protagonistas en sus rutinas; salto de pasos en la metodología y
falta a las normas establecidas para
la gestión de calidad.
|
Hace unos días atrás, un joven programador de
DocIRS, realizó una transacción en una de nuestras plataformas
Web que significó un grave error frente a nuestros clientes.
En efecto, una vez desarrollada y probada una
rutina de mejoramiento, la
traspasó a dos plataformas de diferentes clientes en Ambiente de
Producción, en uno de nuestros s servidores que operan sobre Internet.
El problema fue, que una de las funciones
hacían envío de correos con datos adjuntos a dos diferentes
clientes de una de las plataformas, y sus direcciones de correo
electrónico el programador las había escrito en duro dentro
del código, con el fin de probar su rutina en Ambiente de
Pruebas. Sin embargo,
una vez revisada la rutina,
omitió borrar dichas direcciones de correo, de modo que cuando las pasó a producción
contenían el error.
Es decir, estas
direcciones no estaban siendo recuperadas paramétricamente de la
base de datos, ni tampoco verificando los atributos y derechos
correspondientes del usuario, sino que estaban directamente
escritos dentro de la función.
Por tanto, al ejecutarse la rutina dichos
cliente recibieron correos con información adjunta de la otra
plataforma, perteneciente a otra empresa. Afortunadamente, se
trataba de asuntos triviales sin importancia. No obstante, los
usuarios receptores se preguntaron ¿Si me llega información de
otra empresa no será que está pasando lo mismo con mi información?
Frecuentemente los programadores ponen puntos
de control en los código para ir depurando. Obviamente, que un
programador olvide un alert(“hola”) o una
response.write (“jsjsjsjjsjs”) en el sistema pasado
a producción, no
es comparable con el grave error de que enviar información real a diferentes clientes.
Bien, analicemos a continuación las verdaderas causas del error, que obviamente no
son de exclusividad del descuido del joven programador.
Primero, sabemos que el factor humano es
fundamental en todas las tareas relacionadas al procesamiento y
desarrollo de sistemas. Es decir, las tareas de programación
requieren diferentes habilidades, todas las cuales se deben
utilizar en forma adecuada para producir una
correcta
aplicación. En otras palabras, los programadores no son
máquinas, son seres humanos que realizan funciones complejas y
por tanto son susceptibles de cometer errores.
No es trivial recordar a quienes realizan el
diseño funcional y/o formulan los requerimientos, que los seres
humanos somos capaces de tener fallas y a veces muy absurdas. De
modo que para aquellos ingenieros más exigentes y estructurados,
-
les diremos en sus propios términos-, que los humanos somos
matrices de infinitas entradas e infinitas salidas, y por tanto
tenemos interpretaciones diversas de percepción y rendimiento
que varían según cada individuo.
Por eso es importante que tanto el programador
como el
equipo que trabaja con él, reconozcan cuáles son las fortalezas
y
limitaciones en este campo. Así mismo, en la dinámica del trabajo ir configurando un
lenguaje estructurado entre los equipos.
Volvamos a la falla inicialmente planteada:
¿Cuáles son las causas observables de un error tan grave?
i) Se tiene un Equipo de Proceso
responsable del diseño funcional y que realiza los
requerimientos mediante una
Plataforma de Gestión de
Calidad, la cual registra las evidencias, tales como
entregables, peticiones, solicitud de respuesta, respuestas
con fechas, preguntas, etc..
ii) Se cuenta con normas internas de
nomenclatura y control en el Ambiente de Desarrollo y
Ambiente de Prueba
iii) Se tiene un
PMO con estructura y
procedimientos, para controlar cada entregable antes de que se
ponga a disposición del cliente.
iv) Los miembros del Equipo de Proceso
son quienes deben revisar la funcionalidad entregada por el
programador en Ambiente de Prueba, y aprueban o rechazan el
paso a producción del entregable.
¿Por qué entonces, si se tienen todos esos
mecanismos de control aún siguen habiendo perforaciones de
error?
¿Hay siempre una probabilidad de fallar pese a todas las
estructuras de control?
Efectivamente es probable, que en una de las
plataformas, construidas sobre varias centenas de miles de
código, existan casos de uso que conllevan al error o fallas en
los algoritmos, los cuales han sido probados exitosamente en una serie de casos particulares, pero
que bajo otras circunstancias (Casos
de Uso) no operan.
Sin embargo, en este
caso el error fue, simplemente porque no se respetó un
procedimiento de revisión en forma integral, por ninguna de las dos partes
(Equipo Proceso y
Equipo de Desarrollo), debido a la confianza que brinda un
sistema que opera perfectamente en producción hace varios años.
Es decir, porque las rutinas, funciones,
nomenclatura, estandarización de componentes están muy
consolidadas y se trabaja copiando y pegando las clases en forma
rápida, sin mayor revisión. Este exceso de confianza ha
producido que en varias ocasiones que los actores involucrados
se salten pasos de ciertos procedimientos, a tal punto que ha
bastado con una llamada directa de un gerente al programador,
para el programador realice un cambio en forma directa sobre los
códigos de una rutina y los pasé a producción sin revisión
alguna.
La mayoría de las veces este descuidado
proceder no ha causado problemas, pero cuando ocurre, ¡¡es muy
grave!! El mayor tiempo y energía en la conformación del Método
Simple-DocIRS, ha estado orientado a la búsqueda de algoritmos
que operen con rapidez y exactitud, minimizando el error. La
presencia del error, puede venir en la entrada, darse también en
el proceso y por ende su suma se manifiesta en la salida. Muchos
profesionales aceptan las pequeñas dificultades (o fallas) de
los programas como una consecuencia natural de la condición
humana, y consideran su corrección como una situación inevitable
de la vida.
Es necesario señalar que las múltiples
aplicaciones operan con el Método Simple-DocIRS, lo que
significa un conjunto de funciones, rutinas y componentes con la
misma notación e iguales, las cuales se está traspasando por FTP,
eliminando, sustituyendo, adicionando a la biblioteca común.
Esto implica, que existe una más alta probabilidad de
equivocarse y por tanto requiere de concentración cuando se está
realizando las transacciones de archivos a las diferentes
plataformas. Ese hecho, que mi profesor Dr.
PHD Roberto Frucht Wertheimer me los hubiese reprochado como
un desacierto en la notación, hoy es una ventaja en los tiempos
de respuesta de nuestro método.
Cada vez que se efectúa un cambio o traspaso
de una componente a otra plataforma, se debe realizar un
seguimiento exhaustivo de toda la red de rutinas que aparezcan
involucradas. A pesar de que esto puede hacerse, es evidente que
es responsabilidad del Equipo de Procesos y del Equipo de
Desarrollo es asegurar que la aplicación está libre de errores.
Buena parte de la investigación en ciencia
relacionada a la Tecnología de la Información, ha estado
dirigida hacia la búsqueda de pruebas formales, matemáticas, de
la validez de los programas. Se ha establecido que estas pruebas
son posibles.
Sin embargo, los procedimientos son largos y
dificultosos, y pocas veces prácticos en las aplicaciones
reales. Cuando éste sea el caso, el programador debe recurrir a
otros métodos, como las pruebas para establecer la validez de
sus módulos y rutinas.
Algunas conclusiones concretas de esta
experiencia nos señalan fallas en los ingenieros de proceso,
quienes están a cargo del diseño funcional y de revisar los
requerimientos solicitados en Ambiente de Prueba. A pesar de
desarrollar en capas, con objetos y funciones atómicas siempre
habrá que revisar integralmente, dado que un “copy-paste” genera la probabilidad de tener impacto en otras
rutinas.
Un corolario que tendría un impacto directo
en los tiempos de entrega y costos, es crear entre Procesos y
Desarrollo, una capa intermedia autónoma de profesionales,
dedicada al control de calidad, que no deje pasar nada a
producción, si no se ha cumplido con todas las pruebas en los
Ambientes previos.
DocIRS en su evolución y búsqueda por evitar
errores, saltó de la programación extrema, a organizar dos
diferentes equipos de trabajos, Gerencia Procesos y Gerencia de
Desarrollo. Mediante esta organización “Arquitectura <–>
Construcción”, regular y controlar avalar las entregas y
orientar el desempeño de los miembros de ambos equipos.
Incorporar entre estas dos áreas una instancia de Control
de Calidad, tendría un impacto directo en los tiempos de entrega
y los costos, y estadísticamente no se justifica, dado que hasta
hoy la cantidad de fallas y nivel de gravedad es casi cero.
En otras palabras, el equipo de desarrollo
debe revisar los requerimientos de diseño y mejoramiento
funcional en forma más rigurosa y exhaustiva. Auditándose entre
ellos, siempre en Ambiente de Desarrollo. Por otra parte, el
equipo de Procesos y sus ingenieros debe revisar el entregable
en Ambiente de Pruebas forma integral, mapeando cuáles son las
posibles funcionalidades que podrían ser afectadas y aprobar o
rechazar la tarea.
En caso de ser aprobado el cambio,
mejoramiento o nueva funcionalidad, entonces se pasa a
producción. A este efecto, se han implantado el método simple el
cual cuenta con mecanismos automáticos de control que sirven
sostener el diseñar y mantener constantemente el flujo de
funcionamiento del sistema operando en Ambiente de Producción.
Estos mecanismos automáticos de control,
especialmente asociados a los accesos, tareas nocturnas
programadas y el sistema de continuidad operativa son
mecanismos que detectan un conjunto de desvíos, regulando,
anticipando y alertando acerca de posibles errores.
Otra fuente indirecta de errores, pero no
menos potente, es el actuar de los ingenieros-gerentes
quienes interaccionan con los clientes y quienes,
frente a sus demandas, realizan compromisos y tareas por fuera
de la plataforma. La mayoría de las veces, ofreciendo
soluciones fuera de los bordes convenidos o recurriendo a
la generación de informes en Excel, para
posteriormente introducirlos de apuro en la plataforma,
sometiendo a los programadores a requerimientos no planificados.
Esta práctica de carácter comercial , - que se
repite y que aumenta los factores no controlables, ha
sido muy difícil desterrarla, porque es también de tremenda
utilidad para la empresa. Sin embargo, representa más
variabilidad en el quehacer del soporte y logística de los
sistemas.
Está más que claro, que esta forma de hacer gestión con el
cliente puede incidir en los tiempos de respuesta, incrementos
en la presión y cantidad de trabajo no planeada, derivando en
posibles fallas. Si es que no se aumentan las horas hombre de
revisión y testing.
Finalmente, está claro que este suceso
desfavorable con el que comienza el articulo, fue resultado de la realización poco pulcra en el control de procesos.
Es un alerta a estar vigilantes, a corregir las malas
prácticas y respetar todos los pasos establecidos en las normas
de Gestión de Calidad del proceso informático y así evitar
la burocratización del modelo
Simple-DocIRS y
de su Estrategia del Diseño Simple.
Artículos Relacionados
|
