{"id":344,"date":"2022-05-12T20:12:01","date_gmt":"2022-05-12T23:12:01","guid":{"rendered":"http:\/\/dragonlibre.net\/?p=344"},"modified":"2022-05-12T20:12:01","modified_gmt":"2022-05-12T23:12:01","slug":"solo-se-trata-de-elegir","status":"publish","type":"post","link":"https:\/\/dragonlibre.net\/index.php\/2022\/05\/12\/solo-se-trata-de-elegir\/","title":{"rendered":"S\u00f3lo se trata de elegir"},"content":{"rendered":"

La tarea de elegir un software libre o de c\u00f3digo abierto1<\/sup><\/a> 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\u00e1 en alguna tarea, es probable que nos encontremos con una variedad importante de potenciales candidatos.<\/p>\n

Por ejemplo, si buscamos una aplicaci\u00f3n 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 \u201cpdf\u201d.<\/p>\n

Si pretendemos realizar la selecci\u00f3n con cierta seriedad o formalidad, quiz\u00e1s sea conveniente indagar en los numerosos m\u00e9todos que se han propuesto para evaluar la calidad de un software libre o para seleccionar el que sea m\u00e1s adecuado para necesidades espec\u00edficas.<\/p>\n

\"\"<\/a>
Ilustraci\u00f3n de Alinaderi158 (CC BY-SA 4.0)<\/figcaption><\/figure>\n

Antes de adentrarnos un poco en el tema, conviene tener en claro que no existe ning\u00fan m\u00e9todo universal ni generalmente aceptado. No hay una navaja suiza, ni un santo grial. Hay propuestas con m\u00e1s o menos difusi\u00f3n, con m\u00e1s o menos cr\u00edticas, algunas de las cuales, en el mejor de los casos, pueda servirnos para una situaci\u00f3n en concreto.<\/p>\n

De todos modos, las caracter\u00edsticas comunes entre ellos puede orientarnos para formar nuestra propia metodolog\u00eda de selecci\u00f3n, que puede variar seg\u00fan lo que queramos hacer con el software: no es lo mismo buscar una biblioteca (\u201clibrary\u201d) que un programa funcional completo, ni es lo mismo buscar c\u00f3digo que resuelva determinados problemas que explorar qu\u00e9 juegos para computadora o para celular podemos descargar y usar libremente.<\/p>\n

Muchas de las propuestas se basan en modelos de calidad. \u00bfDe qu\u00e9 estamos hablando?, seg\u00fan citan Miguel y otros [1] a partir del est\u00e1ndar ISO\/IEC IS 9126-1, un Modelo de Calidad es \u201cun conjunto de caracter\u00edsticas y las relaciones entre ellas, que proveen las bases para especificar requerimientos de calidad y evaluaci\u00f3n\u201d. 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\u00edsticas. Esos subfactores deben ser cuantificables, lo que significa que se determinan (valores, m\u00e9tricas) que las representan.<\/p>\n

\"Esquema<\/a>
Ilustraci\u00f3n 1: Esquema de un modelo de calidad (basado en una ilustraci\u00f3n de Callejas-Cuervo y otros)<\/figcaption><\/figure>\n

<\/i>La calidad adem\u00e1s puede referirse a diferentes vistas del software y su desarrollo. As\u00ed, puede tratarse de la calidad de proceso, orientado a la forma en que fue desarrollado y sus distintas etapas; calidad de producto, sobre caracter\u00edsticas intr\u00ednsecas de la aplicaci\u00f3n analizada; y calidad en uso, que trata de los aspectos que hacen a la aceptaci\u00f3n de parte del usuario, por lo que incluye la usabilidad<\/i>, pero no se limita a ella.<\/p>\n

Las m\u00e9tricas 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\u00f1o de un software podemos contar la cantidad de l\u00edneas de c\u00f3digo que tiene, o la cantidad de bytes que ocupa; si queremos saber si un software es muy utilizado, podemos fijarnos en cu\u00e1ntas veces fue descargado, cu\u00e1ntas menciones hay a \u00e9l en Internet o en sitios Web relacionados, etc. La \u201ccalidad\u201d 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.<\/p>\n

Un poco de historia<\/h3>\n

En 2003 Duijnhouwer y Wedding propusieron el Open Source Maturity Model[2], el primer modelo de evaluaci\u00f3n del software libre y de c\u00f3digo abierto. Se bas\u00f3 en el Modelo de Madurez de Capacidades (Capability Maturity Model) [3] elaborado por el Instituto de Ingenier\u00eda de Software (SEI, por sus siglas en ingl\u00e9s), donde se especifican diferentes grados de madurez de los procesos de desarrollo de software en una organizaci\u00f3n.<\/p>\n

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

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

Los resultados muestran que en algunos casos la aplicaci\u00f3n del mismo modelo a los dos productos dan resultados dis\u00edmiles para algunas caracter\u00edsticas valoradas. Por ejemplo, usando Open BRR, los evaluadores obtuvieron para Firefox resultados muy variados para los atributos Escalabilidad y Documentaci\u00f3n; algo similar ocurri\u00f3 con los atributos de Soporte y Adopci\u00f3n para Chrome.<\/p>\n

En concreto: distintos evaluadores adjudicaron puntajes muy diferentes<\/b> para algunas caracter\u00edsticas de los programas analizados, pese a emplear la misma metodolog\u00eda. Eso puede indicar que la forma de evaluar esos atributos se presta a interpretaciones diferentes, por lo que no hay garant\u00edas de que los puntajes que se asignen sean similares para distintas personas y, por lo tanto, arrojen resultados de validez general.<\/p>\n

Un ejemplo: QSOS<\/h3>\n

Para tener una idea m\u00e1s clara acerca de los modelos, miremos un poco m\u00e1s a uno de ellos. Tomamos aqu\u00ed a QSOS (Qualification and Selection of Open Source Software, Clasificaci\u00f3n y Selecci\u00f3n de Software de C\u00f3digo Abierto), del cual se puede conocer diversos ejemplos de aplicaci\u00f3n. Uno de esos ejemplos es el que comunicaron Proen\u00e7a y Bernardino en 2019 [5], donde comparan 3 aplicaciones libres usando QSOS.<\/p>\n

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

El m\u00e9todo QSOS consta de 4 etapas: Definici\u00f3n, Evaluaci\u00f3n, Calificaci\u00f3n y Selecci\u00f3n. En la primera de ellas se establecen los criterios que se usar\u00e1n en las etapas posteriores; en la segunda se obtiene la informaci\u00f3n sobre la comunidad de cada proyecto y se analiza la madurez del mismo, seg\u00fan los criterios fijados en el paso anterior, y se establece c\u00f3mo se adjudicar\u00e1n puntajes a distintos aspectos del proyecto y qu\u00e9 peso tendr\u00e1 cada uno en la evaluaci\u00f3n posterior; en el tercer paso se realiza el c\u00f3mputo correspondiente a cada proyecto para determinar cu\u00e1l ser\u00e1 seleccionado. Esta secuencia puede volver a iniciarse con nuevos valores en un proceso iterativo. Un esquema de la secuencia puede verse en la Ilustraci\u00f3n 2.<\/p>\n

\"\"<\/a>
Ilustraci\u00f3n 2: Esquema de SQOS (basado en la publicaci\u00f3n de Proen\u00e7a y Bernardino)<\/figcaption><\/figure>\n

<\/span>En el caso informado por Proen\u00e7a y Bernardino, en la etapa inicial se recopil\u00f3 la informaci\u00f3n sobre la licencia de cada programa, los nombres de los responsables de cada proyecto y la p\u00e1gina Web del mismo. All\u00ed tambi\u00e9n se determinaron las funcionalidades que se espera encontrar en cada uno.<\/p>\n

En el segundo paso se establecieron los puntajes que se considerar\u00edan en las distintas funcionalidades. As\u00ed, se asigna un 0 si el programa no presta la funcionalidad en cuesti\u00f3n, 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\u00f3n, se les asigna 2 puntos, mientras que a OrangeScrum se le pone un 0 porque no contempla esa posibilidad. M\u00e1s abajo reproducimos, traducidos al castellano, la tabla confeccionada por los autores.<\/p>\n

 <\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
\n

Tabla 1. Puntajes asignados a los diferentes proyectos en relaci\u00f3n con las funcionalidades buscadas<\/p>\n<\/th>\n<\/tr>\n

\n

Criterio<\/p>\n<\/th>\n

\n

Gantt Project<\/p>\n<\/th>\n

\n

OrangeScrum<\/p>\n<\/th>\n

ProjeQtOr<\/b><\/td>\n<\/tr>\n<\/thead>\n
\n

Puntos<\/p>\n<\/th>\n

\n

Puntos<\/p>\n<\/th>\n

\n

Puntos<\/p>\n<\/th>\n<\/tr>\n

\n

Tareas jer\u00e1rquicas<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento de hitos<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n<\/tr>\n

\n

Manejo de camino cr\u00edtico<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n<\/tr>\n

\n

Gr\u00e1fico de Gantt<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento del tiempo<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento del costo<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n<\/tr>\n

\n

Gesti\u00f3n de riesgo<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

0<\/p>\n<\/td>\n

\n

2<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

En esta instancia tambi\u00e9n se explicitan los criterios de madurez que se consideran relevantes para la selecci\u00f3n. En el caso que comentamos aqu\u00ed, se eligieron edad del proyecto; soporte; popularidad; documentaci\u00f3n; y actualizaciones y nuevas versiones. En cada caso se otorgaron puntajes entre 0 y 2.<\/p>\n

Una vez que se otorgaron los puntajes, hay que asignarles un peso, lo que significa dar m\u00e1s prioridad a unos factores que a otros. Las funcionalidades que se consideran esenciales tendr\u00e1n 3 puntos, mientras que los que sean opcionales tendr\u00e1n un 1. En el caso en cuesti\u00f3n se consider\u00f3 que \u201cTareas jer\u00e1rquicas\u201d y \u201cmanejo de camino cr\u00edtico\u201d son funcionalidades secundarias, mientras que las otras son esenciales.<\/p>\n

 <\/p>\n\n\n\n\n\n\n\n\n\n\n\n
\n

Criterio<\/p>\n<\/th>\n

\n

Peso<\/p>\n<\/th>\n<\/tr>\n<\/thead>\n

\n

Tareas jer\u00e1rquicas<\/p>\n<\/td>\n

\n

1<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento de hitos<\/p>\n<\/td>\n

\n

3<\/p>\n<\/td>\n<\/tr>\n

\n

Manejo de camino cr\u00edtico<\/p>\n<\/td>\n

\n

1<\/p>\n<\/td>\n<\/tr>\n

\n

Gr\u00e1fico de Gantt<\/p>\n<\/td>\n

\n

3<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento del tiempo<\/p>\n<\/td>\n

\n

3<\/p>\n<\/td>\n<\/tr>\n

\n

Seguimiento del costo<\/p>\n<\/td>\n

\n

3<\/p>\n<\/td>\n<\/tr>\n

\n

Gesti\u00f3n de riesgo<\/p>\n<\/td>\n

\n

3<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

De manera similar se establecen pesos para cada una de las caracter\u00edsticas de madurez que se analizan. En este caso, se considera que los factores m\u00e1s importantes son la Documentaci\u00f3n y el Soporte. Sobre este \u00faltimo aspecto, cabe se\u00f1alar 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\u00fan caso (ProjeQtOr) tambi\u00e9n se puede acceder a un servicio pago de parte de los desarrolladores principales (esta diferenciaci\u00f3n no consta en el trabajo de Proen\u00e7a y Bernardino).<\/p>\n

Para la selecci\u00f3n 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\u00e9ndose un valor promedio. Este c\u00e1lculo se realiz\u00f3 de manera separada para las funcionalidades y los indicadores de madurez.<\/p>\n

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.<\/p>\n

Uno de los autores del trabajo mencionado, Bernardino, tambi\u00e9n public\u00f3 [6]\u2013 junto a Andr\u00e9 Vicente- una evaluaci\u00f3n comparativa con SQOS de otros 3 proyectos: GitLab, OpenProject y Redmine.<\/p>\n

Sistem\u00e1ticamente revisados<\/h3>\n

A pesar de la falta de uniformidad y consenso en las metodolog\u00edas de evaluaci\u00f3n y selecci\u00f3n de software libre y de c\u00f3digo 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\u00f3n de software para formarse una estrategia adecuada a cada contexto concreto.<\/p>\n

Para tener un panorama de los distintos modelos propuestos, tomaremos dos revisiones sistem\u00e1ticas: El trabajo de Adewumi y otros [7], y la revisi\u00f3n sistem\u00e1tica publicada por Lenarduzzi y otros [8].<\/p>\n

Adewumi y sus compa\u00f1erxs revisaron 19 iniciativas publicadas entre 2003 y 2015, donde los autores apuntan qu\u00e9 caracter\u00edsticas del software considera clave en cada una de esas propuestas, qu\u00e9 vinculaci\u00f3n tiene -si tiene alguna- con est\u00e1ndares de calidad de software, la metodolog\u00eda que emplean para la selecci\u00f3n y la aplicabilidad a dominios espec\u00edficos.<\/p>\n

Los autores parten de considerar las caracter\u00edsticas incluidas en los est\u00e1ndares de calidad m\u00e1s relevantes (ISO 2916, actualizada en ISO 25010), se\u00f1alando que en el caso del software de c\u00f3digo abierto es necesario considerar aspectos que no figuran en esas normas, como las que se vinculan con la comunidad de desarrollo. A continuaci\u00f3n, clasifican cada propuesta en funci\u00f3n de su derivaci\u00f3n de un est\u00e1ndar, la adecuada descripci\u00f3n del m\u00e9todo de evaluaci\u00f3n, la existencia de alguna herramienta que soporte el uso del m\u00e9todo en cuesti\u00f3n y la existencia de ejemplos demostrativos del uso del modelo.<\/p>\n

Tambi\u00e9n 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\u00f3n, referida a la comunidad de desarrollo. Los autores clasifican a los distintos modelos seg\u00fan si se concentran en una sola de esas dimensiones, si eval\u00faan atributos de todas ellas, si se concentran s\u00f3lo en las caracter\u00edsticas 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\u00e1s de una de esas categor\u00edas.<\/p>\n

Aunque no se pueden extraer conclusiones definitivas, es interesante observar -como destacan Adewumi y su equipo- cu\u00e1les son los atributos que se toman en cuenta con mayor frecuencia.<\/p>\n

Como se\u00f1alamos antes, es posible que los distintos modelos definan los atributos de manera diferente. Adewumi y su grupo los agrupa seg\u00fan las definiciones de la ISO 25010. As\u00ed, concluye que las dos caracter\u00edsticas de calidad de producto que se miden con mayor frecuencia son la mantenibilidad (55% de los modelos) y la adecuaci\u00f3n funcional (50%). Dicho de otra manera, m\u00e1s de la mitad de los modelos tratan de evaluar las condiciones del producto para ser modificado, corregidos sus errores, mejorado, y dem\u00e1s caracter\u00edsticas que se engloban con la palabra \u201cmantenibilidad\u201d.<\/p>\n

En lo que se refiere a la calidad \u201cen uso\u201d, la caracter\u00edstica que los modelos intentan medir con mayor frecuencia es la usabilidad (50% de los modelos).<\/p>\n

El desarrollo a trav\u00e9s de una comunidad es un factor caracter\u00edstico del software libre. Si el desarrollo cuenta con una gran n\u00famero de colaboradores y usuarios, hay m\u00e1s posibilidades de que se detecten errores, se postulen correcciones, etc. Adem\u00e1s, que haya muchos usuarios de un software sugiere que sirve para algo, que resuelve de manera efectiva alg\u00fan problema (aunque, claro, no necesariamente el problema que nos interesa resolver a nosotros).<\/p>\n

Los atributos de calidad de la comunidad que los modelos consideran con mayor frecuencia son la \u201ccapacidad de mantenimiento\u201d y la \u201csostenibilidad\u201d.<\/p>\n

Mientras m\u00e1s 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\u00e1s r\u00e1pidamente y que la incorporaci\u00f3n de nuevas funcionalidades tambi\u00e9n se logre en menos tiempo. A eso se refiere la \u201ccapacidad de mantenimiento\u201d, que considera la cantidad de contribuyentes de un proyecto y el tiempo que dedican a la tarea.<\/p>\n

La \u201csostenibilidad\u201d, 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.<\/p>\n

En 2020, Lenarduzzi y otros [8] publicaron una revisi\u00f3n sistem\u00e1tica de los trabajos referidos a la evaluaci\u00f3n, selecci\u00f3n y adopci\u00f3n de software \u201cde c\u00f3digo abierto\u201d. 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 \u201cservicio y soporte\u201d, \u201ccalidad del c\u00f3digo\u201d, \u201ctipo de licencia\u201d y \u201ccontribuyentes\u201d.<\/p>\n

Los estudios citados arriba dan una idea de qu\u00e9 factores han sido considerado frecuentemente como los m\u00e1s 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 \u00fanica de decir cu\u00e1ndo un programa es m\u00e1s \u201cusable\u201d que otro, ni siempre se puede discernir cu\u00e1l proyecto es m\u00e1s \u201cmaduro\u201d o \u201cestable\u201d. Adem\u00e1s, conseguir la informaci\u00f3n 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\u00f3n de los errores que se informen sea lo m\u00e1s r\u00e1pida posible. En muchos casos, el tiempo de demora en resolver problemas se puede estimar a partir de la informaci\u00f3n disponible en la Web del producto que se analice, pero no siempre es completo, y en ocasiones ni siquiera est\u00e1 a la vista.<\/p>\n

M\u00e1s all\u00e1 de la heterogeneidad, otro aspecto com\u00fan entre los diferentes modelos y metodolog\u00edas es que se presentan como una serie de etapas. Li y Moreschini [9] destacan las siguientes actividades principales en ellos: 1) identificaci\u00f3n del software; 2) obtenci\u00f3n de los factores a considerar2<\/sup><\/a> y las m\u00e9tricas con las que se evaluar\u00e1n los mismos; 3) proveer puntajes o recomendaciones de selecci\u00f3n como salida.<\/p>\n

\u00bfQu\u00e9 hacemos, entonces?<\/h3>\n

Aunque no existe ning\u00fan modelo aceptado ampliamente, y menos a\u00fan herramientas que permitan realizar la tarea de manera autom\u00e1tica, las distintas propuestas ponen de relieve distintos aspectos a tener en cuenta para seleccionar un software.<\/p>\n

Sin pretensiones de crear un nuevo modelo ni nada por el estilo, podemos extraer algunas ideas para adoptar nuestro propio m\u00e9todo.<\/p>\n

Los siguientes puntos pueden servir de gu\u00eda:<\/p>\n

    \n
  1. \n
      \n
    1. Definir lo m\u00e1s claramente posible qu\u00e9 es lo que queremos de un software (nuestros requerimientos) teniendo en cuenta si pretendemos usarlo tal como est\u00e1, hacerle algunas modificaciones (para adaptarlo a necesidades espec\u00edficas, por ejemplo) o usarlo como una pieza para un nuevo software.<\/li>\n
    2. Con la lista de funcionalidades escrita (al menos, con una primera<\/i> lista de funcionalidades), establecer qu\u00e9 puntaje se le dar\u00e1 a cada software de acuerdo a cu\u00e1nto cubren de cada funci\u00f3n. Aqu\u00ed tambi\u00e9n pueden definirse caracter\u00edsticas de calidad y las m\u00e9tricas que -seg\u00fan consideremos- representar\u00e1n dicha caracter\u00edstica.<\/li>\n
    3. Definir los pesos relativos de cada funcionalidad pedida.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
        \n
      1. \n
          \n
        1. <\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

          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.<\/p>\n

            \n
          1. \n
              \n
            1. <\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

              Al igual que con los caracter\u00edsticas funcionales, fijar puntajes para el cumplimiento total o parcial de las condiciones listadas en el punto anterior.<\/p>\n

                \n
              1. \n
                  \n
                1. <\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                  Definir los pesos relativos de las condiciones.<\/p>\n

                    \n
                  1. \n
                      \n
                    1. <\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

                      Calcular la suma ponderada.<\/p>\n

                      En la primera etapa se podr\u00edan incluir criterios de \u201cdenegaci\u00f3n\u201d, es decir, requisitos que implicar\u00e1n descartar el software si no los cumple. Ejemplo de ello podr\u00edan ser: la licencia, el tiempo de inactividad del proyecto (un programa que no saca nuevas versiones ni corrige errores hace muchos a\u00f1os es probable que tenga problemas de funcionamiento en la actualidad), o el lenguaje de programaci\u00f3n.<\/p>\n

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

                      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\u00e1s all\u00e1.<\/p>\n

                      Jorge Ramirez \u2013 2022<\/p>\n

                      http:\/\/dragonlibre.net<\/p>\n

                      CC BY-SA 4.0<\/p>\n

                      Bibliograf\u00eda<\/h3>\n

                      1. Miguel, J.P., Mauricio, D., Rodr\u00edguez, G.: A Review of Software Quality Models for the Evaluation of Software Products. ArXiv Prepr. ArXiv14122977. (2014).<\/p>\n

                      2. Duijnhouwer, C.F.-W.: Open source maturity model (OMMM). Technical report, Capgemini (2003).<\/p>\n

                      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.<\/p>\n

                      4. Petrinja, E., Sillitti, A., Succi, G.: Comparing OpenBRR, QSOS, and OMM assessment models. In: Open Source Software: New Horizons. pp. 224\u2013238. Springer (2010).<\/p>\n

                      5. Proen\u00e7a, C.R., Bernardino, J.: Evaluating Gant Project, Orange Scrum, and ProjeQtOr Open Source Project Management Tools using QSOS. In: ICSOFT. pp. 522\u2013528 (2019).<\/p>\n

                      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\u2013387 (2019).<\/p>\n

                      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\u201313 (2016).<\/p>\n

                      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\u2013444. IEEE (2020).<\/p>\n

                      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\u201350. Springer (2021).<\/p>\n

                      \n

                      1<\/a>En este texto hablaremos de \u201csoftware libre y de c\u00f3digo abierto\u201d. Si bien ambos conceptos son distintos, se refieren a conjuntos de productos muy similares, caracterizadas por licencias de distribuci\u00f3n que contemplan el acceso al c\u00f3digo fuente y brindan libertades a usuarios y desarrolladores que no est\u00e1n contempladas en los productos \u201cprivativos\u201d o de c\u00f3digo cerrado.<\/p>\n<\/div>\n

                      \n

                      2<\/a>Los autores utilizan la palabra \u201celicit\u201d, muy usada en la ingenier\u00eda de requerimientos para referirse a la tarea de obtener o \u201cextraer\u201d los requerimientos reales de un sistema de software a partir de fuentes muy distintas y usando m\u00e9todos diversos.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

                      La tarea de elegir un software libre o de c\u00f3digo 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\u00e1 en alguna tarea, es probable que nos encontremos con […]<\/p>\n","protected":false},"author":1,"featured_media":351,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"\u00bfC\u00f3mo elegir un software libre si hay varias opciones? Un repaso a la historia y algunas ideas para evaluar y seleccionar","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[15],"tags":[56,55,43],"class_list":["post-344","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-informatica","tag-calidad","tag-evaluacion-de-software","tag-software-libre"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/dragonlibre.net\/wp-content\/uploads\/2022\/05\/Serious-and-hard-decisions.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/posts\/344","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/comments?post=344"}],"version-history":[{"count":5,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/posts\/344\/revisions"}],"predecessor-version":[{"id":352,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/posts\/344\/revisions\/352"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/media\/351"}],"wp:attachment":[{"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/media?parent=344"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/categories?post=344"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dragonlibre.net\/index.php\/wp-json\/wp\/v2\/tags?post=344"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}