Seguimos con el post anterior sobre las preguntas que hacer para preparar la instalación de un proceso de análisis de código ABAP, donde hemos visto que eso depende bastante de los casos de uso.

Le pregunté a Walter, Director de Calidad en Drago Solutions, quien nos acompaña desde el principio de esta serie.

¿Cuáles son los casos de uso que encuentras lo más a menudo?

Los casos de uso en los que pienso son: Quality Gate, mejora continua, auditoria de un portafolio de aplicación, benchmark de proveedor, KPIs para el management (indicadores sobre la evolución de la calidad a lo largo del año), assessments específicos (por ejemplo para una migración, un problema de rendimiento), etc.

Los más frecuentes según nuestra experiencia son: primero, la evaluación puntual de una aplicación, desarrollo o proyecto; segundo, la integración continua del análisis en el ciclo de vida del software; tercero, un análisis antes y después de un proyecto de mantenimiento evolutivo; cuarto, el análisis especifico orientado a un problema de rendimiento, seguridad, etc.

Pero no olvidemos subproductos de los mismos tan importantes como ellos, a saber: la generación de Mejores Prácticas, el apoyo al seguimiento de ANS o Acuerdos de Nivel de Servicio (SLA o Service Level Agreement), la generación de nueva documentación técnica para cubrir su obsolescencia o ausencia, el apoyo a requisitos de evaluación CMMI o ISO, o finalmente el cumplimiento de estándares y reglas específicas en entornos de alto riesgo (defensa, aviación civil, entornos nucleares, farmacéutico, sanidad y salud, etc.).

Y recientemente, hemos abierto un campo que combina la evaluación y la reducción los riesgos de los proceso de negocio producidos por fallos de los sistemas de información que los apoyan, a través del análisis del código de estos sistemas de información.

¿Hay casos de uso que te parecen presentar más valor y más beneficios y que recomendarías a un cliente?

Ante todo, la integración continua del análisis de código en el ciclo de vida de desarrollo manifiesta un valor muy alto para las organizaciones en las que lo hemos implantado.

Además me gustaría recomendar la orientación del análisis de código a los riesgos de los procesos de negocio, especialmente para todos aquellos procesos críticos de una organización.

¿Este valor añadido puede ser diferente según el tamaño del portafolio SAP, o el número de proveedores, o cualquier otro elemento?

Si continuamos con la visión de procesos de negocio y sus riesgos, cuánto más amplio sea el portafolio SAP, más riesgos podrán identificarse y mitigarse mediante el análisis de código ABAP.
En cuanto al número de proveedores, si son varios, podrá añadirse el benchmarking interno y el seguimiento de los ANS o mejores prácticas por parte de los proveedores.

Y no olvidemos la información que el análisis de código puede aportar la identificación y priorización de proyectos del Plan Estratégico de Sistemas de Información.

¿Qué es lo que llamas benchmarking “interno” o “externo”?

Hablo de benchmarking “interno” si el cliente necesita evaluar de forma comparativa las capacidades o la calidad del código producido por diferentes equipos, normalmente diferentes proveedores.

En cambio llamo benchmarking “externo” al contraste de capacidades o resultados de análisis de código de diferentes empresas del mismo sector industrial y de la misma tecnología (por ejemplo, implantaciones del módulo SAP ABAP IS-U en el sector energético y personalizaciones a un sistema CRM en el sector de las telecomunicaciones).

Pues bien, a veces nuestros clientes nos han pedido que, además, les proporcionemos bien un benchmarking interno de proveedores o un benchmarking externo de su sector industrial.

¿Qué pasa con los errores antiguos, provenientes de otro proveedor u otro equipo de desarrollo?

Como has señalado, los proveedores o el equipo de desarrollo actuales no son responsables de deficiencias históricas ocultas hasta ahora. Si afloran mediante el análisis de código, no debemos ignorarlas; en base a su cualificación, que proporcionamos con nuestro análisis, en cuanto a su gravedad, impacto, forma de solución, frecuencia, esfuerzo en su resolución, etc. podemos seleccionar los puntos críticos y actuar sobre ellos. Siempre el esfuerzo de resolución, después de su detección, será más bajo que su impacto en Producción, en el caso de activarse como si de una bomba de relojería se tratase.

¿Tanto si se tienen estándares como si no se tienen, qué aporta la auditoría de código a los mismos?

Si existen, aporta en primer lugar el conocimiento del nivel de aplicación o seguimiento de los mismos por el equipo de desarrollo y mantenimiento propio o externo. En segundo lugar aporta la posibilidad de refinar estas mejores prácticas, en forma de unas reglas medibles a nivel de código.

El objetivo puede ser: “El rendimiento de las bases de datos deberá ser óptimo” en la próxima versión de las mejores prácticas, difundirla, aplicarla y controlar su cumplimiento, por ejemplo por la siguiente formulación precisa y medible: no deben usarse SELECT anidados, no debe usarse la sentencia SELECT … ENDSELECT, etc.

Gracias Walter, por compartir tu experiencia en la implementación de casos de usos SAP. En el futuro, seguiremos a un nivel más técnico con análisis de código ABAP con Sonar. Hasta luego.

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