Entendiendo los secretos de su código IBM i

Entendiendo los secretos de su código IBM i

Entendiendo los secretos de su código IBM i

Saber lo que tienes

"Si fuera responsable de un millón de algo, me gustaría saber exactamente lo que tendría en cualquier momento".

Sigue siendo una ironía el hecho de que los departamentos de TI, dirigidos por las mismas personas responsables de construir un excelente software empresarial para administrar con precisión los activos y el inventario, ignoran regularmente el valor de usar ese mismo concepto de administración del inventario para gestionar sus propios activos de software.

Sin embargo, con los proyectos de modernización que se vislumbran en el horizonte y el riesgo de fuga de cerebros debido a la jubilación y el desgaste, un número cada vez mayor de departamentos de desarrollo de IBM i están buscando datos basados en análisis forenses para comprender su código fuente y de esta manera, poder administrar mejor los recursos de desarrollo disponibles. 

Por lo general, las organizaciones recurren al análisis de código para dar respuesta a las siguientes preguntas:

  • ¿Cuánto código tenemos que mantener y/o modernizar?
  • ¿Cómo puedo entender y controlar mejor la calidad de mi código fuente?

Mala visibilidad a 3.000 metros

Desafortunadamente, todavía hay muchos departamentos de TI con una dependencia continua del IBM i que no conocen con precisión qué parte de su código fuente es relevante, qué compleja es alguna parte de este, qué reglas de Negocio implementa, cuál es el modelo relacional, o cualquier otra métrica consistente con un proceso de gestión estructurado.

No es extraño que los directores de TI de organizaciones multimillonarias no tengan una visión real de la cantidad de código de la que son realmente responsables, o de la poca calidad y eficiencia de sus procesos de gestión de desarrollo.

En un encuentro reciente de un grupo de usuarios de IBM Power Systems, un experimentado director de TI confesó tener la responsabilidad de "miles" de programas, pero no tenía datos precisos sobre el tamaño del código fuente, o cuánto de este código era redundante. Tampoco tenía información del diseño explícito sobre el sistema más allá de lo que se documentó hace 20 años, en el momento en que se implementó el sistema por primera vez.

Sin embargo, es igualmente revelador (y satisfactorio) ver la expresión de asombro en los rostros de las personas al ver algo en lo que han trabajado durante 30 años cuantificado, medido y visualizado por primera vez. Sin excepción, esta "vista de pájaro" proporciona una nueva y efectiva forma de trabajar y administrar sus sistemas de TI y procesos de desarrollo.

Por lo general, uno de los entregables clave de un proyecto de visualización de código, consiste en una lista detallada de problemas de software. Esta lista puede incluir desajustes de software y objetos, fuentes perdidos, programas no utilizados, archivos, vías de acceso, código y una serie de construcciones heredadas como GOTO, archivos descritos internamente y archivos multiformato.

El asombro inicial de obtener un sistema visualizado rápidamente da paso a la sorpresa y a la inquietud a medida que se expone y conoce el alcance de estos problemas. Sin embargo, esta consternación se traduce rápidamente en un plan de acción proactivo para solucionar o eliminar problemas en las partes críticas de las aplicaciones existentes.

Comprender el alcance de las tareas generales o específicas de mantenimiento, los proyectos de modernización, la planificación y los costes precisos, pueden impulsar o frenar la carrera de un director de TI. Sin mencionar que normalmente se termina culpando a la misma plataforma por una mala planificación. "¡Oh, es esa plataforma heredada de nuevo! ¡Es por eso que nunca realizamos nuevas mejoras a tiempo!" Cualquiera que esté familiarizado con el desarrollo en RPG o SYNON en IBM i argumentará que es probablemente el kit más productivo para el desarrollo de aplicaciones empresariales.

¿Es la gestión del código fuente o RTC la clave?

Algunos departamentos de IBM i utilizan referencias cruzadas básicas y alguna forma de Gestión de Cambios de Fuentes (SCM de sus siglas en inglés) para ayudar a gestionar el desarrollo. Existe una idea errónea generalizada de que SCM puede ayudar a controlar el inventario de activos de software. Esto no es cierto. SCM permite o proporciona el control de activos específicos para un propósito claro en un momento dado. No proporciona datos de gestión significativos de  todo el sistema, ni antes ni después de un cambio o una serie de cambios.

En el extremo opuesto del espectro está Rational Team Concert (RTC) de IBM, que ofrece un amplio abanico de características y módulos que ayudan a gestionar proyectos de desarrollo grandes y complejos con muchos desarrolladores y partes implicadas. RTC es una excelente solución cuando un departamento de TI se dedica al desarrollo de código fuente, con múltiples equipos en múltiples ubicaciones.

Sin embargo, los esfuerzos de desarrollo y modernización en IBM i no se ajustan a ese modelo. En estos escenarios, la atención se centra en pequeños equipos responsables de mantener o modernizar fuentes de código existentes muy grandes. El uso de RTC en esta situación puede desalentar a los desarrolladores de IBM i. Además, el soporte para el análisis de código profundo de las aplicaciones RPG / SYNON IBM i dentro de RTC es muy limitado.

La mejor opción: análisis de código

Los directores de TI recurren cada vez más al análisis de código para mejorar la visibilidad. Herramientas como X-Analysis son fundamentales para cuantificar y administrar el tamaño y la calidad de su código fuente, evaluar el riesgo de mantener y modernizar el código fuente heredado y mejorar la calidad del desarrollo. Al abstraer el código fuente un nivel por encima de su sintaxis y usar varios diagramas interactivos y pseudocódigos en lugar de RPG, los desarrolladores y colaboradores que no son de IBM i están expuestos a los diseños probados y al valor de las aplicaciones heredadas de IBM i. La mayoría de las herramientas de análisis se integran con herramientas SCM para que las decisiones clave resultantes del análisis se implementen de manera estructurada y metódica.

En resumen

La disminución de los recursos RPG disponibles, el aumento de los costes de mantenimiento, el crecimiento constante del código fuente, y la creciente diversidad en tecnología y conocimientos, están creando un punto de inflexión para un enfoque más científico y medible en el desarrollo y la modernización del IBM i. Independientemente de que el plan de la organización sea modernizar, o simplemente mantener los sistemas IBM i que gestionan actualmente el negocio, una mejor comprensión del código fuente a través del análisis de código estructurado, dará como resultado una mejor comprensión del negocio y una hoja de ruta más clara para el futuro.