Análisis en profundidad

Calidad del software: metodologías y tecnologías para garantizarla

¿Cuáles son las tendencias que caracterizan la calidad del software para aplicaciones empresariales? El artículo presenta los resultados de los estudios realizados en los dos últimos años. Se centra en el análisis de cinco factores determinantes que afectan al resultado y proporciona algunas pautas válidas para elevar el nivel de calidad estructural, mediante el control de algunos aspectos estratégicos, tanto tecnológicos como organizativos.

07 Ene 2022

Giorgio Fusari

la calidad del software

¿Cómo mantener la calidad del software bajo control y mejorarla para satisfacer las necesidades de los usuarios? He aquí un resumen de las principales cosas que hay que saber.

Cómo estar seguro de la calidad del software

  • Prestar más atención al tipo de tecnología y a la aplicación utilizada;
  • adherirse a prácticas de codificación seguras adoptando un enfoque de seguridad por diseño;
  • centrarse en la madurez e integración de las metodologías de desarrollo;
  • vigilar constantemente las violaciones de las normas que puedan poner en peligro la calidad del código fuente;
  • convertir las prácticas de mejora de la calidad del código en procesos metódicos y sistemáticamente repetidos.

Estos son, en definitiva, los puntos estratégicos que hay que vigilar, según se desprende de una amplia encuesta destinada a conocer las tendencias globales actuales de la calidad estructural del software y las aplicaciones informáticas desarrolladas en todo el mundo. Cabe señalar que el término “calidad estructural” se utiliza en el estudio para referirse principalmente a la solidez de la ingeniería arquitectónica y la “salud” de la codificación de una aplicación, más que a la corrección con la que se implementan los requisitos funcionales solicitados por el usuario.

Los cinco factores de la calidad del software

Partamos de una detallada investigación llevada a cabo por Cast en 2017, y que en su esencia resumida aquí sigue siendo válida en la actualidad, (Informe Crash (Cast Research on Application Software Health) 2017): el informe trata de hacer un balance del nivel de salud del software empresarial y de cuál es su valor desde el punto de vista del negocio, midiendo su calidad estructural en base a unos benchmarks y puntos de referencia o, si se prefiere, de cinco “factores de salud” o características fundamentales de la calidad estructural, que se identifican con la robustez, la seguridad, la eficiencia del rendimiento, la transferibilidad, la modificabilidad.

En esencia, la calidad estructural se mide identificando las violaciones de las normas que representan las buenas prácticas arquitectónicas y de desarrollo de códigos en cada una de estas cinco áreas clave. Por lo tanto, definámoslos mejor.

  1. El factor de robustez mide la probabilidad de que se produzcan interrupciones, la dificultad de recuperación y la posibilidad de que los datos se corrompan, ligada a las malas prácticas de codificación.
  2. El factor de seguridad, por su parte, mide las violaciones de las metodologías de encriptación seguras que abren el camino al acceso no autorizado, a las interacciones engañosas, al robo de datos o a la violación de la confidencialidad.
  3. La eficiencia es el factor de salud que mide la probabilidad de una posible degradación del rendimiento, y el uso ineficiente de los recursos (procesadores, memoria, redes), de nuevo causado por metodologías de desarrollo de código deficientes.
  4. El factor de modificabilidad mide la dificultad de modificar las aplicaciones, añadir funcionalidad, corregir errores o cambiar el entorno de la aplicación.
  5. Por último, la transferibilidad es el factor que mide la dificultad de llevar a cabo el trabajo o la dificultad de entender la aplicación y ser productivo al trabajar con ella.

Las puntuaciones de estos cinco factores de salud se calculan en una escala de 1 (bajo/medio) a 4 (alto/bueno), a partir de la cual se analiza la aplicación para identificar las violaciones de más de 1.200 normas de buenas prácticas arquitectónicas y de codificación.

Mejora del software: principales recomendaciones

Antes de explicar la muestra, cómo se llevó a cabo la investigación y algunos aspectos concretos del estudio, conviene destacar de una vez las valiosas recomendaciones para los equipos de desarrollo que se desprenden de los resultados resumidos del informe Cast.

  1. Para obtener información precisa y útil sobre el rendimiento comparable, las actividades de evaluación comparativa de software deben realizarse dentro de la categoría tecnológica y el tipo de aplicación específicos. De hecho, los resultados de la evaluación comparativa realizada únicamente con respecto al tipo de industria pueden ser engañosos, debido a los efectos de otros factores más influyentes que pueden variar dentro de las organizaciones.
  2. Debería prestarse más atención a las prácticas de codificación segura, ya que muchas aplicaciones obtuvieron una puntuación inaceptablemente baja en este ámbito. De hecho, las puntuaciones de la categoría “seguridad” mostraron mayores variaciones que las de cualquier otro factor de salud.
  3. La tercera recomendación es que, para mejorar las puntuaciones en los factores de salud, las organizaciones deben mejorar la madurez de sus procesos y metodologías de desarrollo. Las organizaciones con poca madurez obtuvieron sistemáticamente una puntuación más baja en los factores de salud.
  4. Es aconsejable adoptar metodologías híbridas para el desarrollo de aplicaciones “críticas para el negocio”, ya que los métodos híbridos obtuvieron una mayor puntuación en los factores de salud que las metodologías “ágiles” y “en cascada”, integrando la planificación del análisis arquitectónico con una rápida retroalimentación sobre la calidad.
  5. Es preferible evitar la creación de equipos de más de 20 desarrolladores; los equipos de menos de diez miembros parecen ser óptimos.
  6. Al considerar estrategias como la externalización o la deslocalización, hay que prestar atención a los factores que han demostrado influir en la calidad estructural, como la madurez de la organización, la metodología de desarrollo o el tamaño del equipo, ya que estos factores influyen más que otros, como la fuente (interna, externalizada) o el lugar de desarrollo (deslocalizado, onshore).
  7. Es importante analizar periódicamente el código fuente antes de liberarlo, para identificar las violaciones de las normas de calidad que pongan en riesgo las operaciones o los costes. Las infracciones a nivel de sistema son las más críticas, ya que son mucho más costosas de resolver, y pueden requerir varios ciclos de liberación antes de ser eliminadas por completo.
  8. Es necesario concebir la mejora de la calidad estructural como un proceso iterativo, que debe proseguirse a través de numerosas versiones del software para alcanzar umbrales de calidad óptimos.

Dos niveles de normas de calidad

Un aspecto esencial de la evaluación de la calidad estructural del código es dividir las reglas de calidad en dos niveles de análisis: reglas a nivel de código y reglas a nivel de sistema. Las primeras, aclara Cast, son normas evaluadas a nivel de la unidad de código (por ejemplo, dentro de una clase, un método, una subrutina, un módulo) y las infracciones en este ámbito suelen implicar problemas de “higiene” de la codificación y simples defectos.

Las reglas a nivel de sistema, en cambio, son reglas arquitectónicas cuya evaluación implica a múltiples componentes, a menudo distribuidos en diferentes niveles de la aplicación. Las infracciones en este ámbito son difíciles o imposibles de detectar a través de las actividades normales de prueba, pero suelen ser las culpables de las interrupciones, los agujeros de seguridad, la corrupción de datos y las dificultades para soportar o ampliar la aplicación (escalado).

Los datos utilizados como muestra para el análisis del informe Crash proceden de Appmarq, el repositorio digital de Cast, que la empresa describe como la mayor base de datos sobre sistemas informáticos reales, que contiene datos recogidos durante los análisis estructurales a nivel de sistema de grandes aplicaciones informáticas. El repositorio incluye 1.850 solicitudes presentadas por 329 organizaciones para su posterior análisis. En conjunto, estas aplicaciones sumaron 1,03 Blocs (mil millones de líneas de código). Las organizaciones que participan en la investigación se encuentran principalmente en Europa continental (Francia, Bélgica, Italia, Alemania y España), el Reino Unido, América del Norte (Estados Unidos y Canadá) e India. Desde el punto de vista tecnológico, la muestra incluye aplicaciones escritas principalmente en Cobol, Java-EE, .NET, Oracle Server y otras tecnologías, como PHP, C/C++, PowerBuilder, C# y Visual Basic.

En cuanto al tamaño de las aplicaciones, el umbral mínimo para aceptarlas en la muestra era de 10 Kloc (kilo o mil líneas de código), que se elevaba a aplicaciones que contenían más de un Mloc (millón de líneas de código).

En cuanto al desarrollo de código, las tecnologías más utilizadas en la muestra de Crash son Java-EE (40%) y Cobol (22%).

Desde el punto de vista de los segmentos industriales, la muestra incluye solicitudes de 329 empresas de doce sectores: servicios financieros, seguros, telecomunicaciones, fabricación, consultoría informática, energía, servicios públicos, administración pública, comercio minorista, proveedores de software, productos farmacéuticos y medios de comunicación.

Por último, a nivel de tipos de aplicaciones, los tipos de sistemas más frecuentes en la muestra son los sistemas de transacciones básicas y los sistemas de planificación de recursos empresariales (ERP).

Factores clave que influyen en la calidad del software

Se comprobó que el tamaño de una aplicación tiene poco o ningún efecto en su calidad estructural. Por otro lado, la calidad estructural difiere significativamente cuando se comparan las tecnologías de desarrollo, siendo Cobol y Oracle Server las que generalmente obtienen las puntuaciones más bajas y JEE (Java-EE) las más altas. Sin embargo, el efecto de la tecnología sobre la calidad estructural es más fuerte que el del sector industrial al que pertenece la aplicación. Además, la tecnología utilizada en el desarrollo del sistema de aplicación puede ser más importante que el tipo de sistema en sí (sistema transaccional principal, ERP, sitio web, portal, CRM, aplicación analítica) a la hora de determinar su puntuación en el factor de salud.

La madurez organizacional es crucial

Ser capaz de pasar de una organización “indisciplinada” a una empresa innovadora y madura en sus procesos de desarrollo marca la diferencia a la hora de conseguir una calidad estructural en el software. Un grado de madurez cuya evolución Cast mide mediante el modelo CMMI (Capability Maturity Model Integration), que se divide en tres niveles.

En el nivel 1 (riesgo sin controlar) se encuentran las organizaciones en las que una mala planificación y disciplina crean plazos insostenibles para los proyectos, lo que lleva a los desarrolladores a producir un exceso de defectos en el software, con poco tiempo para identificarlos.

En el nivel 2 (riesgo limitado) se encuentran las organizaciones en las que los proyectos se llevan a cabo utilizando sus propias metodologías, pero en las que los compromisos del proyecto y las líneas de base se gestionan para garantizar que los desarrolladores tengan tiempo para realizar un trabajo de calidad.

En el nivel 3 (riesgo controlado) se encuentran las organizaciones en las que los proyectos utilizan normas y procesos organizativos creados mediante metodologías en las que los desarrolladores confían para ofrecer sistemas de alta calidad.

Por tanto, no es de extrañar que las aplicaciones desarrolladas en organizaciones de nivel 1 de CMMI, en las que se cometen muchos errores sin tiempo suficiente para corregirlos, obtuvieran una puntuación más baja que las creadas en organizaciones de nivel 2, en las que las actividades de desarrollo son más disciplinadas y la calidad estructural del software mejora, o de nivel 3, en las que se aplican las mejores prácticas, implementando las capacidades de nivel 2 e integrándolas en los procesos organizativos estándar.

Figura 4 – Método de desarrollo híbrido: el mejor camino hacia la calidad – fuente: Informe de Choque de Cast 2017

Metodología de desarrollo “híbrida”: la opción ganadora

Hablando de prácticas de codificación, las puntuaciones más altas en cuanto a la calidad estructural del software las obtuvieron las metodologías de desarrollo híbridas: de hecho, las diferencias en los factores de salud entre los métodos de desarrollo “ágil” y “en cascada” fueron mínimas, y ambos obtuvieron puntuaciones más bajas que los métodos híbridos, que resultan de la combinación de la planificación y el diseño de la arquitectura de la aplicación, con una rápida retroalimentación sobre los defectos, retroalimentación que se reitera a lo largo del ciclo de diseño. Esto permite a los desarrolladores abordar antes los problemas de calidad del sistema y la arquitectura, e identificar con mayor precisión los defectos, incluso mientras desarrollan el código.

La inteligencia del software: una prioridad para los CIO

Otro informe de referencia es el Software Intelligence Report – CIO Priorities in the Digital Age, publicado este año por Cast, en el que se encuestó a 500 líderes de TI (incluidos 150 directores de informática, 125 arquitectos de software y 125 desarrolladores de aplicaciones, en organizaciones medianas y grandes) sobre sus objetivos tecnológicos y su capacidad para alcanzarlos en función de la Inteligencia de Software a la que pueden recurrir, en comparación con sus carteras de software existentes.

Entre las principales conclusiones del estudio se encuentra no sólo que los CIOs carecen de la visibilidad adecuada sobre el diseño del software para tomar decisiones acertadas sobre los activos informáticos de la empresa, sino también que los departamentos de sistemas de información son incapaces de prevenir los riesgos operativos, corrigiendo los fallos estructurales demasiado tarde para que no se produzca una ralentización del proceso de digitalización.

Un aspecto interesante de la encuesta es que no hay escasez de capacidades tecnológicas; cuando la empresa requiere soluciones que implican incluso habilidades tecnológicas avanzadas, los equipos de TI son capaces de desarrollarlas. Lo que falta, sin embargo, es un análisis claro y coherente que sea capaz de explorar por completo los sistemas de software que son fundamentales para las operaciones empresariales.

En particular, se identifican dos retos principales: por un lado, la prevalencia de los sistemas heredados que aún soportan operaciones empresariales clave dentro de la organización; por otro, la existencia de datos incoherentes sobre las actividades de diseño y mantenimiento de software.

Calidad del software

Los CIOs carecen de mucha información a la hora de tomar decisiones estratégicas sobre la arquitectura del software – Fuente: oftware Intelligence Report, Cast

Calidad del software e ISO 9126, esto es lo que dice

La ISO (Organización Internacional de Normalización), en colaboración con la IEC (Comisión Electrotécnica Internacional), responsables de describir un modelo de calidad del software, colaboraron en la redacción de las normas y directrices ISO/IEC 9126.

Surgió un modelo que sugiere un enfoque de la calidad que los vendedores pueden adoptar para mejorar sus procesos y, en consecuencia, la calidad del software que producen.

Los aspectos técnicos cubiertos por la norma se refieren, además del modelo de calidad del software clasificado por 6 características (funcionalidad, fiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad), a las métricas de calidad externa (que miden el comportamiento del código sobre la base de pruebas, observación de la ejecución, etc.); las métricas de calidad interna (que se aplican al software no ejecutable, por ejemplo, el código fuente, durante las fases de diseño y codificación); las métricas de calidad de uso, es decir, el punto de vista del usuario del software.

@RESERVADOS TODOS LOS DERECHOS
F
Giorgio Fusari
Temas principales

Especificaciones

S
seguridad
S
software