Mi blog Qualilogy tiene ya casi un año (al final del mes) y me parece que casi todos los artículos que he escrito tratan de la calidad del de las aplicaciones y se dirigen principalmente a dos tipos de lectores:

• Aquellos que están familiarizados con los conceptos de calidad, a menudo más allá del mundo de la calidad del código. Son consultores o responsables de calidad, por lo general con una amplia experiencia de diversas tecnologías y lenguajes, capaces de interpretar un cuadro de mandos y hacer auditorías. Sin embargo, no siempre utilizan herramientas de análisis de código, y a veces creo que encuentran el mundo J2EE y Open Source demasiado técnicos para ellos.

Traté de demostrar que no es tan complicado, incluso sin conocimientos técnicos, a través de varios artículos que describen la instalación y el uso de herramientas Jenkins y Sonar, y los beneficios de los muchos plugins creados y mantenidos por la comunidad Sonar.

• Los que en cambio son usuarios o expertos en el uso de estas herramientas, que ponen en práctica en sus proyectos o en el portafolio de aplicaciones J2EE de su empresa, pero no tienen experiencia con otras tecnologías, cuando podrían analizar otras aplicaciones de esas otras tecnologías, con sólo un poco de conocimiento.

Ver por ejemplo, la serie Cobol empezando en este post Análisis de código Cobol – Lo que debes saber.

Como tenía planes de hacer una serie del mismo tipo para la tecnología de SAP, le pedí su participación a alguien que no es sólo un amigo, sino también un experto en el campo de la calidad, de la tecnología SAP y de las herramientas de análisis de código.

Con 20 años de experiencia en el tema de calidad de software, Walter Strobl es Director de Calidad del grupo multinacional Vision IT Group, cuya representación en España la ostenta Drago Solutions.

Sus conocimientos y experiencia cubren múltiples métodos, técnicas y herramientas de gestión de calidad aplicados en proyectos de múltiples tecnologías y diferentes sectores de actividad: nuclear, aeroespacial, defensa, industria, financiero, etc.

En la actualidad, desde Drago el equipo liderado por Walter está realizando proyectos y prestando servicios de análisis o inspección de código a nivel internacional, apoyándose en recursos de la factoría del software del grupo.

Contamos, pues, en especial con las experiencias de Walter en análisis de código SAP ABAP para nuestra próxima serie, que reflejamos a continuación a partir de la entrevista que le hemos realizado recientemente.

Walter, cuéntanos brevemente cómo has vivido la evolución histórica de la calidad del software.

Ante todo, agradecerte tu tiempo y este espacio de tu blog.

Si nos remontamos al año 1983, en el que empiezo a trabajar en calidad del software, lo primero que hice fue revisar los métodos y técnicas de la calidad del hardware y su transferibilidad o no, al software, empezando por identificar las diferencias entre software y hardware. Por ejemplo, el software se “fabrica” una sola vez y después se puede copiar con facilidad; el hardware se fabrica “en cadena”. Si el software original contiene errores, sus copias también; mientras que una pieza hardware puede ser defectuosa, y la de al lado, no.

Así, las técnicas de revisión de diseño de la ingeniería convencional son transvasables con ciertas adaptaciones a la revisión documental en el entorno software. Las inspecciones en fabricación hardware equivalen a inspección de código software. Los ciclos de mejora permanente de la calidad PDCA (Plan-Do-Check-Act) se pueden aplicar en ambos campos. Tanto el hardware como el software requieren testing. La fabricación hardware está muy industrializada, mientras que el desarrollo de software tiene aún mucho de artesanal; el camino para salir de la producción artesanal del software pasa ineludiblemente por tener y aplicar mejores prácticas de arquitectura, diseño y programación adaptadas a las diferentes tecnologías en uso (ABAP, Java, .Net, etc.).

Los procedimientos de fabricación se transformaron en procedimientos de producción de software, sobre todo para software crítico en los campos aeroespacial, nuclear y defensa. La introducción de las herramientas CASE (Computer Aided Software Engineering) a mediados de la década de los 80 ha apoyado el uso de los diccionarios de datos, las técnicas estructuradas de análisis y diseño, en los que estaban muy de moda las metodologías de desarrollo de software.

Cuando no había herramientas disponibles, trabajabais manualmente?

Evidentemente. Recuerdo de esa época una anécdota, que respalda absolutamente la utilidad de tareas de aseguramiento de la calidad manuales: a través de una revisión manual de un documento de usuario de un Sistema de Apoyo a la Operación de una planta nuclear española, la ausencia de cierta documentación de diseño del fabricante, que hubo que subsanar antes de la aceptación del Sistema por el cliente.

La necesidad de revisar la documentación del software sigue siendo fundamental para identificar errores en fases tempranas del ciclo de vida. Y es una actividad de calidad de bajo coste y alta efectividad muy recomendable.
Durante el diseño y la construcción del Tren de Alta Velocidad Madrid-Sevilla (AVE) realizamos actividades de revisión de código del software de comunicaciones tren-tierra, escrito en C, de forma manual, con cierto apoyo de búsquedas de texto en ficheros.

Qué actividades de calidad del desarrollo de software se automatizaron primero?

Según se han ido introduciendo herramientas que apoyan las actividades de calidad, primero en la gestión de configuración y el control de cambios, después en la gestión de requisitos, pasando por herramientas de pruebas, ha sido posible automatizar en gran medida el aseguramiento de la calidad de los desarrollos de software. El círculo se cierra en los últimos años con la aparición creciente de herramientas de auditoría de código.

¿Qué beneficios aportan, en grandes líneas, las diferentes actividades de aseguramiento de la calidad y cuál es el nivel de esfuerzo requerido para alcanzar este beneficio?

Las actividades planificadas y ad hoc de garantía o aseguramiento de la calidad del software aportan respectivamente los siguientes beneficios:

– Las revisiones de documentos garantizan en gran medida la coherencia de los documentos entre sí y en especial con los requisitos; el esfuerzo es muy bajo para el gran beneficio que se obtiene.
– Las auditorías de los procesos de desarrollo aseguran el cumplimiento de los procedimientos y normas e identifican puntos de mejora de dichos procedimientos; el esfuerzo es bajo, para alcanzar un beneficio a largo plazo.
– La inspección de código (que también llamamos en ocasiones auditoría o revisión de código) busca el cumplimiento de las mejores prácticas de arquitectura, diseño y programación con un esfuerzo muy bajo, obteniendo un beneficio inmediato por la identificación rápida y temprana de problemas graves de rendimiento, seguridad, fiabilidad y mantenibilidad, reduciendo el esfuerzo en testing y eliminando posibles problemas en producción.
– El testing o las pruebas son la actividad de calidad de la que nadie prescinde, pero a la que se suele dedicar menos de lo debido, en una fase muy avanzada de los proyectos y que se suele formalizar demasiado poco. Es la actividad de calidad más costosa en esfuerzo; su beneficio es asegurar el cumplimiento, sobre todo, de las especificaciones funcionales, y en ocasiones, aspectos de seguridad, capacidad, etc.

Qué sectores de actividad y tecnologías consideras pueden sacar más provecho de los beneficios de la auditoría de código?

En primer lugar, están claramente los sistemas críticos (aeroespacial, medicina, sistemas de mando y control, sistemas de operación, de producción, etc.) que muchas veces están obligados por norma o ley a su uso, al haber, en caso de fallo, vidas humanas en juego; después estarían los sistemas software cuyos fallos conllevan grandes pérdidas económicas (con lo que llegamos incluso a sistemas comerciales de facturación).

Nosotros hemos analizado código, entre otros, de sistemas de control ferroviario, de gestión comercial en el sector de la energía, sistemas de banca, telecomunicaciones, etc., y la conclusión es unánime: la auditoría de código es la única forma de implantar adecuadamente las mejores prácticas y prevenir errores en producción. Y hemos hecho a y si no tuviera estas mejores prácticas,

Hay entornos de desarrollo que apoyan el desarrollo de software, entre las que se encuentra SAP, en las que el análisis de código aporta una mejora notable. Pero, seleccionando las herramientas adecuadas y teniendo los conocimientos y la experiencia necesarios, es posible auditar código de casi cualquier tecnología (Java, .net, PL/SQL, C, C++, VB, etc.). Hay herramientas abiertas al desarrollo de reglas de programación.

El problema no está en la funcionalidad del software o en la tecnología en la que se basa, para realizar un buen servicio de auditoría de código se necesita combinar el conocimiento y la experiencia en la tecnología de un equipo humano, las herramientas de análisis, el modelo de indicadores de calidad y un proceso de ejecución continua (integrada en el ciclo de desarrollo) o discreta (con análisis periódicos, semanales, mensuales, por entregas) y todo ello se puede hacer de forma remota. Una última recomendación: que el número de reglas de las buenas prácticas que se califiquen como de “obligado cumplimiento” sea un número reducido; un número excesivo produce desánimo en primera instancia e imposibilidad de mejora a la larga.

Gracias Walter para tomar el tiempo de responder a mis preguntas.

En el próximo artículo, veremos lo que se necesita saber respecto a código ABAP, para luego (en un post ulterior), listar las preguntas que hacer a un equipo de proyecto SAP, para analizar su código. Seguro que tu experiencia nos será muy útil.

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