Sólo se trata de elegir

seretur

La tarea de elegir un software libre o de código abierto1 puede ser realmente compleja y engorrosa. Ya sea que uno quiera utilizar software para tomarlo como base para otro, para reutilizarlo como componente, o simplemente para utilizarlo tal como está en alguna tarea, es probable que nos encontremos con una variedad importante de potenciales candidatos.

Por ejemplo, si buscamos una aplicación libre para leer archivos en formato PDF, en GitHub encontramos 123 repositorios de proyectos cuya licencia es de la familia GPL. Y en OpenHub hay datos sobre 214 proyectos que incluyen “pdf”.

Si pretendemos realizar la selección con cierta seriedad o formalidad, quizás sea conveniente indagar en los numerosos métodos que se han propuesto para evaluar la calidad de un software libre o para seleccionar el que sea más adecuado para necesidades específicas.

Ilustración de Alinaderi158 (CC BY-SA 4.0)

Antes de adentrarnos un poco en el tema, conviene tener en claro que no existe ningún método universal ni generalmente aceptado. No hay una navaja suiza, ni un santo grial. Hay propuestas con más o menos difusión, con más o menos críticas, algunas de las cuales, en el mejor de los casos, pueda servirnos para una situación en concreto.

De todos modos, las características comunes entre ellos puede orientarnos para formar nuestra propia metodología de selección, que puede variar según lo que queramos hacer con el software: no es lo mismo buscar una biblioteca (“library”) que un programa funcional completo, ni es lo mismo buscar código que resuelva determinados problemas que explorar qué juegos para computadora o para celular podemos descargar y usar libremente.

Muchas de las propuestas se basan en modelos de calidad. ¿De qué estamos hablando?, según citan Miguel y otros [1] a partir del estándar ISO/IEC IS 9126-1, un Modelo de Calidad es “un conjunto de características y las relaciones entre ellas, que proveen las bases para especificar requerimientos de calidad y evaluación”. Esto suena bastante abstracto, pero en definitiva quiere decir que se trata de un listado de atributos, de cualidades o factores que se considera que deben tenerse en cuenta para juzgar la calidad de un producto, cada una de las cuales se desglosa en subfactores o sub características. Esos subfactores deben ser cuantificables, lo que significa que se determinan (valores, métricas) que las representan.

Esquema de modelos de calidad
Ilustración 1: Esquema de un modelo de calidad (basado en una ilustración de Callejas-Cuervo y otros)

La calidad además puede referirse a diferentes vistas del software y su desarrollo. Así, puede tratarse de la calidad de proceso, orientado a la forma en que fue desarrollado y sus distintas etapas; calidad de producto, sobre características intrínsecas de la aplicación analizada; y calidad en uso, que trata de los aspectos que hacen a la aceptación de parte del usuario, por lo que incluye la usabilidad, pero no se limita a ella.

Las métricas que se nombran en el esquema son cosas medibles que se relacionan con los atributos que se quiere evaluar. Por ejemplo, para hablar del tamaño de un software podemos contar la cantidad de líneas de código que tiene, o la cantidad de bytes que ocupa; si queremos saber si un software es muy utilizado, podemos fijarnos en cuántas veces fue descargado, cuántas menciones hay a él en Internet o en sitios Web relacionados, etc. La “calidad” no se puede medir directamente (tampoco es seguro que distintas personas hablen de lo mismo cuando se refieren a ella), ni tampoco la facilidad con que puede modificarse un software, pero existen medidas que pueden darnos una idea de ello.

Un poco de historia

En 2003 Duijnhouwer y Wedding propusieron el Open Source Maturity Model[2], el primer modelo de evaluación del software libre y de código abierto. Se basó en el Modelo de Madurez de Capacidades (Capability Maturity Model) [3] elaborado por el Instituto de Ingeniería de Software (SEI, por sus siglas en inglés), donde se especifican diferentes grados de madurez de los procesos de desarrollo de software en una organización.

Desde entonces se han desarrollado numerosos modelos de evaluación de software libre orientados por criterios diversos, sin que ninguno de ellos haya alcanzado una difusión ni aceptación muy amplias. Tampoco existen registros numerosos del uso de ninguno de los métodos, si bien existen algunas comparaciones interesantes entre ellos.

Por ejemplo, en 2009 Petrinja y otros [4] compararon 3 métodos, los denominados Open BRR (Business Readiness Rating, algo así como Grado de Preparación para el uso Comercial), QSOS (Qualification and Selection of Open Source Software, Clasificación y Selección de Software de Código Abierto) y Qualipso OMM (Open Madurity Model, Modelo Abierto de Madurez). El trabajo consistió en una experiencia en la cual 26 personas con similares formaciones evaluaron dos aplicaciones libres (Firefox y Chrome) usando cada una de aquéllas alguno de los métodos considerados.

Los resultados muestran que en algunos casos la aplicación del mismo modelo a los dos productos dan resultados disímiles para algunas características valoradas. Por ejemplo, usando Open BRR, los evaluadores obtuvieron para Firefox resultados muy variados para los atributos Escalabilidad y Documentación; algo similar ocurrió con los atributos de Soporte y Adopción para Chrome.

En concreto: distintos evaluadores adjudicaron puntajes muy diferentes para algunas características de los programas analizados, pese a emplear la misma metodología. Eso puede indicar que la forma de evaluar esos atributos se presta a interpretaciones diferentes, por lo que no hay garantías de que los puntajes que se asignen sean similares para distintas personas y, por lo tanto, arrojen resultados de validez general.

Un ejemplo: QSOS

Para tener una idea más clara acerca de los modelos, miremos un poco más a uno de ellos. Tomamos aquí a QSOS (Qualification and Selection of Open Source Software, Clasificación y Selección de Software de Código Abierto), del cual se puede conocer diversos ejemplos de aplicación. Uno de esos ejemplos es el que comunicaron Proença y Bernardino en 2019 [5], donde comparan 3 aplicaciones libres usando QSOS.

Las herramientas analizadas por estos autores fueron Gantt Project, OrangeScrum, and ProjeQtOr. El dominio de aplicación de todas ellas es la administración de proyectos. Se trata de herramientas de administración de proyectos, desarrollados para asistir en la gestión de las distintas tareas que se llevan adelante en el transcurso de un proyecto, las dependencias entre ellas, las duraciones, etc.

El método QSOS consta de 4 etapas: Definición, Evaluación, Calificación y Selección. En la primera de ellas se establecen los criterios que se usarán en las etapas posteriores; en la segunda se obtiene la información sobre la comunidad de cada proyecto y se analiza la madurez del mismo, según los criterios fijados en el paso anterior, y se establece cómo se adjudicarán puntajes a distintos aspectos del proyecto y qué peso tendrá cada uno en la evaluación posterior; en el tercer paso se realiza el cómputo correspondiente a cada proyecto para determinar cuál será seleccionado. Esta secuencia puede volver a iniciarse con nuevos valores en un proceso iterativo. Un esquema de la secuencia puede verse en la Ilustración 2.

Ilustración 2: Esquema de SQOS (basado en la publicación de Proença y Bernardino)

En el caso informado por Proença y Bernardino, en la etapa inicial se recopiló la información sobre la licencia de cada programa, los nombres de los responsables de cada proyecto y la página Web del mismo. Allí también se determinaron las funcionalidades que se espera encontrar en cada uno.

En el segundo paso se establecieron los puntajes que se considerarían en las distintas funcionalidades. Así, se asigna un 0 si el programa no presta la funcionalidad en cuestión, 1 si la ofrece parcialmente y 2 si la cubre en su totalidad. Por ejemplo, se espera que el software permita realizar diagramas de Gantt; como Gantt Project y ProjeQtOr tienen incluida esa función, se les asigna 2 puntos, mientras que a OrangeScrum se le pone un 0 porque no contempla esa posibilidad. Más abajo reproducimos, traducidos al castellano, la tabla confeccionada por los autores.

 

Tabla 1. Puntajes asignados a los diferentes proyectos en relación con las funcionalidades buscadas

Criterio

Gantt Project

OrangeScrum

ProjeQtOr

Puntos

Puntos

Puntos

Tareas jerárquicas

2

0

0

Seguimiento de hitos

2

2

2

Manejo de camino crítico

2

0

0

Gráfico de Gantt

2

0

2

Seguimiento del tiempo

0

2

2

Seguimiento del costo

2

0

2

Gestión de riesgo

0

0

2

 

En esta instancia también se explicitan los criterios de madurez que se consideran relevantes para la selección. En el caso que comentamos aquí, se eligieron edad del proyecto; soporte; popularidad; documentación; y actualizaciones y nuevas versiones. En cada caso se otorgaron puntajes entre 0 y 2.

Una vez que se otorgaron los puntajes, hay que asignarles un peso, lo que significa dar más prioridad a unos factores que a otros. Las funcionalidades que se consideran esenciales tendrán 3 puntos, mientras que los que sean opcionales tendrán un 1. En el caso en cuestión se consideró que “Tareas jerárquicas” y “manejo de camino crítico” son funcionalidades secundarias, mientras que las otras son esenciales.

 

Criterio

Peso

Tareas jerárquicas

1

Seguimiento de hitos

3

Manejo de camino crítico

1

Gráfico de Gantt

3

Seguimiento del tiempo

3

Seguimiento del costo

3

Gestión de riesgo

3

 

De manera similar se establecen pesos para cada una de las características de madurez que se analizan. En este caso, se considera que los factores más importantes son la Documentación y el Soporte. Sobre este último aspecto, cabe señalar que todos los proyectos ofrecen soporte comunitario (se pueden hacer consultas en foros de la comunidad o enviar tickets con posibles fallas detectadas), aunque en algún caso (ProjeQtOr) también se puede acceder a un servicio pago de parte de los desarrolladores principales (esta diferenciación no consta en el trabajo de Proença y Bernardino).

Para la selección se realiza una suma ponderada de los puntajes de acuerdo con los pesos asignados. Es decir, se suman los productos PxW (puntaje por peso) para cada caso. Esa suma se divide luego por la suma de los pesos, obteniéndose un valor promedio. Este cálculo se realizó de manera separada para las funcionalidades y los indicadores de madurez.

En el caso reportado, el ganador es ProjecQtOr, que obtuvo un valor para las funcionalidades de 1,77 y de 2 para la madurez del proyecto.

Uno de los autores del trabajo mencionado, Bernardino, también publicó [6]– junto a André Vicente- una evaluación comparativa con SQOS de otros 3 proyectos: GitLab, OpenProject y Redmine.

Sistemáticamente revisados

A pesar de la falta de uniformidad y consenso en las metodologías de evaluación y selección de software libre y de código abierto, la tarea de comparar y elegir software de este tipo es una actividad casi cotidiana en numerosas organizaciones, por lo que es conveniente conocer diferentes aproximaciones a la evaluación de software para formarse una estrategia adecuada a cada contexto concreto.

Para tener un panorama de los distintos modelos propuestos, tomaremos dos revisiones sistemáticas: El trabajo de Adewumi y otros [7], y la revisión sistemática publicada por Lenarduzzi y otros [8].

Adewumi y sus compañerxs revisaron 19 iniciativas publicadas entre 2003 y 2015, donde los autores apuntan qué características del software considera clave en cada una de esas propuestas, qué vinculación tiene -si tiene alguna- con estándares de calidad de software, la metodología que emplean para la selección y la aplicabilidad a dominios específicos.

Los autores parten de considerar las características incluidas en los estándares de calidad más relevantes (ISO 2916, actualizada en ISO 25010), señalando que en el caso del software de código abierto es necesario considerar aspectos que no figuran en esas normas, como las que se vinculan con la comunidad de desarrollo. A continuación, clasifican cada propuesta en función de su derivación de un estándar, la adecuada descripción del método de evaluación, la existencia de alguna herramienta que soporte el uso del método en cuestión y la existencia de ejemplos demostrativos del uso del modelo.

También toman en cuenta las dimensiones de la calidad a nivel de proceso, de producto y en uso. A ellas los autores agregan una cuarta dimensión, referida a la comunidad de desarrollo. Los autores clasifican a los distintos modelos según si se concentran en una sola de esas dimensiones, si evalúan atributos de todas ellas, si se concentran sólo en las características de las comunidades, si excluyen los atributos que se refieren a la comunidad, o si ignoran los atributos de calidad en uso. Algunos modelos figuran en más de una de esas categorías.

Aunque no se pueden extraer conclusiones definitivas, es interesante observar -como destacan Adewumi y su equipo- cuáles son los atributos que se toman en cuenta con mayor frecuencia.

Como señalamos antes, es posible que los distintos modelos definan los atributos de manera diferente. Adewumi y su grupo los agrupa según las definiciones de la ISO 25010. Así, concluye que las dos características de calidad de producto que se miden con mayor frecuencia son la mantenibilidad (55% de los modelos) y la adecuación funcional (50%). Dicho de otra manera, más de la mitad de los modelos tratan de evaluar las condiciones del producto para ser modificado, corregidos sus errores, mejorado, y demás características que se engloban con la palabra “mantenibilidad”.

En lo que se refiere a la calidad “en uso”, la característica que los modelos intentan medir con mayor frecuencia es la usabilidad (50% de los modelos).

El desarrollo a través de una comunidad es un factor característico del software libre. Si el desarrollo cuenta con una gran número de colaboradores y usuarios, hay más posibilidades de que se detecten errores, se postulen correcciones, etc. Además, que haya muchos usuarios de un software sugiere que sirve para algo, que resuelve de manera efectiva algún problema (aunque, claro, no necesariamente el problema que nos interesa resolver a nosotros).

Los atributos de calidad de la comunidad que los modelos consideran con mayor frecuencia son la “capacidad de mantenimiento” y la “sostenibilidad”.

Mientras más programadores haya participando en el desarrollo de un software, sobre todo si colaboran con bastante frecuencia, es de esperar que los errores que se encuentren se solucionen más rápidamente y que la incorporación de nuevas funcionalidades también se logre en menos tiempo. A eso se refiere la “capacidad de mantenimiento”, que considera la cantidad de contribuyentes de un proyecto y el tiempo que dedican a la tarea.

La “sostenibilidad”, en tanto, trata de la capacidad del proyecto de desarrollo de atraer a nuevos contribuyentes y de reemplazar a quienes dejan de participar. Si a un proyecto se suman frecuentemente nuevos colaboradores, es esperable que dicho proyecto se mantenga en el tiempo.

En 2020, Lenarduzzi y otros [8] publicaron una revisión sistemática de los trabajos referidos a la evaluación, selección y adopción de software “de código abierto”. La autora y su grupo analizaron publicaciones en las que se presentaron modelos, lecciones aprendidas de diferentes experiencias y encuestas sobre usuarios y desarrolladores. A partir de ellos, observaron que los factores considerados con mayor frecuencia fueron “servicio y soporte”, “calidad del código”, “tipo de licencia” y “contribuyentes”.

Los estudios citados arriba dan una idea de qué factores han sido considerado frecuentemente como los más importantes a la hora de evaluar un software libre. Pero tampoco todos entienden lo mismo cuando se refieren a los factores que se toman en cuenta, y tampoco coinciden en la forma en que se pueden evaluar. No hay una forma única de decir cuándo un programa es más “usable” que otro, ni siempre se puede discernir cuál proyecto es más “maduro” o “estable”. Además, conseguir la información necesaria para evaluar algunos de esos aspectos puede llevar mucho tiempo. Supongamos, por ejemplo, que nos interesa seleccionar un software en cuyo desarrollo la solución de los errores que se informen sea lo más rápida posible. En muchos casos, el tiempo de demora en resolver problemas se puede estimar a partir de la información disponible en la Web del producto que se analice, pero no siempre es completo, y en ocasiones ni siquiera está a la vista.

Más allá de la heterogeneidad, otro aspecto común entre los diferentes modelos y metodologías es que se presentan como una serie de etapas. Li y Moreschini [9] destacan las siguientes actividades principales en ellos: 1) identificación del software; 2) obtención de los factores a considerar2 y las métricas con las que se evaluarán los mismos; 3) proveer puntajes o recomendaciones de selección como salida.

¿Qué hacemos, entonces?

Aunque no existe ningún modelo aceptado ampliamente, y menos aún herramientas que permitan realizar la tarea de manera automática, las distintas propuestas ponen de relieve distintos aspectos a tener en cuenta para seleccionar un software.

Sin pretensiones de crear un nuevo modelo ni nada por el estilo, podemos extraer algunas ideas para adoptar nuestro propio método.

Los siguientes puntos pueden servir de guía:

    1. Definir lo más claramente posible qué es lo que queremos de un software (nuestros requerimientos) teniendo en cuenta si pretendemos usarlo tal como está, hacerle algunas modificaciones (para adaptarlo a necesidades específicas, por ejemplo) o usarlo como una pieza para un nuevo software.
    2. Con la lista de funcionalidades escrita (al menos, con una primera lista de funcionalidades), establecer qué puntaje se le dará a cada software de acuerdo a cuánto cubren de cada función. Aquí también pueden definirse características de calidad y las métricas que -según consideremos- representarán dicha característica.
    3. Definir los pesos relativos de cada funcionalidad pedida.

Escribir un listado de condiciones que debe cumplir el software. Por ejemplo, que tenga muchas descargas, que tenga una licencia permisiva, que se hayan publicado versiones recientemente, etc.

Al igual que con los características funcionales, fijar puntajes para el cumplimiento total o parcial de las condiciones listadas en el punto anterior.

Definir los pesos relativos de las condiciones.

Calcular la suma ponderada.

En la primera etapa se podrían incluir criterios de “denegación”, es decir, requisitos que implicarán descartar el software si no los cumple. Ejemplo de ello podrían ser: la licencia, el tiempo de inactividad del proyecto (un programa que no saca nuevas versiones ni corrige errores hace muchos años es probable que tenga problemas de funcionamiento en la actualidad), o el lenguaje de programación.

Nos animamos a una sugerencia más: una vez hecha una evaluación, compartir la experiencia y los resultados para que sirvan de modelo/referencia/ejemplo/contrajemplo para otras personas o grupos que quieran hacer lo mismo.

Porque la fuerza del Software Libre es, precisamente, la oportunidad que brinda para avanzar en base al trabajo previo de otrxs y al mismo tiempo proveer a la comunidad de nuevos elementos para ir más allá.

Jorge Ramirez – 2022

http://dragonlibre.net

CC BY-SA 4.0

Bibliografía

1. Miguel, J.P., Mauricio, D., Rodríguez, G.: A Review of Software Quality Models for the Evaluation of Software Products. ArXiv Prepr. ArXiv14122977. (2014).

2. Duijnhouwer, C.F.-W.: Open source maturity model (OMMM). Technical report, Capgemini (2003).

3. Paulk, M.C., Curtis, B., Chrissis, M.B., Weber, C.V.: Capability Maturity Model for Software, Version 1.1: Defense Technical Information Center, Fort Belvoir, VA (1993). https://doi.org/10.21236/ADA263403.

4. Petrinja, E., Sillitti, A., Succi, G.: Comparing OpenBRR, QSOS, and OMM assessment models. In: Open Source Software: New Horizons. pp. 224–238. Springer (2010).

5. Proença, C.R., Bernardino, J.: Evaluating Gant Project, Orange Scrum, and ProjeQtOr Open Source Project Management Tools using QSOS. In: ICSOFT. pp. 522–528 (2019).

6. Vicente, A., Bernardino, J.: Evaluating GitLab, OpenProject, and Redmine using QSOS Methodology. In: Proceedings of the 15th International Conference on Web Information Systems and Technologies. pp. 380–387 (2019).

7. Adewumi, A., Misra, S., Omoregbe, N., Crawford, B., Soto, R.: A systematic literature review of open source software quality assessment models. SpringerPlus. 5, 1–13 (2016).

8. Lenarduzzi, V., Taibi, D., Tosi, D., Lavazza, L., Morasca, S.: Open source software evaluation, selection, and adoption: a systematic literature review. In: 2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). pp. 437–444. IEEE (2020).

9. Li, X., Moreschini, S.: Oss pesto: An open source software project evaluation and selection tool. In: IFIP International Conference on Open Source Systems. pp. 42–50. Springer (2021).

1En este texto hablaremos de “software libre y de código abierto”. Si bien ambos conceptos son distintos, se refieren a conjuntos de productos muy similares, caracterizadas por licencias de distribución que contemplan el acceso al código fuente y brindan libertades a usuarios y desarrolladores que no están contempladas en los productos “privativos” o de código cerrado.

2Los autores utilizan la palabra “elicit”, muy usada en la ingeniería de requerimientos para referirse a la tarea de obtener o “extraer” los requerimientos reales de un sistema de software a partir de fuentes muy distintas y usando métodos diversos.

Deja un comentario

Tu dirección de correo electrónico no será publicada.

Subscribe US Now