INTRODUCCIÓN
La mantenibilidad tiene un impacto significativo en la calidad general de una aplicación (Rodríguez, Pedreira, & Fernández, 2015). Puede ser uno de los atributos de calidad más difíciles de estimar, porque esto implica inherentemente hacer predicciones sobre actividades futuras, por lo que podemos afirmar que es difícil de medir ya sea de manera cualitativa o cuantitativa (Döhmen, Bruntink, Ceolin, & Visser, 2016). El Glosario del Estándar IEEE (IEEE, 1990) define la mantenibilidad como: la facilidad con la que un sistema o componente de software puede modificarse para corregir fallos, mejorar el rendimiento u otros atributos, o adaptarse a un entorno cambiado.
La correcta gestión de la mantenibilidad incrementa las facilidades de modificación, al obtener productos de software con documentación actualizada y suficientes comentarios en el código. Provee beneficios en la reducción de los costos y recursos destinados a la fase de mantenimiento, gracias a la disminución en la complejidad y la densidad de código repetido. Tratar la mantenibilidad desde las fases tempranas del ciclo de vida aumenta el valor de los proyectos, debido a su influencia sobre los recursos de desarrollo y sobre la etapa futura de mantenimiento. Permite obtener un software fácilmente mantenible y con un código de alta calidad. Además, propicia la adaptación del producto a los cambios propios de la evolución en el desarrollo de software (Erazo, Florez, & Pino, 2016).
El aumento de la mantenibilidad es un requisito económico importante para las empresas con grandes sistemas de información de larga duración (English, Buckley, & Collins, 2016). Con esta premisa se desarrolló un proceso para la gestión de la mantenibilidad desde etapas tempranas en el desarrollo de software. Logrando con su aplicación un impacto positivo en la disminución de los costos en los cambios que se producen a los requisitos, el diseño, la arquitectura y el código. Reconociendo, además, que aumenta las capacidades de reutilización, obteniendo códigos con baja complejidad y disminuyendo los duplicados. Todo ello, logrado gracias a la inclusión de estos dos factores de mantenibilidad desde las fases tempranas del desarrollo.
Aquellos factores que pueden medirse son reconocidos como atributos o métricas de mantenibilidad. Los estudios realizados por Morasca exponen que las métricas son un medio para entender, monitorizar, controlar, predecir y probar el desarrollo del software (Morasca, 1996). Una métrica es una característica de un producto, documentación de sistema o proceso de desarrollo que puede medirse de manera objetiva. También las métricas son usadas para evaluar los atributos internos de un producto de software (Mesias, 2018).
En el presente artículo se analizan las métricas complejidad y código duplicado, así como la herramienta SonarQube usada para evaluar estas métricas de mantenibilidad. Los resultados son un fragmento del diagnóstico utilizado en la confección de un proceso para la gestión de la mantenibilidad desde etapas tempranas en el desarrollo de software. Como parte de un estudio de casos, se decidió aplicar el proceso desarrollado en uno de los proyectos evaluados inicialmente. Luego se realiza una segunda iteración de pruebas para analizar el impacto del proceso propuesto. Teniendo en cuenta el mismo periodo de tiempo, se evalúa también el comportamiento de la mantenibilidad en un segundo caso de estudio.
MÉTODOS O METODOLOGÍA COMPUTACIONAL
Se identificaron 30 publicaciones cuyos temas especificaban la mantenibilidad, de ellas se consideraron relevantes para la presente investigación 18. De la revisión bibliográfica resaltaron cinco artículos de los autores Irrazábal, Erazo y Rodríguez, que presentaban diferentes propuestas para evaluar, certificar y gestionar la mantenibilidad. En estas publicaciones se examinaban las sub-características de mantenibilidad planteadas por la ISO/IEC 25010: 2011, los factores y buenas prácticas para el proceso de desarrollo de software, teniendo en cuenta el aumento de la mantenibilidad. Estos elementos sirvieron de base para la elaboración del proceso para la gestión de la mantenibilidad que se aplica en el estudio de casos. El uso de la herramienta SonarQube para el diagnóstico de las métricas complejidad y densidad de duplicados, antes y después de aplicado el proceso, permitió una valoración del impacto positivo del proceso elaborado.
RESULTADOS Y DISCUSIÓN
Es fundamental conocer la situación en la que se encuentra el producto de software lo más rápido posible para poder decidir mejor cómo gestionar y realizar cada petición de mantenimiento, y en general planificar mejor el proceso (Ruiz & Polo, 2019). La medición de software es el proceso mediante el cual se puede obtener un valor numérico a partir de un proceso o producto de software. Las del producto son mediciones que se realizan en cualquier estado de su desarrollo, desde los requerimientos hasta el sistema instalado y son ampliamente usadas por la industria del software (Pérez, 2015).
Para Rodríguez (Rodríguez et al., 2015), no solo es importante definir las sub-características de mantenibilidad, sino que el desglose de estas al más bajo nivel, donde se definen métricas que se pueden medir a través de los productos de software. A pesar de que la mantenibilidad del software es una tarea costosa y desafiante, a menudo está mal gestionada. Una de las razones de la mala gestión es la falta de medidas probadas (Aggrawal, 2002). A continuación, se analizan las métricas que hacen un aporte significativo a la investigación:
Complejidad: Se relaciona con la dificultad para implementar, probar, entender, modificar o mantener un programa. Está relacionada con la analizabilidad, modificabilidad y testabilidad. En aplicaciones con complejidad elevada, las tareas de mantenimiento requieren mayor esfuerzo y, por tanto, son más costosas (Rodríguez & Piattini, 2014).
Código duplicado: Hace referencia a fragmentos de código que se encuentran repetidos en diferentes lugares del sistema. El código duplicado hace más difícil la realización de modificaciones en una aplicación, ya que solucionar un defecto o introducir una mejora en el código, requiere realizar las modificaciones en todas las partes del sistema en las que aparezca. Afecta a las sub-características de mantenibilidad: analizabilidad y modificabilidad, ya que obstaculiza la identificación del código que se debe modificar y la realización de modificaciones que sean efectivas. También dificulta la testabilidad, pues se deben definir varios casos de prueba diferentes, para comprobar el correcto funcionamiento del código duplicado en sus distintas instancias.
Una métrica básica de calidad es el código repetido, que junto a la complejidad constituyen el mayor enemigo de la mantenibilidad (Valenciano, 2015; Rojas & Alvarez, 2020). A su vez un software con un nivel adecuado de mantenibilidad aporta entre otros beneficios la simplificación de la complejidad (AQCLab, 2019). Teniendo estas premisas en mente, y el hecho de que en la actualidad los desarrollos de software suelen tener un gran tamaño, por lo que el número de medidas a obtener es muy elevado, parece que el enfoque más conveniente sería disponer de herramientas que facilitaran la obtención automática de tales medidas.
SonarQube para medir la mantenibilidad
SonarQube se utiliza para medir la mantenibilidad del código fuente y gestionar su deuda técnica. Puede detectar fugas de memoria, casos avanzados de derivaciones de punteros nulos, condiciones que son siempre verdaderas o falsas, independientemente de la ruta de ejecución (Sonarqube, 2019). los resultados muestran que al incorporar sonarqube al desarrollo se mejora la mantenibilidad (Carvajal, Tasis, & Martínez, 2019). se utiliza para evaluar código fuente, brinda gran cantidad de funcionalidades para la detección de código duplicado, no adecuación a estándares y convenciones de código, vulnerabilidades conocidas de seguridad, complejidad ciclomática y acoplamiento (León, 2020).
SonarQube es una plataforma de código abierto, usada por los equipos de desarrollo para controlar la calidad del código. Fue desarrollada con el principal objetivo de hacer accesible la administración de la calidad del código con un mínimo esfuerzo. Como tal, SonarQube contiene en su núcleo de funcionalidades un analizador de código, una herramienta de reportes, un módulo que detecta defectos y una función para regresar los cambios realizados en el código. Presenta los valores en una interfaz agradable y fácil de comprender, por ejemplo: para representar el código duplicado establece colores según el rango de valores, aquellos programas que cuentan con un valor por debajo del 5% los representa en color verde, entre 5% y 20% en color naranja y los que están por encima del 20% los señala en color rojo.
Descripción del proceso para la gestión de la mantenibilidad
Se optó por la creación de un proceso con el objetivo de gestionar la mantenibilidad desde etapas tempranas en el desarrollo de software, luego del análisis de los resultados obtenidos con la aplicación de los métodos científicos. El proceso incluye los factores que influyen en las sub-características planteadas por la Norma Cubana ISO/IEC 25010: 2016. El proceso describe las actividades en las fases: Inicio, Ejecución y Cierre; y las disciplinas ingenieriles propuestas por la metodología AUP-UCI (Informáticas, 2015): Modelado de negocio, Requisitos, Análisis y diseño, Implementación, Pruebas internas, Pruebas de liberación y Pruebas de aceptación. Además, se detallan: roles, artefactos de entrada, actividades y artefactos de salida, basados en modelos y procesos acorde al ciclo de vida de un proyecto de desarrollo de software (Espinosa, 2021). El proceso propone actividades para asegurar la gestión de los requisitos no funcionales de mantenibilidad (RNFM). En las Figura 1 y Figura 2 se presentan las actividades correspondientes a la Fase de Inicio y a las disciplinas: Modelado de negocio y Requisitos, pertenecientes a la fase de Ejecución.
En la Figura 3 se presentan las actividades correspondientes a las disciplinas: Análisis y diseño e Implementación, pertenecientes a la fase de Ejecución.
En las Figuras 4 y Figura 5 se observan las actividades de las disciplinas: Pruebas internas, Pruebas de liberación y Pruebas de aceptación, así como la actividad de la fase de Cierre.
En la Tabla 1 se describen las actividades correspondientes a la fase de Inicio del proceso elaborado.
Además, se definen los roles, artefactos de entrada y salida a estas actividades.
Aplicación del método estudio de casos
Con una investigación de estudio de casos se pueden lograr diferentes objetivos: hacer una descripción, ofrecer explicaciones o interpretaciones sobre el fenómeno investigado, explorar sus características, funcionamiento o hacer una evaluación (Monge, 2010). Se decidió aplicar este método al proyecto P1 para obtener diferencias respecto al comportamiento de las métricas complejidad y código duplicado. Se realizó la primera iteración de prueba para el estudio de la problemática con la herramienta SonarQube, luego se aplicó el proceso para la gestión de la mantenibilidad y se efectuó la segunda iteración de pruebas. Los valores obtenidos en las pruebas realizadas al primer caso P1 se comparan con los resultados del análisis realizado al segundo caso nombrado en la investigación como P2.
Los resultados del primer diagnóstico (ver Figura 6) arrojaron que la densidad de duplicados (relación entre la cantidad de código duplicado de un producto y su tamaño) era de 3.0. Mientras que la complejidad era de 16,229.
En la versión Acompañamiento y Desarrollo de solicitudes de cambios de P1, se empleó el proceso para la gestión de la mantenibilidad. Para valorar el comportamiento de las métricas después de aplicado el proceso, se hicieron nuevamente pruebas con la herramienta SonarQube, obteniéndose una densidad de duplicados de 2.4 y una complejidad de 16,111 (ver Figura 7).
Los resultados obtenidos después de ejecutado el proceso fueron favorables, ya que tanto la complejidad como la densidad de código duplicado disminuyeron. Reconociendo, además, que estas métricas constituyen los peores enemigos de la mantenibilidad, se puede concluir que su disminución influye positivamente en el aumento de la mantenibilidad del producto de software obtenido.
Para evaluar el comportamiento de ambas métricas en otros espacios, se decidió valorar también con la herramienta SonarQube al proyecto P2. Este caso fue escogido debido a que en la primera iteración de pruebas, presentaba el menor valor en complejidad de los proyectos estudiados. En aquel momento contaba con una densidad de duplicados de 4.9 y una complejidad de 3, 005.
Luego en la segunda iteración de pruebas con la misma herramienta, para el mismo periodo de tiempo que el proyecto P1 y sin aplicar el proceso, P2 mostró valores desfavorables. La densidad de duplicados aumentó a 10.8 y la complejidad a 4, 128 (ver Figura 8). Si comparamos los valores recogidos en ambas iteraciones de pruebas, se puede concluir que en el proyecto P2 las métricas interpretadas ascendieron significativamente.
Después de explorar el comportamiento de las métricas en los proyectos P1 y P2, para el mismo periodo de análisis y utilizando la misma herramienta de prueba, se confirma el éxito del proceso elaborado. Como se reconoció durante la revisión bibliográfica, a medida que el programa de software evoluciona se vuelve más complejo y el código duplicado aumenta, si no se gestiona correctamente la mantenibilidad. Mediante el método estudio de casos esta premisa se ratificó (ver Figura 9 y Figura 10), pues las métricas código duplicado y complejidad disminuyeron en el proyecto donde se aplicó el proceso elaborado. Mientras, en el programa P2, donde no se utilizó el proceso para la gestión de la mantenibilidad, estas métricas aumentaron significativamente.
CONCLUSIONES
Mediante el método estudio de casos se pudo conocer el estado de la mantenibilidad y el impacto positivo del uso del proceso elaborado para la gestión de la misma. Gracias a la evaluación realizada usando la herramienta SonarQube se observó que:
A medida que avanza un proyecto la complejidad aumenta si no se gestiona correctamente.
Junto con la complejidad aumenta también la dificultad de probar, lo que se tendría presente a la hora de planificar pruebas futuras.
Si no se tiene en cuenta la mantenibilidad desde etapas tempranas del desarrollo, entonces el producto resultante es difícil de mantener.
La mantenibilidad es una tarea costosa, sobre todo si no aplicamos métodos para su gestión.
Las métricas complejidad y código duplicado permiten hacer un estudio del software a medida que evoluciona.