Análisis de Desajustes con Respecto a los Requisitos en la

Análisis de Desajustes con Respecto a los Requisitos en la

Análisis de Desajustes con Respecto a los Requisitos en
la Selección de Componentes OTS
Juan Pablo Carvallo1, Xavier Franch2
1
Universidad del Azuay
Av. 24 de Mayo 7-77 y Hernán Malo, Apartado 01.01.981
Cuenca, Ecuador
[email protected]
2
Universitat Politècnica de Catalunya (UPC)
c/ Jordi Girona 1-3 (Campus Nord) E-08034
Barcelona, Catalunya, España
[email protected]
Resumen. Debido a su complejidad, la mayoría de los sistemas de software
modernos se construyen integrando componentes de diversa naturaleza para
formar arquitecturas híbridas. La construcción de este tipo de sistemas se caracteriza por la adquisición de diversos componentes a proveedores externos a la
organización que se integran con algún software hecho a medida. La evaluación
y selección de dichos componentes demanda la identificación de desajustes,
mediante la comparación de sus características con respecto a los requisitos.
Los desajustes son posteriormente utilizados como base para el análisis y la negociación de los componentes más adecuados. Sin embargo, en la práctica, los
desajustes respecto a los requisitos deben ser debidamente interpretados a fin de
que se conviertan en un elemento válido que apoye al proceso de selección. En
este artículo abordamos este aspecto y realizamos una propuesta para el análisis
de desajustes en función del tipo de requisito al que se encuentran relacionados.
Palabras Clave: Modelos de calidad, requisitos, desajustes, selección, componentes, off-the-shelf.
1 Introducción
La mayoría de sistemas de software modernos se construyen integrando componentes
de software de diferente naturaleza y orígenes, en lo que se ha dado por llamar Sistemas de Arquitectura Híbrida [1]. Los componentes de software utilizados en este
enfoque arquitectónico incluyen componentes desarrollados por terceros, generalmente conocidos como componentes “Off-The-Shelf ” (OTS) [2] (p.e., componentes comerciales (COTS), componentes gratuitos y de código abierto (FOSS) y servicios
Web), así como software desarrollado en casa o a la medida y sistemas legados.
En este tipo de enfoque, la selección de los componentes OTS juega un rol predominante. Como resultado, se han propuesto varios métodos (v. [3] para un survey)
para conducir este proceso. Todos estos métodos requieren que las características de
calidad de los componentes sean comparadas respecto a los requisitos del sistema, a
fin de identificar los posibles desajustes. Estos desajustes son entonces utilizados
como base para el análisis, la negociación y eventualmente la decisión final sobre qué
componentes son los más apropiados para integrar la arquitectura propuesta.
La identificación y análisis de desajustes es un proceso complejo. Algunos de los
factores que influyen en esta complejidad son:
ƒ Los componentes OTS de grano grueso, p.e. los sistemas ERP, requieren de largos
periodos de parametrización (usualmente entre 6 meses a 2 años) antes de su entrada en producción en un ambiente particular. Por ello, es inviable en la práctica validar si dichos sistemas cumplen los requisitos antes de que el sistema haya sido seleccionado y se encuentre en operación. En otras palabras, si en un proceso de selección particular un proveedor afirma que todos los requisitos son satisfechos por
el componente ofertado, no hay forma de validar la presencia de desajustes respecto a tales requisitos antes de que sea demasiado tarde para dar un paso atrás.
ƒ Si un componente OTS particular no cumple con todos los requisitos, esto no significa necesariamente que no sea apropiado para operar en la arquitectura propuesta;
en algunos casos, se pueden utilizar componentes adicionales para llenar el vacío.
P.e., considerando los requisitos funcionales, la mayoría de sistemas ERP pueden
ser complementados con motores workflow, herramientas de cuadro de mando integral, etc., con el objeto de facilitar la modificación del comportamiento del sistema o extender su funcionalidad. En otros casos la negociación con los proveedores puede resultar en el desarrollo a la medida de la nueva funcionalidad requerida.
ƒ Las dependencias entre desajustes pueden comprometer el proceso de selección si
no son tratados en un orden apropiado. Por citar un caso, incluso si un determinado
componente OTS cumple con toda la funcionalidad requerida, puede que no sea la
mejor elección, pues deben considerarse posibles requisitos no técnicos para validar el riesgo de su adopción, p.e. la experiencia del equipo de consultores de la
empresa proveedora o la situación económica de la misma.
En este artículo abordamos la problemática del análisis y tratamiento sistemático de
los desajustes entre los componentes OTS candidatos a formar parte de la arquitectura
del sistema, respecto a los requisitos establecidos. Basamos nuestro enfoque, el método WORMS (por sus siglas en ingles: Weigths, Objectives, Rules, Mismatches, Selection), en el análisis del tipo de requisitos al cual se vinculan los desajustes. El artículo
se estructura de la manera siguiente: la sección 2 describe el trabajo relacionado; la
sección 3 introduce el método WORMS y lo describe de manera de tallada; la sección
4 ilustra el método con ejemplos tomados de un caso de estudio que aborda la selección de un sistema ERP para una empresa de Telecomunicaciones; finalmente la sección 5 presenta las conclusiones y las líneas de trabajo futuro.
2 Trabajo Relacionado
Los primeros métodos de selección de OTS (OTSO [4], PORE [5], etc.) fueron propuestos a mediados de la década de los 90. Todos ellos compartían ciertos principios
y actividades que han prevalecido en posteriores métodos: la necesidad de priorizar
requisitos; las interdependencias entre la formulación de requisitos y la evaluación de
componentes; el uso de técnicas de decisión multi-criterio; etc. No obstante, diversos
estudios (p.e. [6]) y nuestras propias experiencias muestran que la transferencia de
estos métodos al contexto industrial está lejos de considerarse satisfactoria. Entre los
diversos motivos que pueden citarse, destaca la dificultad de implementar en las organizaciones los métodos propuestos de forma eficaz, especialmente cuando los componentes OTS son de grano grueso. Se necesitan técnicas altamente eficientes para formular los requisitos y evaluar de forma confiable los componentes OTS, y que los
alinee de forma que su comparación durante el proceso de selección quede favorecida.
Uno de los artefactos que pueden usarse con este propósito son los modelos de calidad del software (MCs) [7]. Los MCs definen una jerarquía de factores de calidad
sobre un dominio de software (p.e., funcionalidad, eficiencia y portabilidad de los
sistemas CRM) y métricas para calcular su valor. La jerarquía de factores puede ser
utilizada como marco para: estructurar la información sobre las características del
software; categorizar diferentes tipos de requisitos; y facilitar la identificación de los
desajustes entre los requisitos del sistema y las capacidades de los componentes.
El uso de los MCs en los procesos de selección de OTS no es nuevo [8], [9], [10],
[11], [12]. En nuestro grupo, hemos utilizado MCs para la selección de componentes
OTS desde 2003 [13] en diversos casos reales y a partir de ahí hemos aprendido ciertas lecciones reportadas en [14]. Asimismo, en [15] realizamos un primer estudio de
los desajustes. En dicho trabajo, determinamos que los desajustes pueden clasificarse
según cuatro patrones predefinidos (cumple, difiere, falla y extiende), que permiten
hacer explícito el nivel al cual un determinado componente OTS cumple con los requisitos de calidad incluidos en los MCs. Sin embargo, en la práctica, hemos observado que la identificación y categorización de desajustes respecto a los requisitos, por sí
sola, no es suficiente para apoyar la negociación y eventualmente la decisión, sobre si
un determinado componente OTS es apropiado para integrarse en la arquitectura definida. Otras aproximaciones posteriores (p.e. [16]) no solucionan el problema pues se
centran más en la formulación de un modelo matemático preciso que en los aspectos
metodológicos y de aplicación práctica. Para solucionar estos problemas de aplicación, proponemos el método WORMS que presentamos en la sección siguiente.
3 Visión General del Método WORMS
Como se indicó en la introducción, WORMS se basa en la utilización de MCs que
describen la calidad del dominio software en el que el proceso de selección tiene
lugar. A lo largo del proceso, WORMS usa dichos MCs para elaborar los requisitos
de selección (que pueden ser vistos como la descripción del componente ideal) y la
descripción de los componentes OTS a evaluar (los que se encuentran disponibles en
el mercado). Los requisitos y las descripciones de los componentes se introducen en
los MCs, a modo de restricciones sobre los factores de calidad, haciendo uso de las
métricas propuestas para los mismos. Es importante destacar que, dada su naturaleza
de método derivado de casos prácticos resueltos por concurso de ofertas, el proceso
de selección propiamente dicho se realiza una vez los requisitos están completamente
determinados, en contraposición a la mayoría de métodos citados en la sección 2 que
consideran que los requisitos evolucionan a medida que se explora el mercado.
Partiendo de esta premisa, el método WORMS divide el proceso de selección en
dos fases: elaboración del modelo de requisitos y selección de componentes (v. Fig.1).
Fig. 1. Visión esquemática del método WORMS.
3.1 Fase I: Elaboración del Modelo de Requisitos
El modelo de requisitos se construirá en base al MC del dominio correspondiente,
considerando las prioridades de los mismos y su aplicación en la evaluación de objetivos de selección. Consideramos como punto de partida la existencia del MC, en caso
contrario podríamos aplicar el método IQMC [13] para construirlo.
Esta primera fase se organiza alrededor de cuatro actividades que se pueden ejecutar de forma iterativa según las necesidades del proyecto en cuestión, por ejemplo, si
es el primer proceso de selección en el dominio en cuestión o ya se dispone de experiencia (y artefactos) acumulada.
ƒ Actividad 1: Determinar los requisitos de partida. La estructura del MC sirve
como guía para determinar los requisitos en conjunto con las personas interesadas
(Stakeholders) y los usuarios finales. Para cada factor de calidad del MC, se determina si es de interés o no para el proceso de selección que nos ocupa. En caso de que no
lo sea, la subjerarquía que cuelga del factor se marca como irrelevante para el resto
del proceso. Si es de interés, se determina el requisito apropiado para dicho factor y la
métrica que se utilizará para medirlo. Esta información queda asociada a los factores
del MC, de manera que los requisitos quedan organizados de la misma manera que el
MC. Vale la pena destacar que, en caso de conducir diversos procesos de selección en
un mismo dominio software, los requisitos de calidad pueden reutilizarse entre experiencias según se propone en [17].
ƒ Actividad 2: Asignar pesos y prioridades a los requisitos. En la inmensa mayoría
de los casos, los componentes OTS disponibles en el mercado no satisfarán la totalidad de los requisitos, por lo que es esencial saber qué requisitos deben tener prioridad
sobre cuáles otros. Por ello, en esta actividad, se analiza la importancia de los requisitos y se les asigna pesos relativos y prioridades en relación al entorno de operación
particular. Al igual que en la actividad anterior, las personas interesadas y los usuarios
finales deben involucrarse totalmente en esta actividad; por lo tanto, si bien el proceso
de asignación de pesos y priorización es de naturaleza técnica, los artefactos utilizados para su soporte deben ser fáciles de manejar y entender por personal no técnico.
En general, la mayoría de técnicas se basan en el uso de matrices cuadradas, encabezadas en filas y columnas por un grupo de requisitos transpuestos. Estas matrices
pretenden, mediante la ejecución de un proceso sistemático de comparación de pares
“fila – columna” y la asignación de pesos relativos, identificar de una manera menos
subjetiva aquéllos que tienen un mayor peso o son prioritarios sobre otros. La priorización deberá incluir la identificación de requisitos obligatorios (no negociables), los
esquemas de conversión de métricas multivaluadas a pesos relativos, y la propagación
de factores de calidad de más concretos hacia los más abstractos incluidas en los
MCs.
ƒ Actividad 3: Identificar los objetivos de evaluación de los requisitos. Los objetivos de evaluación determinan los criterios que van a conducir el proceso de selección.
Los objetivos agrupan requisitos bajo un criterio determinado proporcionando un
nivel de granularidad que puede ser más indicado para el proceso. Distinguimos:
- Objetivos directos. Los factores de calidad determinan objetivos por si mismos.
Por ejemplo, el factor “Funcionalidad” genera el objetivo “Evaluar el alcance
funcional del componente”, mientras que el factor “Activos del Proveedor” genera el objetivo “Evaluar la solvencia económica del proveedor”. Mientras más
abstracto es el factor (i.e., más arriba reside en la jerarquía del MC), más factores (y por ende, requisitos) se encuentran implicados en el objetivo.
- Objetivos transversales. Determinadas estrategias propias de la tecnología de
los procesos software pueden dar lugar a objetivos que involucren factores de
calidad de muy diversa índole. Un ejemplo de tal objetivo sería “Evaluar el
riesgo de la inversión”, que involucra a multitud de factores en un análisis de
riesgos típico, p.e. factores relacionados con el análisis de la solvencia económica o técnica del proveedor, o experiencia previa de su equipo de consultores.
La evaluación de los objetivos debe considerar posibles conflictos. Así, un proveedor
podría satisfacer el objetivo directo “Evaluar la experiencia del proveedor” debido a
la existencia de un gran número de casos de éxito en el dominio de la selección, pero
podría representar un elevado riesgo de inversión si dichos casos de éxito correspondieran a entornos organizacionales muy diferentes al que realiza la evaluación, p.e.
empresas públicas vs. privadas, o de servicios vs. manufactura.
ƒ Actividad 4: Definir el orden y las reglas de análisis de los requisitos. Para conducir de una manera adecuada el proceso de evaluación, se deben definir algunas
reglas básicas con las que los requisitos serán evaluados. Entre ellas se pueden citar:
el orden de evaluación, el esquema de toma de decisiones a utilizar y los puntajes
máximos a asignar. El orden en que los requisitos son analizados puede afectar significativamente el resultado de, y el tiempo y los recursos empleados en, el proceso de
selección. Esto es particularmente cierto en la evaluación de componentes OTS de
grano grueso, en los que el proceso suele ser costoso en tiempo y recursos, y existen
muchas interrelaciones, debido a la gran cantidad de requisitos que deben ser evaluados. En estos casos se suele adoptar un proceso por etapas, en el que los componentes
deben aprobar la evaluación de uno o más requisitos asociados a los objetivos de
evaluación, previa la evaluación de otros, con el objetivo de reducir los potenciales
candidatos y el costo del proceso de evaluación en las siguientes etapas. No obstante,
es importante anotar que el orden de evaluación de los requisitos en los procesos de
evaluación por etapas debe ser estudiado con mucha atención pues puede conducir a
resultados erróneos. Así, por ejemplo, si se define que lo primero a evaluar será el
costo de licenciamiento, podría suceder que componentes técnicamente más apropiados para la arquitectura sean descartados de partida debido al costo de adquisición, sin
haber evaluado que desde el punto de vista técnico, el costo de integración podría ser
menor al de los demás, incluso llegando a compensar la diferencia de costo original.
3.2 Fase II: Selección de Componentes OTS en base al Modelo de Requisitos
Una vez se dispone de un modelo completo de los requisitos, con sus métricas, pesos,
prioridades, objetivos relacionados y reglas de evaluación, pueden evaluarse los componentes OTS candidatos. Canalizamos esta fase mediante dos actividades de carácter
básicamente secuencial.
ƒ Actividad 5: Identificar, analizar y evaluar los desajustes: Las características de
calidad de los componentes OTS considerados deben ser evaluadas en relación a los
requisitos descritos en los MCs, siguiendo el orden determinado en la actividad anterior. Se deberán identificar los desajustes existentes y categorizarlos en base a los
patrones más apropiados según las clases propuestas en [15]: cumple, difiere, falla y
extiende. Los desajustes identificados deberán ser analizados de manera metódica
considerando el orden de análisis predefinido, los pesos y prioridades asignadas, y los
objetivos de evaluación asociados a cada tipo de requisitos. Los desajustes hacen
evidentes las anomalías respecto a estos objetivos y facilitan el proceso de evaluación,
al reducir el número de factores en los que deben enfocarse las actividades de análisis
y negociación. Las conclusiones de este análisis deberán ser documentadas de una
manera estructurada y reportadas como apoyo al proceso de toma de decisiones.
Eventualmente no será necesario identificar todos los desajustes si estamos usando un
proceso escalonado, pues un componente puede ser descartado como solución en base
a la evaluación de los desajustes asociados a los requisitos más prioritarios.
ƒ Actividad 6: Seleccionar los componentes más idóneos: Una vez identificados los
desajustes y analizadas sus implicaciones durante el proceso de evaluación de los
componentes OTS, el equipo de selección deberá decidir sobre los componentes más
adecuados a ser incorporados en la arquitectura. Para esto se deberán considerar las
reglas de evaluación definidas para el proceso, y los puntajes totales computados en
cada etapa del proceso.
4 La Propuesta en la Práctica
Esta sección extiende la explicación de las actividades introducidas en la sección
anterior y las ilustra mediante un caso real de selección de un sistema ERP para una
empresa de telecomunicaciones.
Aunque de naturaleza municipal, la empresa en cuestión (establecida en Suramérica) cuenta con licencia para la provisión nacional de servicios de telefonía fija (pública y domiciliar), portadores de datos (enlaces locales y nacionales) y valor agregado
(acceso a Internet). Si bien la empresa es de orden privado, los fondos para su capitalización son de origen público provistos por el municipio que la constituyó. Por ello,
el proceso de selección que vamos a describir exigió ser conducido bajo las normas
que rigen al sector público del país de origen. Es decir, la empresa publicó un pliego
de condiciones al que los aspirantes debían responder. Ocho proveedores adquirieron
los términos de referencia del concurso, aunque sólo cinco presentaron ofertas.
La selección que vamos a describir es la de un sistema ERP. Para conducir el proceso de selección, se construyó un MC basado en el estándar de calidad ISO/IEC
9126-1 [18] siguiendo el método IQMC propuesto en [13]. El MC incluyó tres jerarquías bien definidas de factores de calidad:
ƒ Factores técnicos funcionales. Estructurados en una jerarquía de 7 niveles que
cuelga de la subcaracterística Suitability del estándar ISO/IEC 9126-1. El primer
nivel incluye 12 subcaracterísticas en relación a los módulos funcionales requeridos (adquisiciones y contrataciones, bancos, caja chica, cartera, contabilidad,
cuentas por pagar, activos fijos, costos, inventarios, presupuesto, recaudación y
recursos humanos), descompuestas en 6 niveles, incluyendo un total de 1.438 factores de calidad (v. Tabla 1).
ƒ Factores técnicos no funcionales, estructurados en 6 niveles, el primero conformado por las 6 características y el segundo por las 19 subcaracterísticas restantes
del estándar ISO/IEC 9126-1 (sin incluir las de Compliance de cada característica)
y su descomposición jerárquica a 5 niveles incluyendo un total de 356 factores .
ƒ Factores no técnicos, también estructurados en 6 niveles, encabezados por las
características Vendedor, Económica, y Producto, y su descomposición en 5 niveles adicionales con un total de 217 factores, presentados en [19, 20].
La construcción del MC, las cuatro actividades de la fase 1 del método WORMS y la
redacción de las bases del concurso, fueron conducidas por un Comité Técnico constituido por personal de la Dirección de Informática de la empresa (especialistas en
ingeniería de requisitos), y por funcionarios de las áreas Financiera, Administrativa y
De Procesos de la empresa.
La segunda fase del proceso fue conducida por etapas (como se describe más adelante), gobernada por un Comité de Calificación, presidido por el Gerente General y
conformado por los directores Jurídico y de Informática de la empresa, y dos técnicos
especialistas en el tema (uno propio de la empresa y uno externo nombrado por el
Colegio Nacional de Ingenieros Informáticos). Adicionalmente se nombró un Comité
Técnico conformado por un informático (el jefe I+D de la Dirección de Informática) y
especialistas en cada una de las áreas funcionales requeridas, provenientes de diversas
áreas de la empresa. El Comité Técnico fue encargado de la valoración y emisión de
recomendaciones para cada una de las etapas, y el Comité de Calificación el encargado de la toma de decisiones y eventual adjudicación del proceso.
Tabla 1. Estructura general del MC utilizado en el proceso
Subcaracterísticas
Atributos
Nivel 1 Nivel 2 Nivel 3 Derivados
1438
12
49
216
82
356
6
19
87
217
3
19
27
Tipo de Factor Total Factores
Funcionales
No Funcionales
No Técnicos
Atributos Básicos
Total Requeridos Obligatorios Deseables
1079
990 92%
- 0%
89 8%
244
183 75%
6 2%
55 23%
168
161 96%
- 0%
7 4%
4.1 Determinar los Requisitos de Partida
La estructura misma del MC sirve de guía para la elicitación de requisitos y su ingreso
en el modelo tal y como se describe en [13]. Destacamos que en nuestro proyecto se
consideraron las 27 subcaracterísticas que ocupan el segundo nivel del estándar
ISO/IEC 9126-1. Ello se debió a la naturaleza del proceso de selección, un concurso
público, que exigió ser especialmente cuidadoso con introducir en el pliego de condiciones todos aquellos requisitos que eventualmente pudieran tener la más mínima
influencia en la selección. En la Tabla 2 se muestra un extracto del resultado, donde
se puede ver algunos atributos, la métrica asociada (con especial uso del concepto de
métrica Nominal, como enumeración no ordenada de valores), y la expresión de los
requisitos como asignación de valores que las métricas pueden tomar.
Tabla 2. Atributos y requisitos asociados de la subcaracterística Ambiente Específico.
1
2
3
4
5
6
Atributo
Sistema operativo
cliente
Sistema operativo
del servidor
Bases de datos
soportadas
Lenguaje de
implementación
Interfaz cliente
Métrica
SO: Nominal; SO = (Windows XP,
Windows Vista, etc.)
SO: Nominal; SO = (Windows 2003,
Linux, etc.)
BD: Nominal; BD = (MS SQL Server
2005, Oracle, etc.)
Lenguaje: Nominal; Lenguaje = (.NET,
Java)
Interfaz: Nominal; Interfaz = (Web
browser, MS Terminal Server)
Requisito
Windows XP, Windows Vista
Características de
servidores
Componente: Set(Tuple (Compatible:
Nominal; Componente: Nominal; Descripción: String));
Compatible = (Sí, No), Componente =
(Servidor, Respaldo,…)
• (Sí, Servidor, “IBM TX SERIES 3650 procesadores XEON DUAL CORE”)
• (Sí, S.A.N., “IBM DS4300”)
• (Sí, Switches FC., “Conexión SAN con canal de
fibra redundante de 2Gbps”)
Windows 2003 Server
Oracle 10g
Java, .NET
Web Browser
4.2 Asignar Pesos y Prioridades a los Requisitos
Para el caso particular de selección que nos asiste, y debido a que el sistema ERP a
ser adquirido estaba enfocado principalmente a las áreas financiera y administrativa
de la empresa, se optó por el uso de una variante de las matrices de Leopold [21] (v.
Fig. 2). Esto se debe a que muchas de las personas interesadas y los usuarios finales
ya estaban familiarizadas con ellas, pues habían sido utilizadas en varios estudios en
la empresa. Si bien esto implicó una reducción en las capacidades de validación respecto a otras técnicas como AHP (v. [22] para un survey reciente), también facilitó la
incorporación de usuarios no técnicos en el proceso.
En el ejemplo de la Fig. 2 se muestra la repartición porcentual del 100% del puntaje del atributo Detalle de Documentos que Conforman la Cartera del Contrato, que
reside en el nivel 5 en el MC, en la posición 1.3.2.9.1, entre los 9 atributos más básicos que lo descomponen (1.3.2.9.1.1 a 1.3.2.9.1.9). Este proceso es replicado para
1.3.2.9.1.1
1.3.2.9.1.2
1.3.2.9.1.3
1.3.2.9.1.4
1.3.2.9.1.5
1.3.2.9.1.6
1.3.2.9.1.7
1.3.2.9.1.8
1.3.2.9.1.9
Peso
ponderado
Total
1.3.2.9.1.9
1.3.2.9.1.8
1.3.2.9.1.7
1.3.2.9.1.6
1.3.2.9.1.5
1.3.2.9.1.4
1.3.2.9.1.3
Descripción
Alto - Mayor
Medio
Bajo - Menor
1.3.2.9.1.2
Importancia
2
1
0,5
1.3.2.9.1.1
todos los niveles del MC, hasta que eventualmente todos los elementos que lo conforman hayan sido asignados un porcentaje relativo en relación al de su padre. El
porcentaje relativo de un atributo puede ser transformado a un peso relativo en relación a todos los elementos del MC, mediante simples multiplicaciones (p.e., si el peso
de 1.3.2.9.1 es 5 puntos, el de 1.3.2.9.1.4 será 5 × 0,05 = 0,25 puntos), una vez se
haya decidido el puntaje total sobre el que se evaluara la jerarquía.
1
1 2 1
1
1
1
1 9 12%
Números físicos de las facturas,sin cancelar
1
1 2 1
1
1
1
1 9 12%
Números internos de las facturas sin cancelar
1
1
2 1
1
1
1
1 9 12%
Fecha de emisión de los documentos
0,5 0,5 0,5
0,5 0,5 0,5 0,5 0,5 4
5%
Estado del documento
1
1
1 2
1
1
1
1 9 12%
Descripción del documento
2
1
1 2 2
1
1
1 11 14%
Forma de pago
Saldo actual de la factura
1
1
1 2 1
1
1
1 9 12%
Valores por mora
1
1
1 2 1
1
1
1 9 12%
Saldo total de la factura incluido interés por mora
1
1
1 2 1
1
1
1
9 12%
Totales 8,5 7,5 7,5 16 8,5 7,5 7,5 7,5 7,5 78 100%
Fig. 2: Uso de Matrices de Leopold en la asignación de pesos a los atributos de calidad (extracto).
En lo que se refiere a la priorización de los requisitos, fue realizada por el Comité
Técnico encargado de la primera fase del proceso y posteriormente validada en la
segunda fase por la Comisión de Calificación. Se decidió distinguir tres niveles: Obligatorios (no negociables), Requeridos (los desajustes pueden ser negociados por contrato para su implementación durante el proceso de consultoría por parte de los proveedores) y Deseables (son de interés para la empresa como un valor agregado, pero
su ausencia no afecta la operación de la misma). La proporción de cada tipo aparece
en la Tabla 1. Entre los obligatorios, citamos los incluidos en la Tabla 2 sobre el ambiente: la empresa tenía una plataforma de servidores, bases de datos y sistemas operativos que ya se encontraba en producción, así como personal debidamente capacitado en su instalación, configuración y mantenimiento. Por ello, con el objeto de reducir
costos de capacitación y personal especializado, se los marcó como no negociables.
4.3 Identificar los Objetivos de Evaluación de los Requisitos
Para identificar los objetivos de evaluación, utilizamos los factores de calidad incluidos en el MC a modo de checklist, e identificamos los objetivos aplicables a requisitos
de similar naturaleza y orden jerárquico. En particular, decidimos considerar las subcaracterísticas a nivel 2 del MC, y realizamos el análisis considerando sus atributos.
Los objetivos fijados se explican a continuación (v. Tabla 3 para los detalles):
ƒ Análisis de Riesgo. Para los directivos de la empresa adquiriente, la identificación
de riesgos de inversión era un objetivo fundamental; componentes provenientes de
proveedores sin experiencia previa, con equipos de consultores tercerizados, o sin
la suficiente solvencia económica y, productos con dudosa madurez o esquemas
de licenciamiento complejos, debían ser identificados y descartados de partida.
Tabla 3. Objetivos de evaluación para subcaracterísticas no técnicas a nivel 2.
Subcaracteristicas
1 Características del vendedor
1
Estructura de la compañía
2
Posicionamiento y fortaleza
Objetivo
Evaluacion
Análisis de Riesgo
Análisis de Riesgo
Directa
Directa
Descripción de la estructura de empresa proveedora
Detalle del posicionamiento y fortaleza de la empresa
Antigüedad de la empresa, certificaciones obtenidas y
recomendaciones emitidas sobre la msima.
Descripción de los servicios que ofrece la empresa
Descripción del los métodos de soporte que ofrece la
empresa
Detalle de las garantías de operación que se proveerán
Detalles del contrato de mantenimiento
Análisis de Costo
Análisis de Costo
Descripción del esquema de licenciamiento del producto
Estimación de precios por servicios ofertados
Análisis de Costo
Detalle del costo por plataforma de producción requerida
Análisis de Costo
Análisis de Costo
Análisis de Costo
Detalle del costo de implementación del producto
Detalle de costos adicionales por operación en la red
Detalle de costos adicionales por operación en la red
Detalle de costos adicionales de consultoria
(Hospedaje,Transporte, etc.)
3
Prestigio
4
Servicios Ofertados
Directa
5
Soporte
Directa
6
Garantías de ofertadas
7
Mantenimiento
2 Características económicas
1
Esquema de Licenciamiento
2
Precio estimado
Costo de plataforma de producción
3
requerida
4
Costos de implementación
5
Costos por operación en red
6
Costos mantenimiento
7
Otros costos de consultoría
3 Características del producto
1
Estabilidad
Descripcion
Análisis de Riesgo
Analisis de Costo
Análisis de Riesgo
2
Propiedad
Análisis de Riesgo
3
4
Entregables
Parametrización / Customizacion
Directa
Análisis de Riesgo
Características de estabilidad del producto
Características en relación a los derechos de propiedad
intelectual sobre el producto
Detalle de entregable
Detalle del proceso de parametrización
% Rel.
Punt.
20,00%
200
20,00%
200
20,00%
20,00%
200
200
20,00%
200
ƒ Análisis de Costos. Permitió calcular el costo inicial de adquisición, el costo total
de adopción, el retorno de inversión y la rentabilidad del proyecto.
ƒ Objetivos directos. El resto de subcaracterísticas incluidas en la Tabla 3 han generado objetivos directos (v. Sección 3.1), lo que significa que serán usados para
evaluar el objetivo implícito asociado a su naturaleza y categorización en el MC.
Destacamos que este tipo de requisitos tienen asignados peso relativo y puntaje de
evaluación, a diferencia de los citados en las viñetas anteriores, en las que un puntaje relativo podría no tener significado en función del objetivo de evaluación.
4.4 Definir el Orden y las Reglas de Análisis de los Requisitos.
Hemos basado esta actividad en la consideración de cuatro reglas básicas:
ƒ Puntajes totales asignados a los MCs: Dado que los puntajes de los factores de un
MC se calculan en base a los puntajes de los padres, es necesario determinar los
puntajes de los elementos de primer nivel en el árbol. Aunque el valor total en
puntos asignado a un modelo no tiene un significado por si solo, como regla general este puntaje debe ser los suficientemente alto como para facilitar su fraccionamiento a lo largo de los diversos niveles del modelo. Incluso diferentes factores de
primer nivel pueden tener un puntaje diferente reflejando su importancia. En nuestro caso, los puntajes totales fueron diseñados de tal forma que se premiara al
componente con mayor cobertura funcional (v. Tabla 4), y de esta manera se redujeran los tiempos y costos requeridos para la adaptación y puesta en producción en
el entorno empresarial así como el hipotético costo de posteriores consultorías.
ƒ Puntuación de los requisitos. Es necesario determinar la asignación de puntajes en
relación al cumplimiento parcial de los requisitos. Por ejemplo, la evaluación de
requisitos funcionales se realizó adoptando el esquema propuesto en [23] (v. Tabla
5). Este esquema premia a los productos que estén listos a utilizarse desde su entrega, reduciendo los tiempos y costos de consultoría.
Tabla 4. Puntajes totales asignados a diferentes tipos de atributos.
Ítem
1
2
3
Descripción
Puntaje Asignado
Atributos funcionales
X = 65 %
Atributos no funcionales
Y = 25 %
Atributos no técnicos correspondientes a objetivos de evaluación directa
Z = 10%
TOTAL X+Y+Z = 1000 Puntos
Tabla 5. Puntajes totales asignados a diferentes tipos de atributos.
Valor
Métrica
SOP
MOD
PER
TER
NS
Descripción
Soportado al entregarse (listo para utilizarse)
Soportado mediante modificaciones (reportes, personalización GUI, etc.)
Soportado mediante personalización (cambios al código fuente)
Soportado mediante la solución de un tercero
No soportado
Valoración
del Peso
100%
80%
40%
20%
0%
ƒ Asignación de puntajes en métricas multivaluados. Nos referimos a métricas cuyo
valor depende de varios factores. En nuestro proceso hemos encontrado dos casos:
(1) los atributos deben ser descompuestos para soportar requisitos mas atómicos
(caso 1 de Tabla 6); (2) la valoración requiere la interpretación por parte de los
evaluadores (caso 2 de Tabla 6), en la que el porcentaje de cumplimiento deberá
ser calculado mediante una función adicional, p.e. 2 componentes con Soportado =
Sí de los 4 requeridos, lo que es igual al 50%.
ƒ El esquema de toma de decisiones. En nuestro caso de estudio el esquema adoptado fue un esquema escalonado ya que así se redujo progresivamente el número de
candidatos, permitiendo que las etapas finales se centren en el análisis detallado de
los componentes más apropiados. Éste es un factor importante para trabajar con
componentes de granularidad gruesa como son los sistemas ERP.
ƒ El orden en el que los requisitos serán evaluados. Lo fundamental para los miembros del Comité de Evaluación fue el análisis de riesgos. El aspecto económico era
secundario sobre los aspectos técnicos, pero se buscaba garantizar que los objetivos de la inversión se cumplan rigurosamente en el corto, mediano y largo plazo.
Con esto en mente, el proceso de evaluación se condujo en cuatro etapas previas al
análisis económico de las propuestas: (1) análisis de riesgo de la inversión en base
a los atributos no técnicos establecidos para el efecto; (2) análisis de los atributos
Tabla 6. Ejemplos de manejo de atributos multivaluados.
Caso
1
2
Atributo
50,00%
Puntaje
según
peso
15,0
Deseable
20,00%
3,0
Deseable
20,00%
3,0
Sí
Deseable
20,00%
3,0
Sí
Requerido
20,00%
3,0
Sí
Opcional
12,00%
1,8
Sí
Opcional
8,00%
1,2
25,00%
1,5
Métrica
Requisito
Formatos de exportación
de datos soportados
XLS
Sí
PDF
Sí
Soportada: Nominal;
Soportada=(Sí, No)
Soportada: Nominal;
Soportada=(Sí, No)
CSV
Soportada: Nominal;
Soportada=(Sí, No)
XML
Soportada: Nominal;
Soportada=(Sí, No)
RTF
Soportada: Nominal;
Soportada=(Sí, No)
Formatos definidos por el Soportada: Nominal;
usuario
Soportada=(Sí, No)
Integracion con software Lista:(<Componente:Nominal,
de Microsoft
Soportada:Nominal,
Alcance:nominal>);
Componente=Etiqueta ( Word,
Excel, Project, etc.),
Soportada=Etiqueta(Sí,No),
Alcance=Texto(Descripción del
alcance)
<Excel, Sí, Salida de todos los reportes
y consultas en pantalla>,
<Word, Sí, Salida de todos los reportes
o datos que ameriten, Ej. contratos>,
<Outlook, Sí, Notificaciones de
procesos workflow, alarmas, etc.>,
<Project, Sí, Seguimiento de
presupuestos en proyectos>
Observaciones
Formatos de exportación de datos
soportados por el sistema
Prioridad
La emporesa mantiene un contrato Requerido
Enterprise Agreement con Microsoft,
por lo que se priorizará a productos
que faciliten una alta integración
con los componentes fabricados por
esa empresa, actualmente
licenciados a ETAPATELECOM.
Peso*
no técnicos con evaluación directa (servicios ofertados, garantías, etc.); (3) evaluación de la matriz de atributos no funcionales obligatorios (Ambiente Específico) y luego los restantes; (4) evaluación de la matriz de atributos funcionales.
ƒ Los criterios de aprobación de las etapas de evaluación. Destacamos:
- Los atributos no técnicos marcados con el objetivo de evaluación de riesgo,
fueron evaluados en base a su nivel de criticidad y etiquetados en una escala de
tres valores (bajo, medio, alto). La empresa se reservaba el derecho de descalificar las ofertas que como resultado de esta evaluación presentaran un índice
elevado de atributos etiquetados con riesgo alto. Para los atributos etiquetados
con riesgo medio, se debían proponer cláusulas contractuales que ayudaran a
eliminar sus potenciales detonantes o mitigar su impacto.
- En relación a los requisitos con objetivo de evaluación directa se definió un
puntaje mínimo con el cual debían aprobar cada etapa, 75% del peso total
asignado para los funcionales y 70% para los no funcionales y los no técnicos.
Se considero que un incumplimiento mayor al 25% en la cobertura funcional,
incrementaría excesivamente el costo y tiempo de adaptación del componente
al entorno y que por tanto no era conveniente para el mismo.
- Los atributos no técnicos marcados con objetivo de evaluación económica particularmente el precio total de la oferta, fueron evaluados con la metodología
del VAN (Valor Anual Neto), con una tasa de retorno del 12%.
4.5 Identificar, Analizar y Evaluar los Desajustes
Una vez completadas las cuatro primeras actividades del método WORMS, debe
iniciarse el proceso de evaluación de los componentes candidatos. Para esto se deben
describir sus características de calidad utilizando las métricas definidas para los factores de calidad incluidos en los MCs.
Una vez recibidas las descripciones de los proveedores, expresadas mediante una
hoja de cálculo (merced a una representación tabular del MC), el Comité Técnico
encargado de la revisión de las propuestas procedió a revisar y marcar los desajustes
identificados para cada componente candidato. Este proceso fue realizado de una
manera altamente sistemática (casi automática), pues los requisitos y los componentes
se encontraban descritos utilizando las mismas métricas, lo cual facilitó notablemente
su comparación. Una vez identificados los desajustes en relación a los requisitos, se
procedió en base a las reglas y propiedades del proceso descritas anteriormente: durante las etapas, se eliminaron candidatos por presentar situaciones de riesgo alto, por
dejar de proveer demasiados servicios fundamentales, por no alcanzar los puntajes
mínimos definidos, etc. Finalmente, a la etapa final llegaron dos componentes finalistas que obtuvieron una evaluación final del 96,98% y el 87,43% del puntaje respectivamente. Debido a esto ambos componentes aprobaron la etapa. Los desajustes respecto a los requisitos marcados como Requeridos, fueron debidamente marcados a fin
de verificar su correcta implementación durante el proceso de consultoría. Finalmente
en la etapa de evaluación económica, los productos fueron cotejados vs. el presupuesto estimado del proyecto y analizados, tal como se mencionó previamente, con la
metodología del VAN. Ambos componentes finalistas aprobaron la etapa al encontrase dentro del presupuesto referencial definido para el proceso.
4.6 Seleccionar los Componentes más Idóneos
Si bien la identificación de desajustes y el proceso de evaluación en sí, podrían ser
considerados más o menos directos (seguir el orden y las reglas definidas para el
proceso, identificar desajustes y emitir recomendaciones), la selección de los componentes más idóneos no lo es. No sólo que la adjudicación implicará que la empresa
deba vivir con las consecuencias de las decisiones que se tomen en el mismo, sino que
en procesos como el del ejemplo de estudio, podía implicar sanciones legales y
económicas a los miembros los equipos responsables del proceso.
Debido a ello en el caso de estudio se optó por la creación de los dos equipos de
evaluación descritos en la introducción de la sección 4. Si bien el Comité Técnico
tenía la responsabilidad de identificar desajustes y emitir recomendaciones sobre los
mismos, la decisión final sobre la selección recaía sobre la comisión de calificación.
Este esquema resultó útil en la práctica: permitió una doble validación de las recomendaciones a lo largo del proceso, la generación de consultas y la ampliación del
nivel de detalle de las recomendaciones del Comité Técnico, y eventualmente la revisión y corrección de errores que pudieran haberse identificado. Particularmente en el
caso del análisis de riesgos, la discusión generada entre el comité y la comisión permitió recategorizar la criticidad de algunos riesgos y definir acciones de mitigación
para los mismos.
Previa la adjudicación final se realizo una sumatoria de todas las calificaciones obtenidas por los candidatos finalistas (aquéllos que superaron todas las etapas de evaluación) en las diversas etapas (v. Tabla 4). La comisión de calificación decidió adjudicar el concurso al proveedor del producto con mayor cobertura funcional, que
además obtuvo el mayor puntaje en cada una de las etapas.
5 Conclusiones
En este trabajo se ha propuesto el método WORMS para dirigir la selección de componentes OTS. El método se basa en la identificación sistemática de desajustes entre
los requisitos y las características de los componentes usando un modelo de calidad
del dominio como elemento conductor. La característica principal del método es que
emerge de la práctica industrial, aplicando técnicas, heurísticas y documentos contrastados mediante selección de componentes de grano grueso, con lo que pretendemos
cubrir la reconocida distancia conceptual entre la teoría y la praxis en esta disciplina.
Como trabajo futuro, el método presupone actualmente que el proceso se divide en
dos fases diferenciadas (v. sección 3), lo que lo hace especialmente indicado para
procesos de selección dirigidos por pliegos de condiciones, pero es necesario estudiar
su adaptación a procesos más clásicos donde la obtención de requisitos y la evaluación de componentes se solapan en el tiempo. Asimismo, nos proponemos definir de
forma objetiva las condiciones idóneas de aplicabilidad de las diversas técnicas y
heurísticas presentadas, dependiendo de factores tales como: características del componente (granularidad, condiciones de licencia –COTS, FOSS, etc. –, ...), recursos
disponibles, criticidad de la selección para la organización, etc.
Referencias
1. Proceedings of the 7th International Conference on Composition-Based Software Systems
(ICCBSS’08), IEEE, 2008.
2. J. Li et al. “A State-of-the-Practice Survey of Risk Management in Development with Offthe-Shelf Software Components”. IEEE Transactions Software Engineering 34(2), 2008.
3. A. Mohamed, G. Ruhe, A. Eberlein. “COTS Selection: Past, Present, and Future”. CBSE
2007.
4. J. Kontio. “A case study in applying a systematic method for COTS selection”. ICSE 1996.
5. N. Maiden, C. Ncube. “Acquiring Requirements for COTS Selection”. IEEE Software
15(2), 1998.
6. M. Torchiano, M. Morisio. “Overlooked Aspects of COTS-Based Development”. IEEE
Software 21(2), 2004.
7. IEEE Std 1061-1998. IEEE Standard for a Software Quality Metrics Methodology, 1998.
8. L. Beus-Dukic, J. Bøegh. “COTS Software Quality Evaluation”. ICCBSS 2003.
9. A. Rawashdeh, B. Matalkah. “A New Software Quality Model for Evaluating COTS Components”. Journal of Computer Science 2(4), 2006.
10. M.F. Bertoa, A. Vallecillo. “Quality Attributes for COTS Components”. QAOOSE 2002.
11. T. Morris. “Revealing the ISO/IEC 9126-1 Clique Tree for COTS Software Evaluation”.
AIAA Infotech@Aerospace Conference and Exhibit, California, May 2007.
12. S. Kim, J. Park. “A Practical Quality Model for Evaluating Business Components”.
IASTED 2003.
13. X. Franch, J.P. Carvallo, “Using quality models in software package selection”. IEEE
Software, 20(1), 2003.
14. J.P. Carvallo, X. Franch, C. Quer. “Determining Criteria for Selecting Software Components: Lessons Learned”. IEEE Software 24(3), 2007.
15. C. Alves, X. Franch, J. P. Carvallo, A. Finkelstein. “Using Goals and Quality Models to
Support the Matching Analysis During COTS Selection”. ICCBSS 2005.
16. A. Mohamed, G. Ruhe, A. Eberlein. “Optimized mismatch resolution for COTS selection”.
Software Process: Improvement and Practice 13(2), 2008.
17. O. Mendez-Bonilla, X. Franch, C. Quer. “Requirements Patterns for COTS Systems”.
ICCBSS 2008.
18. ISO/IEC Standard 9126-1. Software Engineering – Product Quality – Part 1: Quality
Model, 2001.
19. J. P. Carvallo, X. Franch, C. Quer. “Managing Non-Technical Requirements in COTS
Components Selection”. RE 2006.
20. J. P. Carvallo, X. Franch, C. Quer. “Towards a Unified Catalogue of Non-technical Quality
Attributes to Support COTS-Based Systems Lifecycle Activities”. ICCBSS 2007.
21. L.R. Leopold et al. “A Procedure for Evaluating Environmental Impact”. US Geological
Survey Circular 645, United States Geological Survey, Washington, DC, 1971
22. E. Kornyshova, C. Salinesi. “MCDM Techniques Selection Approaches: State of the Art”.
International Journal of Information Technology and Intelligent Computing (IT&IC), May
2008.
23. Technology Evaluation. The ERP Evaluation Center. ERP Decision Hierarchy. Available
at http://www.erpevaluation.com/