Prueba de Procedures en ILE RPG

Ile Procedures

Base de Datos vs. DFU

Cuando estamos realizando pruebas de programas, generalmente recurrimos al uso del DFU para proveernos de un conjunto de datos improvisados por nosotros mismos para realizar pruebas parciales y unitarias de programas. En general, existe la sensación de que en un ambiente de desarrollo, todo es válido. Puede corromperse la data para realizar pruebas, tener redundancia de información y alterar la data como la requerimos.

En ambientes de desarrollo donde no hay control de versiones, esto puede representar un problema cuando otros programadores necesitan realizar pruebas con los mismos archivos y se encuentran con una data corrompida. Aunque dupliquemos los archivos en nuestras librerías de trabajo personales para manejar la data a nuestro antojo, no debemos olvidar que la situación que estamos forzando “No se ajusta a la realidad”. Ese escenario que estamos produciendo de manera forzosa, probablemente nunca ocurrirá en el ambiente de producción. Entonces ¿Qué estamos probando?.

La elaboración de escenarios de pruebas debe estar basada en un principio de “correspondencia con la realidad” que se presenta en la operativa diaria del negocio.

Las datas de prueban deben ser generadas por las aplicaciones que fueron desarrolladas para tal fin. Las aplicaciones velan para que las validaciones se encarguen de la integridad y la consistencia de la data. Cuando realizamos pruebas en base a data generadas por las aplicaciones, garantizamos que el ambiente de desarrollo sea idéntico a lo que ocurre en el ambiente de producción, que en resumidas cuentas, es lo que sucede día a día en las actividades diarias del negocio.

Es recomendable que los profesionales asignados al mantenimiento y la custodia de los datos sean quienes suministren la data de prueba a los analistas y programadores. Corresponde al personal de Base de Datos colocar en el ambiente de desarrollo una data que simule la data de producción.

En algunas empresas, por razones de estrategia de negocios y protección de la identidad de los clientes, la data debe ser tratada previamente por estos profesionales de Base de Datos antes de ser entregada al ambiente de desarrollo donde todos los analistas y programadores puedan accederla.


Autor: Ing. Liliana Suárez


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo
click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.

Mas sobre Migración

Cuando se realizan un cambio de plataforma es necesario establecer acuerdos entre dos metodologías de de trabajo que deben coordinarse y sumar esfuerzos para lograr un resultado exitoso.

La migración de sistemas distintos sobre el mismo lenguaje RPG, en plataforma As/400 no es tan traumática como la migración entre un sistema desarrollado en RPG en el AS/400 y un sistema desarrollado en un lenguaje orientado a objetos.

El control del proyecto de migración debe generar una serie de pautas que establezcan puntos de control que sean fácilmente cuantificables por los analistas de ambas plataformas: la plataforma receptora de la data y la emisora donde residen actualmente los datos de origen.

La cultura tradicional del AS/400 ha carecido de cierta solidez en relación a la definición de la Base de Datos, en las pruebas de procesos y en la estandarización del código en el desarrollo del software. Por otra parte, en la programación orientada a objetos el enfoque es funcional y el desarrollo de código es mucho menor. Hay muchas más herramientas y normas de documentación que en la cultura clásica del AS/400.

Para subsanar las diferencias que se suscitan en la forma de controlar el avance del proyecto debe intervenir un tercero en la mesa de discusión. En realidad este tercero en la mesa debe intervenir siempre pero en el cambio de plataformas tecnológicas su participación se hace imprescindible para el éxito de la migración.

La participación de los profesionales del área de Procesos, Organización y Métodos es esencial para levantar la información relacionada con las reglas del negocio, el impacto de los cambios a realizarse y los puntos de control operativo por área de negocio que puedan y deban ser sometidos a certificación antes de la implantación del nuevo sistema.

Una vez recopilada la información sobre la funcionalidad del negocio, establecidos los puntos de control y las funciones operativas que deben certificarse, procede la fijación de un cronograma de actividades que los involucrados del área de sistemas deben cumplir. En este punto entonces los profesionales de ambas plataformas deben establecer compromisos de acuerdo a su “cultura” profesional pero siempre sobre los cimientos construidos por el área de Procesos y Organización y Métodos.

Una definición clara de la funcionalidad del negocio minimiza el impacto que pueda producirse por la salida inesperada de algún analista y facilita la curva de aprendizaje de un nuevo analista que está asumiendo la responsabilidad.

Una gran ventaja de la participación de los profesionales de Procesos, Organización y métodos es que los procesos del negocio quedan documentados. Esto facilita a mediano y largo plazo la adecuación del sistema instalado a los cambios que requiera la organización por cuestiones de estrategia y competitividad de mercado. Con una documentación de los procesos del negocio, puede estimarse con mayor rapidez la factibilidad del cambio, el impacto y el riesgo operativo que representaría para el negocio.


Autor: Ing. Liliana Suárez


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo
click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.