Universidad ORT Uruguay

Facultad de Ingeniera

Proceso de seleccin de software

Walter Fernndez - 4704

Pablo Larraz - 14066
Edgardo Silvera 81134

2009
 INDICE

INTRODUCCIN...........................................................................................................3

ABSTRACT......................................................................................................................4

1. CONCEPTOS BSICOS.............................................................................................5

1.1. Objetivos de este documento.............................................................................5

1.2. Sistemas Floss...................................................................................................5
1.3. Relevancia del software de monitoreo para el proyecto SIGNA......................6
1.4. Breve resea del cliente.....................................................................................7
1.5. reas y funciones Involucradas.........................................................................7
1.6. Participantes directos en la seleccin e implementacin del sistema................8

2. PROCESO DE SELECCIN....................................................................................8

2.1. Etapa 1: Caractersticas y requerimientos del sistema a elegir..........................9

2.2. Etapa 2: Lista de Sistemas Floss (Primera Seleccin).....................................10
2.3. Etapa 3: Metodologa de seleccin de software..............................................11
2.3.1. Importancia de la Metodologa....................................................................11
2.3.2. Descripcin de Metodologas......................................................................11
2.3.2.1. QSOS.......................................................................................................12
2.3.2.2. BRR.........................................................................................................14
2.3.3. Comparacin de los enfoques QSOS y BRR..............................................16
2.3.4. Seleccin de la metodologa a utilizar.........................................................17

REFERENCIAS..............................................................................................................19
 CAPITULO 1 - INTRODUCCIN

Este documento es parte de la investigacin realizada por el equipo del proyecto

SIGNA1 (Sistema Integral de Gestin y Notificacin de Alarmas) con el objetivo de
determinar el proceso mas apropiado de seleccin de un sistma de cdigo abierto..

El proyecto SIGNA tiene como objetivo principal investigar e implementar una solucin
fiable para el monitoreo de componentes de un centro de cmputos y posterior
notificacin de problemas identificados.

La solucin implementada debe monitorear los diferentes servicios, para lograr una
mayor calidad y disponibilidad de los mismos, de forma de contar con una herramienta
que permita detectar problemas en los distintos componentes del sistema.

Para ello se basa en la utilizacin de tecnologas de cdigo libre que sean capaces de
detectar incidentes e informarlos. Estos problemas sern notificados a tcnicos para
que estos puedan resolver las fallas en el menor tiempo posible.

Se presentarn en este documento una serie de conceptos que revelarn la

importancia del proceso de seleccin de software, debido a que el sistema
seleccionado va a ser un componente central en la solucin final. Por dicha
importancia se debe elegir el sistema que mejor se adecue en la fase de seleccin.

Es entonces evidente la relevancia que adquiere el proceso de seleccin del sistema y

la metodologa empleada para elegirlo.

1
SIGNA-Sistema Integral de Gestin y Notificacin de Alarmas.

3
ABSTRACT

Este documento comienza con la exposicin de distintos conceptos, definiciones y

aspectos importantes sobre los sistemas de cdigo abierto. Se expone lo importante
que es el sistema que se elegir para el proyecto SIGNA. Luego se presentar una
breve descripcin del cliente, las funciones que se van a ver afectadas con el nuevo
sistema y los participantes en el proceso de seleccin e implantacin del mismo. Se
expone el proceso de seleccin de software elegido para realizar la eleccin, este
esta compuesto por 3 etapas que consisten en: identificacin de los requerimientos
bsicos del cliente, bsqueda de sistemas candidatos y por ltimo definicin de una
metodologa a seguir que permita realizar una comparacin objetiva de los sistemas,
de forma de poder realizar la mejor eleccin posible. Se realiza una breve descripcin
y comparacin de las metodologas QSOS2 y BRR3, con el objetivo de seleccionar una
de ellas y utilizarla en la etapa 3 del proceso de seleccin.

2
QSOS: Qualification and Selection of Open Source software.
3
BRR: Business Readiness Rating for open source.

4
1. CONCEPTOS BSICOS

Se presentarn en esta seccin una serie de conceptos que brindarn un punto de

partida conceptual del anlisis.

1.1 Objetivos de este documento

Existe una amplia oferta de sistemas que pueden monitorear los componentes de una
red de datos. La eleccin del sistema apropiado resulta ser para el proyecto una de las
tareas ms importantes y crticas a realizar. Por este motivo es de suma importancia
evaluar cuidadosamente cada una de las posibles opciones que estn disponibles
hasta llegar a la eleccin del sistema ms adecuado.

El cliente solicita que se utilice como herramienta de monitoreo un sistema gratuito que
cumpla con la caracterstica de ser un sistema Floss (Free Libre Open Source
System).

La presente investigacin pretende alcanzar los siguientes objetivos:

Establecer un procedimiento de seleccin de software apropiado al proyecto.

Eleccin de una metodologa apropiada que permita comparar herramientas

Floss, con el objetivo de poder confrontar sistemas candidatos entre si y llegar
a la eleccin del sistema que mejor se adapte a las necesidades planteadas.

En este documento no se expondr la comparacin ni la seleccin final del sistema,

slo se har referencia a los procesos y metodologas utilizadas para llegar al mismo.

1.2 Sistemas Floss

Segn Pessagno, Leslibeth; Domnguez, Kenyer; y otros (2008) [1], en el mercado

existen herramientas que se caracterizan por combinar las caractersticas de software
libre y Software Open Source, que se pueden resumir en los siguientes aspectos:
acceso al cdigo fuente, modificacin del cdigo, sin restricciones de uso, copia y
redistribucin. No obstante, seleccionar este tipo de herramientas no es una tarea fcil,
pues deben satisfacer, adems de los requisitos del negocio, las propiedades de
Free/Libre Open Source Software (Floss).

Segn Open Source Initiative [2] estos sistemas no slo significan tener la posibilidad
de acceso al cdigo fuente, sino que tambin deben de cumplir con ciertas
caractersticas.

5
 Libre Redistribucin: La licencia de un componente no debe restringir la venta o
el uso de una distribucin de software integrado por otras fuentes. La licencia no
tendr que requerir una tarifa por dicha venta o uso.

Cdigo Fuente: El programa debe incluir y permitir la distribucin del cdigo

fuente, as como la forma compilada.

Trabajos Derivados: La licencia debe permitir modificaciones y trabajos

derivados, y debe permitir que se distribuya bajo los mismos trminos que los de
la licencia del software original.

Integridad del Cdigo Fuente del Autor: La licencia puede restringir la

distribucin del cdigo fuente modificado slo si permite la distribucin de
"archivos de revisin" con el cdigo fuente.

No debe existir discriminacin contra Personas o Grupos: La licencia no debe

discriminar a ninguna persona o grupo de personas.

No debe existir discriminacin contra reas especficas de trabajo: La licencia

no debe restringir a nadie de hacer uso del programa.

Distribucin de la licencia: Los derechos vinculados al programa deben

aplicarse a otras aplicaciones que lo redistribuyan, sin necesidad de contar con
una licencia adicional.

La licencia no debe ser especfica a un producto: Los derechos vinculados al

programa no debe depender de que este forme parte de una distribucin
particular.

La licencia no debe restringir otro software: La licencia no debe imponer

restricciones sobre otro software.

La Licencia debe ser tecnolgicamente neutral: No debe haber predisposicin

para que se utilice cierta tecnologa o estilo de interfaz.

1.3 Relevancia del software de monitoreo para el proyecto SIGNA

El sistema de monitoreo es un componente muy importante dentro del proyecto, ya

que se constituir en el ncleo del sistema, cumpliendo con tareas esenciales de
vigilancia y notificacin de alarmas, adems CSIGNA se basar en ste como fuente
principal de datos para identificar los costos provocados por problemas en los
sistemas. Por consiguiente su eleccin es una tarea crtica. Para realizar la seleccin
se implementar el proceso de seleccin que sea el ms apropiado para ello.

6
1.4 Breve resea del cliente

Como lo sugiere la actividad 1 de la fase 1 de la Metodologa de Seleccin de un

Sistema ERP4 (MSEE), segn Florencia Chiesa (2004) [3], se van a identificar las
necesidades del cliente y determinar el equipo de proyecto. Para armar esta seccin
del documento es necesario que el equipo de proyecto se rena con el cliente. De
estas reuniones se obtendr la informacin sobre las necesidades que debe cubrir el
sistema de monitoreo y las personas que estarn involucradas en el proyecto.

El cliente es el Centro de Cmputos del Ministerio de Transporte y Obras Pblicas de

la Repblica Oriental del Uruguay (MTOP). Cuenta con la necesidad de obtener un
sistema que le ayude con el cometido de informar eventos o alarmas crticas que se
disparen en equipos o sistemas, incluso se ha remarcado la necesidad de informar
sobre estas alarmas ya sea por medio de correos electrnicos o mensajes de texto de
forma automtica.

El cliente piensa migrar en un futuro cercano el centro de cmputos a un nuevo lugar

fsico, y agregar nuevo equipamiento al ya existente, como as tambin nuevas
aplicaciones crticas, entre ellas estara incluida el sistema de monitoreo. Como
principal caracterstica el cliente solicita que este sistema sea de cdigo abierto.

Siguiendo las recomendaciones de la metodologa expuesta por Florencia Chiesa

(2004)[3]sedebe definir y establecer el marco general de referencia para la seleccin
del sistema. Aspectos que se deben considerar son:

La definicin de las reas y funciones de la empresa que se abarcarn con el

sistema, esta definicin debe contemplar los planes estratgicos de la empresa
y debe tener una visn a largo plazo.

Los participantes en el proceso de seleccin del sistema.

1.5 reas y funciones Involucradas

El rea directamente afectada por el nuevo sistema es el centro de cmputos del

MTOP, este cuenta con personal limitado por lo cual es imprescindible automatizar la
mayor cantidad de tareas posibles. Dentro de las tareas de mayor grado de
automatizacin se ubican las tareas de monitoreo, las cuales se pueden realizar a
travs de aplicaciones especificas para ese fin. De esta manera se espera liberar el
personal de realizar estas tareas y encomendarle otras de igual o mayor importancia.

El sistema de monitoreo impactar directamente sobre esta rea de forma de

permitirle a los funcionarios del centro de cmputos mayor disponibilidad de tiempo
para desarrollar otras tareas.

4
ERP- Enterprise Resource Planning

7
1.6 Participantes directos en la seleccin e implementacin del sistema

Las personas que van a participar directamente en la seleccin e implantacin del

sistema son:

Responsable centro de cmputos del MTOP: Responsable de definir los

requisitos que el software debe cumplir, definir las caractersticas y funciones
principales del mismo. Para ello se basar en su experiencia al frente del rea
y su visin de futuro.

Equipo de proyecto SIGNA: Son las personas encargadas de coordinar el

proyecto y las actividades del proceso de seleccin. Sern responsables de la
eleccin, e implementacin del software. Trabajan tiempo completo en el
proyecto. En el proceso de seleccin realizan las tareas de recopilar
informacin, prepararla, deciden junto al cliente la eleccin del sistema,
organizacin de reuniones y armado de cuestionarios. Trabajarn en la
implementacin del sistema seleccionado. Se encargarn de la implementacin
y realizacin de complementos que permitirn cubrir todas las expectativas del
cliente establecidas de comn acuerdo en el documento de Especificacin de
Requerimientos de Software.

Grupo de usuarios: formado por distintos usuarios del centro de cmputos del
MTOP. Son las personas que usarn el sistema luego de implantado.

1.6.1 PROCESO DE SELECCIN

Segn Daffara,Carlo(2007),el proceso de seleccin de software es muchas veces

ignorado aunque es extremadamente importante en el momento de realizar una
adopcin de un sistema Free Libre Open Source System (Floss). Identifica 3 etapas
que se deben seguir para seleccionar de forma exitosa un sistema Floss:

Etapa 1: Identificar sus requerimientos

Etapa 2: Buscar los sistemas que se ajusten a los requerimientos funcionales.

Etapa 3: Seleccionar el sistema apropiado de un conjunto de sistemas

encontrados, en base a una metodologa de seleccin.

El primer paso es crucial para que la seleccin del software sea exitosa. Para llevar
adelante esta fase se requiere confeccionar una lista de requerimientos o funciones
tiles y necesarias que el software debe contemplar.

8
Luego de tener la mencionada lista hay que encontrar los sistemas que cumplan con
los requerimientos establecidos. Existen muchos sitios web que proveen informacin
de software disponible. Algunos de los sitios ms importantes son:

http://sourceforge.net/
http://savannah.gnu.org/
https://gna.org/
http://alioth.debian.org/
http://www.berlios.de/
http://codehaus.org/

Los repositorios usualmente son divididos en Estables y Inestables para proveer a

los usuarios de informacin que le permita elegir entre software estable y versiones
que no fueron probadas a fondo. Para este trabajo es necesario elegir un sistema
estable.

Luego de tener un conjunto de aplicaciones potencialmente aptas como para ser

elegidas, es fundamental evaluar las distintas opciones. Para ello se puede utilizar
alguna metodologa de seleccin de software Floss.

Adems de las 3 etapas presentadas anteriormente, se hace imprescindible agregar

una nueva que consiste en analizar la posibilidad de realizar alguna adaptacin del
sistema elegido en caso de ser necesario, por ejemplo agregar alguna funcionalidad
que no est contemplada en el sistema, y su posterior implantacin en el cliente. Esta
etapa no esta incluida en el proceso de seleccin del sistema pero si dentro del
proyecto SIGNA.

1.7 Etapa 1: Caractersticas y requerimientos del sistema a elegir.

De acuerdo a la Etapa 1 del procedimiento de seleccin de software expuesto en el

punto anterior se requiere confeccionar una lista de requerimientos o funciones tiles
y necesarias que el software debe contemplar.

Para realizar esta lista se organizan reuniones con el responsable del centro de
cmputos y se recogen las siguientes caractersticas que el software de monitoreo
debe cumplir:

Debe ser un sistema Floss

Se debe poder implementar sobre cualquier sistema operativo.
Debe poder monitorear distintas plataformas.
La aplicacin de monitorizacin debe vigilar sistemas y aplicaciones
Debe generar alertas cuando se sobrepasen umbrales definidos.
Debe monitorear hardware y software tales como (aplicaciones, Sistemas
Operativos, bases de datos, servidores web, VPN, procesos, servicios, etc.).
Debe detectar interfaces de red cadas.

9
 Debe enviar mensajes SMS informando cuando falle algn sistema o aplicacin
que se considere esencial.
Debe generar informes, estadsticas.
Debe monitorear cortafuegos, proxies, routers, switches.

1.8 Etapa 2: Lista de Sistemas Floss (Primera Seleccin)

El objetivo de esta actividad es la bsqueda en el mercado de los sistemas

disponibles. Como opciones de bsqueda se presentan: Internet, exposiciones de
software, revistas profesionales del rubro, consulta con profesionales que conozcan el
dominio. La opciones elegidas de bsqueda son: bsqueda en Internet (se investigan
las direcciones web nombradas en el punto 2 de este documento y otros sitios) y
consulta a profesionales con conocimientos del dominio.

De la bsqueda de aplicaciones que en principio cumplen con los requerimientos

establecidos se arma un listado que provee de sistemas de monitoreos encontrados.

Nombre URL
Aarhus http://argus.tcp4me.com/
CA eHealth http://www.ca.com/us/network-performance.aspx
Cacto http://www.cacti.net/
CiscoWorks LMS http://www.cisco.com/en/US/products/sw/cscowork/ps2425/index.html
Collectd http://collectd.org/
dopplerVUE http://www.dopplervue.com/
Entuity http://www.entuity.com/
Everest http://www.lavalys.com/
fireScope BSM http://www.firescope.com/Products/BSM/
freeNATS http://www.purplepixie.org/freenats/
Ganglio http://ganglia.info/
GroundWork Community http://www.groundworkopensource.com/community/
GroundWork Enterprise http://www.groundworkopensource.com/products/enterprise/
Heroix Longitude http://www.heroix.com/
Hyperic www.hyperic.com
Intellipool Network Monitor http://www.intellipool.se/
InterMapper http://www.intermapper.com/
LoriotPro http://www.loriotpro.com/
ManageEngine OpManager http://www.manageengine.com/products/opmanager/
Munin http://munin.projects.linpro.no/
Nagios http://www.nagios.org/
NeDi http://www.nedi.ch/
NetCrunch http://www.adremsoft.com/netcrunch/
Netscope http://www.netscope.nl/
Nimsoft http://www.nimsoft.com/
Op5 Monitor http://www.op5.se/nyheter/201-op5-releases-new-version-of-op5-monitor-
OpenNMS http://www.opennms.org/index.php/Main_Page
Opsview http://www.opsview.org/
Osmius http://www.osmius.net/es/
PacketTrap http://www.packettrap.com/
Pandora FMS http://pandorafms.org/
Performance Co-Pilot http://oss.sgi.com/projects/pcp/

10
Plixer Scrutinizer http://www.plixer.com
Polymon http://www.codeplex.com/polymon
Server-Eye http://www.server-eye.co.uk/en/
Seven-Layer http://architel.com/integration-services/seven-layer/
SevOne http://www.sevone.com/
SNM http://snm.sourceforge.net/
SolarWinds http://www.solarwinds.com/
Uptime Software http://www.uptimesoftware.com/
WhatsUpGold http://www.whatsupgold.com/
Wormly http://www.wormly.com/
Simn http://www.xymon.com/
z/OS RMF http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/
Zabbix http://www.zabbix.org/
Zenoss http://www.zenoss.com/
Zyrion Traverse http://www.zyrion.com/?src=nocol
Tabla 1: Sistemas candidatos

De esta larga lista de sistemas candidatos se elegir el que mas se adecue a las
necesidades de este proyecto, para ellos se aplicarn una serie de pasos que se
describirn a continuacin en este documento.

1.9 Etapa 3: Metodologa de seleccin de software

Segn FlorenciaChiesa(2004)[3],una metodologa intenta organizar el proceso de

seleccin de un sistema de forma que se pueda escoger el sistema que mejor cumpla
con una serie de requisitos. Apunta a encontrar el producto adecuado en el mercado
evaluando distintos aspectos de los mismos.

1.9.1 Importancia de la Metodologa

Atos Origin (2006) [5] sostiene que cuando se planea estudiar que tan adecuado es un
software open source es necesario contar con un mtodo de calificacin y seleccin
adaptado a las caractersticas de este tipo de software. Es muy importante examinar
las limitaciones y los riesgos especficos para las aplicaciones Open Source. Por ende
es necesario contar con un mtodo de calificacin que permita diferenciar la numerosa
cantidad de candidatos que cumplen con los requerimientos tcnicos funcionales y
estratgicos.

1.9.2 Descripcin de Metodologas

Existen muchas metodologas que proponen ayudar a seleccionar un sistema Floss.

Segn Ciolkowski, Marcus y otros (2007) [6] algunas de las metodologas ms
conocidas desarrolladas con este fin son:

Open Source Maturity Model (OSMM) desarrollado por Bernard Golden de

Navicasoft.

11
 Open Source Maturity Model (OSMM) desarrollado por CapGemini.

Business Readiness Rating (BRR) creado por Atos Origin.

Qualification and Selection of Open Source software (QSOS) creada por

Carnegie Mellon West y Intel.

Todas estas metodologas crearon plantillas de evaluacin y generaron sistemas de

puntuacin para proyectos de cdigo abierto en base a diferentes criterios.

En esta parte del trabajo se realizar una exploracin sobre las caractersticas de las
metodologas y se analizar los sistemas de puntuacin que proveen estos modelos
con el fin de compararlos y seleccionar uno. El modelo seleccionado se usar para la
eleccin del software de monitoreo. Para realizar la comparacin se eligen las
metodologas QSOS y BRR ya que son 2 destacadas metodologas segn Deprez,
JeanChristophe,Simon,Alexandre [7] y surgidas ms recientemente. En esta seccin
se realizar una breve descripcin de de las metodologas QSOS y BRR.

1.9.2.1 QSOS

Para describir esta metodologa nos basamos en AtosOrigin(2006) [5] se expone la

versin 1.6 de la metodologa. El proceso general de QSOS est constituido por 4
etapas:

Definicin: Constitucin y enriquecimiento de los marcos de referencia

utilizados en los siguientes pasos. Los marcos de referencias son: las
familias de software, los tipos de licencia y los tipos de comunidad.

Evaluacin: Consiste en recolectar informacin de las comunidades open

source para construir tarjetas de identidad5 de cada software, y adems
construir las hojas de evaluacin 6 mediante la puntuacin de criterios,
realizado sobre tres ejes de criterios: aspectos funcionales, los riesgos
desde la perspectiva del usuario y los riesgos desde la perspectiva del
proveedor del servicio.

Los criterios funcionales son determinados por la familia del software y son
extrados desde el marco de referencia de la etapa de definicin. Se puede
consultar el sitio http://www.qsos.org para obtener detalles funcionales de
5
Tarjetas de Identidad: tipo de documento utilizado por la metodologa QSOS que registra informacin
general de los distintos sistemas Floss.
6
Hojas de Evaluacin: tipo de documento utilizado por la metodologa QSOS que registra informacin de
sistemas Floss mas detallada que las tarjetas de Identidad.

12
 las familias de software. En esta etapa se puntan los distintos criterios con
puntajes de 0, 1 2 donde:

Funcionalidad Puntuacin
No cubierta 0
Parcialmente cubierta 1
Totalmente cubierta 2
Tabla 2: Puntuacin de los criterios funcionales

En el eje de riesgos desde la perspectiva del usuario, se incluyen los

riesgos incurridos por el usuario cuando realiza la adopcin de software
libre o software open source. La puntuacin de los criterios se hace con
independencia de cualquier contexto particular del usuario (el contexto se
considera ms adelante la etapa 3 de Calificacin). Estos criterios se
dividen en categoras 5 categoras:

Durabilidad intrnseca
Solucin industrializada
Integracin
La capacidad de adaptacin tcnica
Estrategia

Respecto al eje de los riesgos desde la perspectiva del proveedor de

servicios se agrupa los criterios de evaluacin para estimar los riesgos
contrados por un contratista de servicios que ofrece en torno a un software
de cdigo libre o abierto (conocimientos, integracin, desarrollo, apoyo,
etc.).

En AtosOrigin(2006)[5] se muestran cuadros que detallan cada una de las

categoras nombradas, especificando subcategoras y las mtricas
relacionadas con ellas, adems la puntuacin para cada una de ellas.

Calificacin: El objetivo de esta etapa es el de definir filtros evaluando las

necesidades y limitaciones relacionadas a la seleccin de un sistema libre o
uno open source para el contexto dado. Esto se puede lograr calificando el
contexto del usuario que ser utilizado posteriormente en la prxima etapa
para la seleccin. Se pueden filtrar sistemas por las tarjetas de
identificacin. Tambin se pueden filtrar sistemas verificando criterios
establecidos en el paso anterior, o sea aspectos funcionales, los riesgos
desde la perspectiva del usuario y los riesgos desde la perspectiva del
proveedor del servicio.

Seleccin: El objetivo de este paso es identificar el software segn los

requisitos del usuario, o ms general comparar el software de la misma
familia. Existen 2 modos posibles de seleccin, uno estricto y otro ms
amplio.

13
 La seleccin estricta se basa en la eliminacin directa de sistemas que no
cumplan con requerimientos formulados en la etapa anterior de Calificacin,
es posible realizar la eliminacin en base a:

La utilizacin de las tarjetas de identificacin, eliminando

aquellos sistemas incompatibles.
El sistema no ofrece las funcionalidades previstas.
Las puntuaciones obtenidas en los criterios relevantes o crticos
no son las esperadas.

Tambin se puede realizar una seleccin menos estricta que la anterior

porque mas que eliminar los sistemas que no cumplan con criterios
preestablecidos se clasifican mientras se le aplican las mtricas de filtrado.
Para ello se ponderan las funcionalidades y la importancia de cada criterio
definido en el eje de los riesgos de usuarios.

Para comparar los sistemas de una misma familia con criterios de

funcionalidades comunes pueden ser comparados usando puntuaciones
ponderadas determinadas en etapas anteriores.

1.9.2.2 BRR

Para describir y evaluar esta metodologa nos basamos en BRR (2005) [8]. Esta
metodologa separa el proceso de evaluacin en 4 etapas:

Evaluacin Rpida: En esta etapa se intenta identificar una lista de

componentes para ser evaluados. Se establecen medida de cada uno de
los componentes contra criterios de evaluacin rpida definidos
previamente. Por ltimo se elimina cualquier componente de software de
cdigo abierto que no se ajuste a las necesidades de los usuarios de la
lista.

Evaluacin segn el objetivo de uso: En esta etapa se determinan

distintos criterios de ponderacin.

(a) Ponderacin de categoras: Se clasificarn 12 categoras definidas por

la metodologa de acuerdo a la importancia, siendo 1 la categora de mayor
importancia y 12 la de menor importancia. Las categoras de evaluacin
son:

Categora de
Evaluacin Descripcin

14
 Funcionalidad Cmo el software podr satisfacer las
necesidades del usuario?
Qu tan buena es la interfaz de usuario? Qu
Usabilidad tan fcil de usar es el software para los usuarios
finales? Qu tan fcil es el software para
instalar, configurar, implementar y mantener?
De qu calidad son el diseo, el cdigo y las
Calidad pruebas? Qu tan completos y libre de errores
son?
Seguridad Qu tan bien el software maneja la seguridad?
Qu tan seguro es?
Rendimiento Qu tan performante es el software?
Escalabilidad Qu tan escalable es para un ambiente amplio?
Qu tan buena es la arquitectura de software?
Arquitectura Cmo tan modular, porttil, flexible y extensible,
abierto y fcil de integrar es?
Compatibilidad Qu tanto es el componente de software
compatible?
Documentacin De que calidad es la documentacin refernte al
software?
Adopcin Qu tan bien es el componente aprobado por la
comunidad, el mercado y la industria?
Comunidad Qu tan activa y dinmica es la comunidad para
el software?
Cul es el nivel de la profesionalidad del
Profesionalismo proceso de desarrollo y la organizacin del
proyecto en su conjunto?
Tabla 2: Categoras de ponderacin de la metodologa BRR.

El prximo paso es elegir las 7 (o menos) categoras ms importantes

expuestas en (a), y asignarle un porcentaje de importancia para cada una
de ellas, totalizando un 100% para las categoras elegidas.

(b) Ponderacin de mtricas: Cada mtrica de una categora hay que

agregarla en un ranking de acuerdo a la importancia para la disposicin
del negocio. Posteriormente para cada una de ellas, se debe asignar un
porcentaje de importancia, la suma total para todas las mtricas de una
categora debe ser de 100%.

La recoleccin de datos y el procesamiento: Se debe reunir datos para

cada mtrica utilizada en cada categora de calificacin, y calcular el
coeficiente aplicado para cada indicador.

Traduccin de datos: Usar las puntuaciones de las categoras y los

factores de ponderacin funcionales para calcular la puntuacin BRR del
software, luego publicar la puntuacin de BRR del software.

15
1.9.3 Comparacin de los enfoques QSOS y BRR

En esta seccin se comparan los enfoques expuestos en el punto anterior, analizando

sus similitudes y diferencias, basados en el trabajo de Deprez,JeanChristopheySimon,
Alexandre [7], quienes sostienen que ambas metodologas son similares en los
siguientes aspectos:

(a) Cada metodologa propone un conjunto predefinido de criterios de evaluacin

con el cual se comparan los proyectos Floss. El conjunto de criterios de
evaluacin se clasifican en una jerarqua de rbol, esta jerarqua es de 2
niveles para la metodologa BRR y es de 3 niveles para QSOS.

(b) La evaluacin consiste en puntuar los distintos criterios sobre la base de un

procedimiento de puntuacin estndar. Durante la evaluacin de un proyecto
Floss, este paso se traduce en la asignacin de puntaje a cada criterio. Se
considera a esta puntuacin como absoluta.

(c) Los usuarios pueden ajustar la importancia de cada criterio en funcin de su

contexto, variando el peso asignado a cada criterio. En particular, durante una
evaluacin, los resultados absolutos estn ponderados en base a su
importancia en el contexto actual de evaluacin.

(d) Se puede tomar una decisin en base a los resultados obtenidos.

Sin embargo las metodologas difieren en el orden en que se aplican los puntos. Ya
que el orden descrito anteriormente refleja la forma de trabajo que propone la
metodologa QSOS, pero no el de la metodologa BRR, que sugiere invertir el orden de
las etapas b) y c) de forma que los usuarios primero seleccionen los criterios
relevantes dentro de su contexto y, por lo tanto evitar puntuar aquellos criterios que
son intiles. Adems, la metodologa BRR permite la creacin de nuevos criterios as
como la adaptacin de los procedimientos de puntuacin.

La metodologa QSOS sostiene que los resultados obtenidos al aplicar el sistema de

procedimientos de calificacin son universales. Por lo tanto, el procedimiento de
puntuacin para una versin particular de un proyecto Floss se lleva a cabo slo una
vez. Es posible que no todos estn de acuerdo con el resultado de la evaluacin y por
consiguiente sostener que este puede parecer injusto. Sin embargo, una vez que se
haya acordado la puntuacin absoluta surgida para una versin de un proyecto Floss,
estos resultados se convierten en universales y eventualmente se ponen a disposicin
de todos. La nica manera de ajustar el resultado final de una evaluacin es el de
adaptar los pesos asignados a los criterios de evaluacin.

Por otra parte la metodologa BRR asume que cada usuario instancia la metodologa
de maneras distintas. Por lo tanto, la evaluacin de un proyecto Floss provoca
resultados ligeramente diferentes dependiendo del contexto en el que la evaluacin se
lleva a cabo. Por consiguiente el resultado de una evaluacin no es absoluto ni

16
disponible para su reutilizacin, ni siquiera los resultados absolutos obtenidos para los
criterios de evaluacin. En el caso de BRR, esto parece ser muy razonable, ya que el
usuario es libre de aadir y eliminar criterios de evaluacin, as como para modificar y
crear nuevos procedimientos de calificacin para criterios nuevos o existentes. Por
consiguiente, BRR ofrece una metodologa estndar y que procura ser adaptable en la
prctica segn los distintos contextos.

Como resultado de la diferencia entre las metodologas en cuanto a la estrategia de

reutilizacin de QSOS y la adaptacin de BRR a los distintos contextos, se espera
encontrar un creciente repositorio de evaluaciones de productos para QSOS, y que no
lo haya para BRR. QSOS puede aplicar una estrategia de este tipo debido a que su
procedimiento de puntuacin slo permite una serie de tres puntuaciones 0, 1 y 2. Por
lo tanto, la diferencia de resultados entre los diferentes evaluadores se reduce.

Por otro lado cabe sealar que QSOS define el alcance de una evaluacin basada en
una versin particular de un producto Floss mientras esta informacin no es clara para
BRR. Por lo tanto, podemos suponer que BRR parece dejar esta cuestin abierta para
que sea posible aplicar la metodologa para un alcance de un proyecto en su conjunto,
o slo para una versin especfica de un producto Floss determinado. Esto plantea
que al aplicar los procedimientos de puntuacin sea muy importante definir claramente
el alcance del estudio, definir a que versin del software son los datos recogidos con el
fin de no incluir datos relacionados con otras versiones. En algunos casos, esto no es
fcil o factible. Por ejemplo, los libros publicados de un sistema no siempre especifican
que versin se est evaluando. Por lo tanto, esto puede hacer que el procedimiento de
puntuacin sea ambiguo.

1.9.4 Seleccin de la metodologa a utilizar

Para seleccionar la metodologa a utilizar en la eleccin del software Open Source de

monitorizacin nos basamos en el anlisis de los documentos de dichas tecnologas y
en la seccin de comparacin de metodologas QSOS y BRR de Deprez, Jean
ChristopheySimon,Alexandre[7].

En primera instancia, se consulta la pgina <http://www.qsos.org/sheets/index.html>

en donde se exponen las publicaciones de los resultados de los distintos sistemas
Floss ya obtenidos mediante la aplicacin de la metodologa QSOS de forma objetiva
por otros investigadores. El anlisis de estos resultados puede servir como marco de
referencia. Se recorre la lista de los sistemas publicados, pero no se encuentra
ninguno de los sistemas expuestos en la tabla 1 de este documento, de forma que no
es posible tomar como referencia esta fuente de informacin objetiva y universal.

Por consiguiente se prosigue a la eleccin de la metodologa a aplicar. Al momento de

elegir la metodologa se prioriza el hecho de poder contemplar el contexto actual del
proyecto, el hecho de poder ponderar criterios propios de este proyecto. Basado en
esta caracterstica, la metodologa elegida para realizar la comparacin de sistemas
Floss es BRR, ya que sta se adapta de forma mas adecuada a esta caracterstica,
por el hecho de ofrecer una metodologa estndar adaptable a distintos contextos.

17
REFERENCIAS

[1]Pessagno, Leslibeth; Domnguez,Kenyer;yotros. Modelo de calidad para

herramientas FLOSS que dan apoyo al modelado de procesos del negocio. En:
RevistaEspaoladeInnovacin,CalidadeIngenieradelSoftware. 2008. Vol.4,No.1.
Disponible en Internet: <http://www.lisi.usb.ve/publicaciones/11%20software
%20libre/software_04.pdf>

[2]OpenSourceInitiative.Open Source Definition. . Disponible en Internet:

<http://www.opensource.org/docs/osd>

[3]Chiesa,Florencia.2004.MetodologaparaseleccindesistemasERP.Disponible
enInternet:
<http://www.administracion.econo.unlp.edu.ar/655/paginas_web/06_materiales/ari_met
odologia_seleccion_%20ERP_o.pdf>

[4]Daffara,Carlo.2007.Free/LibreOpenSourceSoftware:aguideforSMEs.
DisponibleenInternet:<http://www.scribd.com/doc/2084063/Floss-Guide>

[5]AtosOrigin.2006.MethodforQualificationandSelectionofOpenSource
Software(QSOS)version1.6.DisponibleenInternet:
<http://www.qsos.org/download/qsos1.6en.pdf>

[6]Ciolkowski,Marcus;Soto,Martn;Deprez,JeanChristophe.2007. Measurement
RequirementsSpecifications(SpecificationofGoalsfortheQualOSSQualityModel).
DisponibleenInternet:http://www.qualoss.org

[7]Deprez,JeanChristophe,Simon,Alexandre.ComparingAssessment
MethodologiesforFree/OpenSourceSoftware:OpenBRR&QSOS.Disponibleen
Internet:
<http://www.qualoss.org/dissemination/DEPREZ_CompareFlOSSAssessMethodo
Camera02.pdf>

[8] BRR. 2005. BusinessReadinessRatingforOpenSource(AProposedOpen

StandardtoFacilitateAssessmentandAdoptionofOpenSourceSoftware ). Disponible
enInternet:<http://www.openbrr.org/wiki/index.php/Downloads

18