Seguimos con nuestra serie de análisis de código ABAP.

Hemos visto en el post anterior lo que se necesita saber respecto a la tecnología SAP y el código ABAP.

Ahora, vamos a listar las preguntas que necesitamos examinar con los equipos de proyectos para preparar la descarga del código.

Pues, si conoces Sonar porque estás acostumbrado ya en hacer análisis de código (por ejemplo J2EE) pero no sabes nada de código ABAP, esta parte te va a interesar.
Si al contrario, conoces bien la tecnología SAP pero nada de Sonar, los próximos posts donde hablaremos de análisis de código ABAP con Sonar, te interesarán más; aunque previamente, tendrás que organizar la entrega de este código o ver como organizarlo y este post puede ayudarte en eso.

Por suerte, tenemos con nosotros, desde los articulos anteriores, a Walter que es experto en estos dos temas, calidad de aplicaciones SAP y uso de la plataforma Sonar, entre otras. Y su experiencia y peritaje nos van a ser muy útil, pues le pedí que nos comentara esos puntos.

¿Quién es tu cliente?

La primera pregunta, aunque eso no necesitamos preguntarlo porque lo podemos saber ya, es ¿Para quién vamos a trabajar? Básicamente, o trabajas en una compaña en el departamento de TI y tus ‘clientes’ son usuarios de la compaña, pertenecientes a diferentes departamentos de negocio por ejemplo, o trabajas para otra empresa proveedora y tus clientes son otras compañas a las cuales prestas servicios de análisis de código.

Vas a decirme ¿qué importa esto, si de todos modos vamos a analizar código ABAP? Tiene su importancia desde el principio, porque por ejemplo las extracciones, las puedes hacer con relativa facilidad si estás en el departamento de TI, si sabes qué extraer, de dónde extraer, cómo extraer y tienes los permisos necesarios. Sin embargo, si eres de otra empresa, tienes que gestionar con el departamento de TI, que te proporcionen estos accesos y permisos o que te entreguen el código, realizando ellos las extracciones o indicándote los objetos (clases, ficheros, etc.) que extraer.

Luego, si trabajas en un proveedor por diferentes clientes, probablemente vas a necesitar diferentes cuadros de mandos para cada uno de ellos, y posiblemente con diferentes ‘Quality profiles’, es decir diferentes conjuntos de reglas porque cada uno tendrá sus propias buenas prácticas, diferentes de otros clientes, o no con el mismo peso, etc.

Otro punto: un proveedor puede ser encargado de manejar un centro de Calidad para un cliente, y analizar todas las entregas de código de otros proveedores en una Quality Gate – es el caso del equipo de nuestro amigo Walter, Director de Calidad de Vision IT Group – o puede ser un proveedor de código SAP que tiene que entregar diferentes versiones a lo largo del tiempo, y quisiera poner en marcha un proceso de Continuous Integration para mejorar la calidad de estas entregas.

Hay diferentes casos de uso y escenarios posibles y no precipites a lo técnico primero: lo más importante es de definir los objetivos de tus usuarios o de tus clientes, y muy probablemente tendrás que presentarles los diferentes casos de uso posibles para que ellos escogen los que responden mejor a sus necesidades. Optimizar los beneficios para el business, siempre.

Las otras preguntas que hacer son más técnicas.

SAP versión

La primera es sencilla: ¿cuál es la versión SAP? No hay diferencias a nivel de lenguaje – pero en el núcleo SAP y en el Workbench sí. Y el programa que tendremos que implantar para hacer la extracción del código no será el mismo.

SAP areas

Hemos visto en el post anterior que hay diferentes áreas o módulos SAP: FI, CO, HR son los más frecuentes. Y es así que vamos a organizar los análisis con Sonar y también los resultados en el dashboard, porque es así que el cliente o cualquier equipo de proyecto SAP lo entiende y quiere verlo.

Servidores SAP

Podemos tener estas diferentes áreas o módulos SAP en diferentes servidores, cada uno con su Workbench, su núcleo SAP y su código personalizado. Tienes que pensar en organizar tus procesos de análisis desde el principio, es decir, desde la extracción de código. Y necesitarás hacer tantas extracciones como servidores haya.

Ahora, depende del caso de uso y / o del primer punto que hemos visto, y si tú te encargas de las extracciones o si alguien – equipo de proyecto, cliente, etc. – te entrega el código. Hay clientes que no quieren que se acceda a sus servidores desde el exterior, y te lo van a entregar. O te van a pedir que alguien de tu equipo trabaje desde dentro de sus oficinas para este asunto de seguridad. Pero de todos modos, del numero de servidores depende el numero de extracciones y cualquier sea quien se encarga de eso, es un punto que tomar en cuenta.

Organización de los equipos / outsourcers

Este depende también del primer punto y de los casos de uso que poner en marcha. Lo más usual es que diferentes proveedores o equipos de proyecto trabajan en un mismo servidor. Pero no siempre en la misma área SAP. Si tienes que poner en marcha un caso de Quality Gate por cada entrega de cada outsourcer , necesitas saber cuántos proveedores trabajan en cuales servidores y áreas.

Cuidado: hay una cuestión muy habitual y mejor hablar de este tema con el cliente o los equipos de proyecto lo más ante posible. Es que el código ABAP, como las aplicaciones Cobol, puede ser muy antiguo. Y tú haces un análisis de este código para un Quality Gate y encuentras un montón de defectos graves o críticos, y muy probablemente no sea el último desarrollador responsable de esos defectos sino todos los programadores anteriores.

Entonces, no puedes decir al equipo de proyecto o el outsourcer que rechazas esta entrega y que ellos tienen que arreglar estos defectos porque no son responsables.
La sola manera de poder saber quien ha añadido nuevos defectos seria de hacer un análisis de todo el código existente para disponer de una ‘baseline’ y luego, poder ver los defectos nuevos en los cambios respecto a esta ‘baseline’. Pero eso significaría empezar con analizar millones o hasta decenas de millones de líneas de código para tener esta foto del portafolio SAP de la compaña.

Sonar es una herramienta muy poderosa cuando se trata de analizar código, pero el esfuerzo puede ser muy alto. De todos modos, depende mucho de los casos de uso y de las relaciones que el cliente quiere mantener con los equipos de proyecto y los proveedores. Pero es un punto importante que ver en la primera reunión.

Organización del código

Unos clientes organizan el código personalizado en clases de desarrollo (hemos visto en el post anterior que se trata de módulos y no de clases ‘Objetos’ como en J2EE). Básicamente, una clase corresponde a un directorio dentro de lo cual encontrarás los diferentes programas que analizar. No es un problema para Sonar, cualquier sea el numero de programas y el numero de directorios dentro del directorio raíz (root) de análisis.

Pero necesitas hacer esta pregunta. Unos clientes organizan el código en clases y otros no. Pues pueden pedirte de extraer tal y tal clase o al contrario, tal y tal programa. Y tendrás un cuadro de mandos a 2 niveles: área (FI, CO, etc.) y clases, o un solo nivel: área y todos los ficheros dentro de cada área.

Nomenclatura SAP

No queremos analizar el código del núcleo SAP sino solamente el código personalizado, desarrollado para personalizar el núcleo SAP. Por eso, es usual reconocer este código con unas nomenclaturas.

Si ves una clase que empieza con Z o ZZ o Y o YY o XX por ejemplo, es código personalizado y se analiza. Debería ser lo mismo a nivel de programas pero aquí las reglas pueden cambiar, según el tipo de programa. Por ejemplo, puede empezar con un ‘L’ porque es un ‘load-module’ o ‘function pool’.

Un ejemplo bastante usual de nomenclatura: Z[Id]_[t]:*, con

• ‘Id’: identificador de la clase o del proyecto en que se realiza el desarrollo
• ‘t’: tipo de objeto, R para un programa de tipo Report, I para un include, M para un Modul Pool, etc.
• *: una cadena de caracteres que describe lo que hace el código.

Con esta norma, vas a encontrar ficheros como ‘ZUC_R_CHECK_FISCAL_CODE.abap’, por ejemplo.

Normas SAP

Ultima pregunta, no específica a SAP (hay que preguntarla siempre): si existen estandartes de programación. Se encuentra más a menudo que en otras tecnologías, así que es interesante de comprobar si hay algún documento que describe estas buenas prácticas y las cuales están presentes en Sonar o no. Eso también nos ayuda a poner en marcha los casos de uso que queremos implantar.

Walter: ¿Hay otras preguntas en tu lista cuando pones en marcha un proceso de análisis de código por un nuevo cliente?

¿De qué volumen de código a analizar estamos hablando?

Esta volumetría puede medirse en la famosa y discutida métrica de líneas de código (en inglés: LOC / Lines of Code) y digo “discutida” porque hay una gran discusión en el tema de productividad, si ésta se puede medir en kLOC (miles de líneas) o debe hacer por otro medio, como son los Puntos de Función (FP o Function Points).

Muchas veces, no sabemos de qué volumen tiene nuestro código; a veces sólo se sabe al cabo del análisis. En el caso de SAP ABAP, por ejemplo en su versión ECC 6.0, podemos saberlo de antemano ejecutando un programa nuestro que cuenta el número de líneas.

Esto nos da una idea del tiempo que puede llevar el análisis, y en base a nuestra experiencia en Vision IT Group, podemos saber el esfuerzo necesario para interpretar y presentar los resultados, o predecir un posible Retorno de la Inversión (ROI).

Sí, es cierto que me había olvidado de eso. ¿Algo más?

¿Integración con resultados de otras tecnologías o análisis aislado?

Otra pregunta a realizarse al inicio del análisis, es si se va a analizar una única tecnología (por ejemplo SAP ABAP) y si es necesario combinar los resultados de análisis de código SAP con análisis de código Java, COBOL o PL/SQL. La composición de nuestro equipo técnico puede varíar.

Gracias Walter. Hay otras cosas que ver en relación con los casos de uso, pero este post ya es bastante largo. Nos vemos la próxima semana para hablar de eso.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.