SELECCIÓN DE COMPONENTES; OFF-THE-SHELFfranch/papers/libro-calidad-cap-17-jpc-xf-10... · CALIDAD...

Versión preliminar

17Capítulo 17

SELECCIÓN DE COMPONENTES; OFF-THE-SHELF

Juan Pablo Carvallo

Xavier Franch

17.1 INTRODUCCIÓN La mayoría de sistemas de software actuales se construyen integrando

componentes de software de diferente naturaleza y orígenes. La existencia de un enorme y creciente mercado de componentes desarrollados por terceros ha hecho de esta tecnología “la” forma estándar de desarrollo de software. Estos componentes se denominan componentes OTS, de las siglas inglesas “Off-The-Shelf” (Li et al., 2008), aludiendo a su disponibilidad similar a la de un libro que está disponible en una estantería. Los componentes OTS pueden ser componentes comerciales, llamados componentes COTS, por “Commercial OTS” (Carney and Long, 2000); o software de código abierto, abreviados como OSS, por “Open Source Software” (Madanmohan and Rahul, 2004). Los componentes OTS, una vez personalizados, son integrados utilizando software desarrollado a medida, e incluyendo eventualmente capacidades de interacción con otros subsistemas ya existentes (p.e., sistemas legados).

Sin embargo, a pesar de sus beneficios potenciales (especialmente reducción de costes y tiempo de desarrollo), el diseño de software basado en componentes OTS también conlleva nuevos riesgos y retos para la Ingeniería de

CALIDAD DE PRODUCTO Y PROCESO SOFTWARE.

Software. Uno de sus procesos más críticos es el proceso de selección de componentes a ser integrados: si un componente es seleccionado erróneamente, el riesgo de fracaso de un proyecto se incrementa dramáticamente (Vitharana et al., 2003; Bhuta y Boehm, 2007). Los factores que afectan al proceso de selección son cuantiosos y muy variados, pudiendo ser de naturaleza funcional o técnica, pero también política o legal (Reifer et al., 2003).

En este capítulo nos centramos en el estudio de los procesos de selección de componentes OTS. Después de precisar qué entendemos por componente OTS y enumerar las actividades que tienen lugar en su presencia, nos centraremos en el proceso de selección, resumiendo algunas propuestas actuales. A continuación, discutiremos el uso de modelos de calidad del software en la selección de componentes. Seguidamente, incidiremos en un tipo particular de procesos de selección, los procesos conducidos por pliegues de condiciones. Acabaremos el capítulo con una breve discusión de los puntos más relevantes presentados.

17.2 TIPOS DE COMPONENTES OTS Un componente OTS se define como: “un producto software que está

disponible públicamente a un coste dado o con algunas obligaciones de licencias, que puede ser reusado e integrado en otras aplicaciones” (Torchiano y Morisio, 2004). Como hemos mencionado en la introducción, consideramos dos grandes tipos de componentes OTS, los componentes COTS y los OSS.

Según la definición seminal del Software Engineering Institute (SEI-CMU), un componente COTS es un componente de sofware que responde a las características siguientes: vendido, cedido o licenciado al público general; ofrecido por un vendedor que trata de obtener un provecho a partir de él; apoyado y evolucionado por el vendedor, que retiene los derechos; disponible en numerosas copias idénticas; usado sin modificación del código fuente (Brownsword et al., 2000). Algunos autores discuten alguna de estas características, por ejemplo Basili y Boehm (2001) consideran que incluso si las copias no son idénticas, hablamos de componentes COTS.

En contraposición, un componente OSS es servido no por un vendedor en el sentido clásico, sino por una comunidad de desarrolladores, que controla la evolución del código fuente, y que como filosofía de trabajo no sólo permite sino que promueve cambios y modificaciones (Madanmohan y Rahul, 2004).

Pese a estas diferencias, son mayores las similitudes y por ello es posible estudiarlos conjuntamente; de hecho, existen evidencias que apuntan a que los

CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF.

desarrolladores en general tienden a confundir ambos términos (Torchiano y Morisio, 2004).

Ambos tipos de componentes pueden ser de granularidad fina o de granularidad gruesa; ejemplos típicos de este segundo caso serían aplicaciones empresariales como sistemas ERP, sistemas CRM, etc. En los componentes de granularidad fina, la problemática reside principalmente en la integración de los diversos componentes, entre ellos y con otro software, para formar la solución. En el caso de componentes de granularidad gruesa, es frecuente que el sistema se base casi exclusivamente en el componente mismo, radicando la dificultad en su personalización, que puede ser un proceso que lleve varios meses, siendo las necesidades de integración parte de dicha personalización. Usualmente, la interacción de los componentes OTS con otros componentes y sistemas se realiza mediante APIs (abreviatura de “Application Programming Interface”) y/o mediante intercambios de datos según un formato determinado.

17.3 ACTIVIDADES DEL DESARROLLO DE SOFTWARE BASADO EN COMPONENTES OTS El desarrollo de software basado en componentes OTS difiere del

desarrollo clásico en la naturaleza y temporización de sus actividades. Existen diversos motivos para ello, entre otros:

• El proceso de obtención de requisitos debe realizarse considerando la oferta de componentes en el mercado. Estos componentes se habrán diseñado de acuerdo con una visión de negocio del fabricante (Potts, 1995) que en general no concordarán con los requisitos iniciales en un proyecto concreto.

• El proceso de negociación de los contratos ha de tener en cuenta las especificidades de los fabricantes y/o suministradores de los componentes.

• La evolución de la aplicación deja de estar bajo el control de la organización para la que se ha desarrollado el sistema. La irrupción de nuevos productos, o versiones de productos existentes, y la retirada de productos integrados en un sistema, responden a criterios de mercado o a las posibilidades del fabricante (Regnell et al., 2001), que pueden coincidir o no con las necesidades de la organización.

• Los componentes adquiridos presentan en el caso general interacciones con otras partes del sistema. Estas interacciones pueden ser de tipo diverso: la


necesidad de algún producto adicional para posibilitar la integración o mejorar el resultado del componente, la incompatibilidad con alguna versión instalada de un software existente, etc.

En respuesta a estas y otras necesidades, se han formulado diversos ciclos de vida específicos para el desarrollo de software basado en componentes OTS. En la fig. 17-1 se presenta el marco general propuesto por Albert y Brownsword (2002). Se aprecian cuatro grandes ámbitos que interaccionan continuamente: 1) los requisitos sobre el sistema representados por las necesidades y los procesos de negocio; 2) la oferta del mercado de componentes; 3) la gestión del proyecto; 4) la visión de la arquitectura (la necesidad de sincronizar los requisitos con la arquitectura del sistema es ampliamente reconocida en el ámbito de los componentes OTS, v. por ejemplo, Galster et al., 2007).

Figura 17.1. Actividades en el desarrollo de software basado en componentes OTS.

Esta figura general cristaliza en actividades, roles, artefactos, etc., que frecuentemente difieren de los correspondientes en el ciclo de vida clásico o, directamente, no encuentran tal correspondencia. Franch y Torchiano (2005) ofrecen un compendio de las actividades, roles y documentos más característicos relativos al desarrollo de software basado en componentes OTS. Otros autores presentan propuestas en la misma dirección. En todas ellas, existe un nexo de unión: la identificación de una actividad encargada de dirigir el proceso de selección de componentes.

17.4 SELECCIÓN DE COMPONENTES OTS


De acuerdo con Finkelstein et al. (1996), la selección de componentes comprende cuatro tareas: (1) adquisición y especificación de los requisitos; (2) identificación y comprensión de los componentes OTS disponibles en el mercado; (3) evaluación de los requisitos en los diversos componentes; (4) selección del “mejor” componente. Por supuesto, estas actividades no deben considerarse secuenciales, sino que se ejecutan de forma iterativa e incremental. Por ejemplo, la figura 17-2 (adaptada del método PORE citado más adelante) muestra claramente la relación entre la adquisición de requisitos y el análisis de componentes del mercado: cuando empieza el proceso de selección, se dispone de un gran número de componentes candidatos para satisfacer los pocos requisitos de partida que se consideran obligatorios. A medida que avanza el proceso, van descartándose componentes mientras aumenta el conocimiento del dominio y, por ello, aparecen nuevos requisitos. Finalmente, se selecciona el componente que satisface el conjunto final de requisitos, que como queda claro se ha obtenido incrementalmente.

Desde mediados de la década de los 90, se han propuesto una cantidad ingente de métodos para la selección de componentes OTS. Básicamente se pueden clasificar en dos grandes familias (v. Mohamed et al., 2007, para un estado del arte reciente):

Figura 17.2. Relación entre requisitos y componentes durante el proceso de selección.

• Métodos generales: pueden aplicarse en virtualmente cualquier proceso de selección de componentes OTS. Podemos citar, entre otros: OTSO (Kontyo, 1995), PORE (Maiden y Ncube, 1998), PECA (Comella-Dorda et


al., 2002), CARE (Chung y Cooper, 2004), STACE (Kunda, 2003), y un largo etcétera.

• Métodos específicos: de aplicabilidad sólo en un contexto dado. Citamos:

o Dependiente de la organización: por ejemplo, OPAL (Krystkowiak et al., 2004) y el método de Burgués et al. (2002).

o Dependiente del tipo de software: por ejemplo, middleware con i-Mate (Liu y Gorton, 2003) o sistemas ERP usando SHERPA (Pastor et al., 2002).

o Dependiente del dominio de la aplicación: por ejemplo, SCARLET (Maiden et al., 2002) para el dominio de las aplicaciones bancarias.

17.5 SELECCIÓN DE COMPONENTES BASADA EN MODELOS DE CALIDAD Pese a sus particularidades, todos los métodos de selección presentados en

la sección anterior comparten ciertos principios y actividades: 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 (Torchiano y Morisio, 2004; Li et al., 2008) 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 sea facilitada.

Uno de los artefactos que pueden usarse con este propósito son los modelos de calidad del software. Los modelos de calidad 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. Los conceptos básicos de los modelos de calidad y el análisis


detallado de una propuesta concreta, el estándar ISO/IEC 9126-1, aparece en el capítulo 10 de este mismo libro.

El uso de los modelos de calidad en los procesos de selección de OTS no es nuevo, entre las propuestas existentes podemos citar: Bertoa y Vallecillo (2002), Beus-Dukic y Bøegh (2003), Kim y Park (2003), Morris (2007), Rawashdeh y Matalkah (2006). Los autores de este capítulo han usado modelos de calidad para la selección de componentes OTS desde 2003 (Franch y Carvallo, 2003). En (Carvallo et al., 2006) se ofrece un resumen de las experiencias desarrolladas hasta esa fecha, pudiendo encontrarse algún caso adicional en (Carvallo et al., 2007).

La figura 17-3 muestra el detalle de utilización de modelos de calidad en los procesos de selección de software. Para simplificar la discusión, en la figura nos limitamos a la selección de un único componente. En este caso, se dispone de un modelo de calidad para el dominio del componente a seleccionar4. Dicho modelo de calidad puede construirse aplicando el método IQMC (Franch y Carvallo, 2003) sobre un catálogo genérico de factores de calidad, por ejemplo el modelo de calidad ISO/IEC 9126-1 extendido, tal y como se ha descrito en el capítulo 10 de este libro. La extensión precisa un procesamiento correcto del dominio del problema, aplicando los métodos y técnicas descritas por ejemplo en (Ayala y Franch, 2006).

Una vez obtenido, el modelo de calidad para el dominio juega el papel de ontología de referencia compartida entre los requisitos del sistema y el mercado de componentes OTS. Por lo que se refiere a los requisitos, éstos se formulan como restricciones aplicadas sobre los factores de calidad. En cuanto a los componentes, es necesario asignar valores a dichos factores. De este modo, el proceso de selección acaba siendo en esencia un ejercicio de comparación de las restricciones correspondientes a los requisitos, con las descripciones correspondientes a los componentes, combinando los resultados según alguna técnica de decisión, por ejemplo técnicas de decisión multi-criterio (v. Kornyshova y Salinesi, 2007, para una panorámica). Por supuesto, esta comparación puede ser, y será en el caso general, compleja, pero en todo caso la utilización de modelos de calidad la hace más sistemática.

17.6 EJEMPLO: SELECCIÓN DE UNA HERRAMIENTA DE GESTIÓN DE FLUJOS DE TRABAJO

4 No abordamos aquí la problemática de discernir el dominio adecuado, si no fuera sabido de antemano. El lector interesado puede consultar el trabajo (Carvallo et al., 2004b).


Como ejemplo de aplicación de los modelos de calidad, ofrecemos en esta sección unas pinceladas de una experiencia real de selección de una herramienta para la gestión de flujos de trabajo (para más detalles, v. Carvallo et al., 2004).

Figura 17.3. Visión general de la utilización de modelos de calidad en los procesos de

selección de software.

Los sistemas de gestión de flujos de trabajo (WMS de sus siglas en inglés, workflow management systems) proveen un apoyo automatizado a la activación, ejecución y coordinación de procesos de trabajo un contexto organizacional (Workflow Management Coalition, 1995). Su uso está actualmente extendido en todo tipo de contextos en que existan circuitos de procesamiento de datos claramente definidos. A continuación describimos los pasos que seguimos durante el proceso de selección:

17.6.1 Obtención de los requisitos del sistema En un primer paso, se decidieron los objetivos generales más importantes

del sistema, v. fig. 17-4 (2 columnas de la izquierda) para una muestra.

17.6.2 Conocimiento del dominio del problema El estudio de los WMS y la consideración de los objetivos generales del

sistema llevaron a la conclusión que, en realidad, el proceso de selección está involucrando varios dominios de software (i.e., tipos de componentes): el sistema de gestión de flujos propiamente dicho; un sistema de gestión documental (DMS de


sus siglas en inglés, document management systems); un sistema de gestión de contenidos (WCMS, por web content management system); y un paquete de adquisición de información (DI, por document imaging). La figura 17-4, en su parte derecha, muestra qué objetivos generales afectan a qué dominios.

ID Objetivo WMS DMS WCMS DI

1 El sistema debe capturar tanto documentos en

papel como electrónicos, en diferentes formatos

x x

2 El sistema debe definir y controlar

automáticamente el flujo de documentos x

3 El sistema debe visualizar documentos en la

web cuando así se le requiera x

4 El sistema debe ser fácil de configurar x x x x

5 El sistema debe ofrecer interfaces de usuario en

múltiples idiomas x x x x

6 El sistema debe definir diferentes tipos de usuario con sus propios derechos de acceso

x x x

7 El sistema debe ser capaz de gestionar

versiones de documentos x

8 El sistema debe mantener la privacidad de los

datos sensibles x x x x

9 El sistema debe reaccionar rápidamente a

estímulos externos x x x x

Figura 17.4. Una muestra de los objetivos generales del caso del WMS.

17.6.3 Modelos de calidad para los dominios Una vez identificados los 4 dominios, debe construirse un modelo de

calidad para cada uno de ellos. Este paso va a depender de la situación de partida y de las expectativas de futuro. Por lo que se refiere a la situación de partida, se puede disponer de algún modelo de experiencias anteriores, o se puede partir de cero. Por lo que se refiere a las expectativas, puede considerarse la necesidad en el


futuro de reaprovechar (parte de) algún modelo de calidad, o bien esta posibilidad no interesa, en cuyo caso no hay que invertir esfuerzos en el proceso más allá de los estrictamente necesarios. Por ejemplo, si nos focalizamos en el dominio de los WMS en concreto, el modelo obtenido sería similar al que se esboza en la figura 17-5 (por motivos de espacio se han omitido algunas subcaracterísticas intermedias así como las métricas asociadas a los factores).

SUBCARACTERÍSTICAS ATRIBUTOS

Nivel 1 Nivel 2

Definición de Procesos

...

Gestión de Tareas ... Administración de reglas de notificación Tipos de notificación Mecanismos de notificación Formato de notificación por e-mail Administración del modelo organizacional Reglas de sustitución Reglas de soporte

Organización y Notificaciones

Importación de directorios Monitorización de Procesos y Actividades

...

Adecuación

Reportes ... Proveedor de seguridad Protocolos de transmisión segura Servicios de certificación Algoritmos de encriptación

Protección de Datos

Firmas electrónicas Soporte ACL Derechos de acceso Gestión de autorizaciones

Funcionalidad

Seguridad

Manejo de ACLs

Restricciones de grupo Parametrización de Interfaz

(ver descomposición más abajo)

Lenguajes de interfaz disponibles Etiquetas de texto modificables

Capacidad para ser entendido Lenguajes de

Interfaz Soporte del vendedor a configuración del interfaz

Facilidad de aprendizaje

Documentación y soporte

...

Estándares de interfaz Parametrización de Interfaz Ofrecimiento de parametrización de interfaz

Usuarios individuales y grupos Cuentas públicas y privadas Directorios individuales y compartidos LDAP Autenticación única

Usabilidad

Capacidad para ser administrado Administración de

Cuentas

Conexión con otros directorios

CARACTERÍSTICAS

Eficie

ncia

Comporta-miento temporal

Tiempo de Respuesta

Tiempo estimado de trabajo de cada actividad


Tiempo medio para completar las tareas en una instancia de proceso

Figura 17-5. Esbozo del modelo de calidad para los WMS

17.6.4 Expresión de los requisitos en función de los factores de calidad Con los modelos de calidad ya disponibles, es posible expresar los

requisitos del sistema como restricciones sobre los atributos de calidad obtenidos. Por supuesto, esta etapa y la anterior, en realidad, pueden (y cuando sea posible, deben) desarrollarse simultáneamente, para asegurar que el modelo se va refinando en aquellas partes directamente relacionadas con los requisitos del problema (a no ser que se esté construyendo un modelo reutilizable). Eso sí, otra estrategia posible consiste en desarro-llar el modelo más allá de lo exigible por los requisitos, con la idea de explorar nuevos posibles requisitos pendientes de ser descubiertos, como se ilustra a continuación.

La casuística que nos podemos encontrar en esta etapa es diversa. Consideremos p.e. el objetivo 5, que condujo directamente a un atributo del modelo de calidad, Lenguajes de Interfaz Disponibles, perteneciente a la subcaracterística Lenguajes del Interfaz. Por ese motivo, se exploraron los otros atributos de tal subcaracterística para encontrar otras posibles necesidades. En concreto, se concluyó que los atributos Etiquetas de Texto Modificables y Soporte del Vendedor a Configuración del Interfaz eran de interés para el objetivo. Finalmente, los requisitos generados fueron “Los lenguajes soportados por el interfaz del sistema deben ser español, catalán e inglés” y “En caso de no existir el interfaz en alguno de estos lenguajes, o bien las etiquetas de texto son modificables, o bien el vendedor ofrece soporte a la configuración del interfaz”.

No todos los casos son tan simples. Consideremos por ejemplo:

• Existen objetivos muy abstractos que involucran muchos factores de calidad al ser refinados, como los objetivos 4 y 9. Su tratamiento exige la aplicación más o menos rigurosa de técnicas de especificación orientada a objetivos (van Lamsweerde, 2001).

• Una necesidad global a nivel de sistema afecta a diversos componentes de manera agregada. Por ejemplo, un requisito sobre el tiempo de procesamiento de una funcionalidad como la de incorporar un documento escrito en el sistema, afecta a diversos atributos referentes al tiempo de


respuesta y de proceso de los diversos componentes, incluyendo: la velocidad (rate) de captura de información por el componente DI; el tiempo de respuesta y la velocidad de proceso del componente DMS; la velocidad de publicación de datos del componente WCMS; y el tiempo de coordinación de todas estas actividades por parte del WMS. Aunque todos estos atributos pertenecen a modelos de calidad diferentes, están categorizados bajo las mismas subcaracterísticas, facilitando pues su unificación.

• Algunos atributos identificados a nivel individual en los modelos de calidad, pueden generar requisitos a nivel de sistema. Este es el ejemplo del atributo Autenticación Única (Single Sign-On), identificado en nuestro caso a nivel del componente WMS pero que se promovió a nivel de sistema.

17.6.5 Evaluación de los componentes OTS La existencia de los modelos de calidad facilita también la evaluación de

los diversos componentes del mercado que se consideran indicados. En este caso, como en muchos otros, un mismo componente puede cubrir varios de los roles asociados a los tipos de componentes identificados, p.e., un WMS puede incorporar funcionalidades de DMS. También cabe destacar que, como se promulga en la mayoría de métodos de selección mencionados anteriormente en este capítulo, es conveniente efectuar un filtrado de la oferta previo a la evaluación detallada de los componentes, por ejemplo considerando los requisitos críticos del sistema, que acostumbran a ser no-técnicos (Carvallo et al., 2006, 2007), para eliminar aquellos componentes OTS que directamente no los cumplan.

En la figura 17-6 ofrecemos un extracto de la evaluación de dos WMS comerciales. Puede observarse:

• Algunos atributos tienen el mismo valor en ambas herramientas. Por ejemplo, el atributo Mecanismos de Notificación al Usuario ofrecía la posibilidad de recibir notificaciones por e-mail o en la lista de cosas a hacer en la página de actividades del sistema, así como un simple aviso en la pantalla.

• Ocasionalmente, alguna herramienta ofrece un valor “mayor” que el establecido en los requisitos. Podemos verlo por ejemplo en el atributo Lenguajes de Interfaz Disponibles. Puede pasar que esta diferencia no sea relevante (como es el caso), también puede suceder que genere un requisito no previsto (como ocurrió con Protocolos de Transmisión Segura) o por el


contrario, que se considere pernicioso porque el “exceso” tiene un coste asociado (monetario, de mantenimiento, etc.).

Atributo Requisito Herramienta 1 Herramienta 2

Mecanismos de Notificación al Usuario

Tan diversos como sea posible

e-mail

página de táreas

mensaje (pantalla)

e-mail

página de táreas

mensaje (pantalla)

Lenguajes de Interfaz Disponibles

Español, catalán e inglés

español

catalán

inglés

... otros 13 idiomas

español

catalán

inglés

... otros 27 idiomas

Protocolos de Transmisión Segura

SSL SSL

SFTP

SSL

SFTP

Gestión de Autorizaciones

Tan diversas como sea posible

por rol

por usuario

por grupo

por departamento

por rol

por usuario

Figura 17.6. Evaluación de algunos atributos de calidad de dos WMS del mercado.

Los atributos realmente relevantes fueron aquéllos en que los componentes

comparados diferían significativamente. Es el caso del atributo Gestión de Autorizaciones: aunque ambos componentes comparados soportaban autorizaciones por rol y por usuario, el primer componente

17.7 LECCIONES APRENDIDAS Después de nuestras experiencias en el ámbito de proyectos de selección de

software, hemos recopilado una serie de lecciones aprendidas que pueden ser de interés para aquellos desarrolladores que se vean implicados en este tipo de


procesos de selección y decidan usar modelos de calidad para guiarlos. Algunas de estas lecciones aparecen en (Carvallo et al., 2007b):

• Adopción de un catálogo equilibrado de factores de calidad. Recomendamos adoptar un catálogo general de partida con pocos factores, que se vaya extendiendo de acuerdo a las necesidades de la organización en sucesivos proyectos. En nuestro caso, el estándar ISO/IEC 9126-1 (2001) ha sido un buen punto de partida, que hemos enriquecido tal y como se explica en el capítulo 10 del presente libro.

• Reconocimiento de la importancia de los factores no-técnicos. Uno de los inconvenientes más importantes de muchos modelos de calidad es soslayar los aspectos no-técnicos (sobre proveedor, licencias, etc.), que en la selección juegan un papel fundamental (Carvallo et al., 2006). Recomendamos introducir estos aspectos en el catálogo de factores y unificar su tratamiento con los técnicos durante el proceso de selección.

• Definición precisa del marco de selección. Recomendamos determinar con claridad los roles, tareas y documentos involucrados en el proceso, así como la estructura misma de los componentes de los modelos de calidad, tanto los factores como las métricas. El uso de un glosario también juega un papel importante dentro del equipo de selección.

• Decisión sobre el grado de reutilización del modelo. En una organización determinada, un proceso de selección puede ser una actividad ocasional y esporádica, o bien puede ser uno de tantos proyectos de la misma índole. Dependiendo de este hecho, el modelo de calidad que sirve de base se contemplará como un artefacto reutilizable o no. Recomendamos discernir la necesidad de reutilización antes de construir el modelo, pues la forma final del mismo, y el esfuerzo dedicado a su diseño, dependerá en última instancia de este hecho.

• Consideración de las dependencias entre componentes. Como ha mostrado el ejemplo de la sección anterior, los componentes OTS raramente actúan aisladamente, sino que deben interaccionar con otros componentes y subsistemas. Recomendamos establecer explícitamente estas dependencias, pero con énfasis en las dependencias de alto nivel y no tanto en consideraciones más operativas (p.e., estándares de intercambio de datos), que se tratarán a otro nivel.

• Uso de notaciones comprensibles por la mayoría de personal implicado. Los modelos de calidad son artefactos de naturaleza técnica por lo que su


estructura debe ser descrita con rigor. No obstante, hay que evitar formalismos innecesarios que puedan dificultar su comprensión. Asimismo, es conveniente que su estructura pueda ser eventualmente mostrada a personal con otro tipo de perfil. En nuestras experiencias, hemos usado profusamente UML y también una notación orientada a objetivos (el lenguage i* diseñado por Eric Yu, 1995) para mostrar las dependencias mencionadas en el ítem anterior.

• Uso (o desarrollo) de herramientas de soporte. Hemos constatado que, por sencillo que sea el proceso de selección a realizar, su ejecución va a precisar rápidamente de docenas, incluso centenares, de entidades a manejar: factores de calidad, métricas, términos de glosario, evaluaciones, etc. Recomendamos disponer de alguna herramienta de soporte a toda esta información, más allá de una simple hoja de cálculo (que puede ser un buen elemento para obtener vistas, pero no para conducir el proceso), ya sea una aplicación centrada en una base de datos (Kitchenham et al., 2001), ya sea una aplicación con lógica de negocio orientada a los procesos de selección (Grau et al., 2004).

17.8 UN CASO PARTICULAR: PROCESOS DE SELECCIÓN DIRIGIDOS POR PLIEGOS DE CONDICIONES La práctica totalidad de métodos de selección enumerados en este capítulo

se basan en un escenario en que el equipo técnico en cargo de la selección interacciona constantemente con otros actores (la organización en cargo, distribuidores de componentes, etc.) en pos de la solución final. Si bien esta situación es muy común, no cubre un escenario particular que por su importancia estratégica y volumen de negocio merece mención especial: los procesos de selección dirigidos por pliegos de condiciones (en inglés, call-for-tender

processes).

Los procesos de selección dirigidos por pliegos de condiciones son procesos basados en invitaciones, principalmente conducidos por organizaciones públicas que establecen una lista predefinida de requisitos a cumplir. Estos requisitos pueden ser muy precisos, o pueden eventualmente dejar lugar a un proceso de negociación, aunque mientras mayor sea el margen, más complicado será el proceso de selección y redacción de contratos. Por motivos de transparencia, la legislación de muchos países requiere que el conjunto de documentos que ha de conducir el proceso (no sólo requisitos, sino también método de evaluación, modalidades de pago, etc.) sea hecho público con anterioridad al inicio del


concurso mismo. Incluso si la legislación lo permite, la modificación de cualquiera de esos documentos puede llegar a ser una tarea tediosa.

En resumen, los procesos de selección dirigidos por pliegos de condiciones se caracterizan por: (1) generalmente, tienen lugar en la administración pública; (2) la transparencia de las decisiones debe ser lo mayor posible; (3) involucran componentes OTS de granularidad gruesa (p.e., sistemas ERP o CRM); (4) como resultado, su impacto en la organización puede ser muy grande (y en consecuencia, la importancia estratégica de su correcta selección, enorme).

En la figura 17-7 se visualiza la diferencia entre la dinámica de los dos tipos de proceso de selección, comparando la adquisición de requisitos con la evaluación de componentes de la misma manera que se hacía en la figura 17-2. Podemos comprobar que en este caso, los requisitos se adquieren totalmente con anterioridad a la evaluación de componentes. Como resultado, este tipo de procesos tiene su propio tipo de riesgos que deben gestionarse adecuadamente (v. por ejemplo Lauesen y Vium, 2005).

Figura 17.7. Relación entre requisitos y componentes durante el proceso de selección

dirigido por pliegos de condiciones.

El método WORMS para dirigir procesos de selección dirigidos por pliegos de condiciones

Pese a la diferencia comentada, en nuestra experiencia los modelos de calidad siguen siendo un vehículo apropiado para dirigir procesos de selección de este tipo. Como resultado de tales experiencias, hemos definido el método WORMS (del inglés, Weigths, Objectives, Rules, Mismatches and Selection) para


la selección de componentes OTS en procesos de selección dirigidos por pliegos de condiciones. WORMS se basa en la utilización de modelos de calidad 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 modelos de calidad 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 modelos de calidad a modo de restricciones sobre los factores de calidad, usando las métricas propuestas para los mismos.

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 (ver figura 17-8).


Figura 19.8. El método WORMS para la ejecución de procesos de selección basados en

pliegos de condiciones (call-for-tender).

Fase I: Elaboración del modelo de requisitos

El modelo de requisitos se construirá en base al modelo de calidad 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 modelo, en caso contrario podríamos aplicar el método IQMC (v. capítulo 10 de este mismo libro) 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 modelo de calidad sirve como guía para determinar los requisitos. Para cada factor de calidad del modelo de calidad, 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 (vigilando en caso de ser un grafo, no marcar factores que puedan estar involucrados en otros factores que sí sean relevantes). Si es de interés, se determina el requisito apropiado para dicho factor y la métrica que se utilizará para medirlo (v. fig. 17-9 para algunos ejemplos). Eventualmente, si faltara algún atributo, se añadiría y descompondría tal y como establece el método IQMC. Esta información queda asociada a los factores del modelo de calidad, de manera que los requisitos quedan organizados de la misma manera que el modelo de calidad. 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 de manera similar a como se propone en (Renault et al., 2009).

Atributo Métrica Requisito

1 SO cliente

SOcli: Nominal

SOcli = (Windows XP, Windows Vista, Linux, ...)

Windows XP

Windows Vista

2 SO servidor SOserv: Nominal

SOserv = (Windows 2003, Linux, ...) Windows 2003 Server

3 BDs soportadas

BD: Nominal

BD = (MS SQL Server 2005, Oracle, ….) Oracle 10g

4 Lenguaje de programación

LP: Nominal

LP = (.NET, Java, ...) Java, .NET

5 Interfaz cliente

Interfaz: Nominal

Interfaz = (Web browser, MS Terminal Server, ...)

Web Browser

Figura 17.9. Ejemplos de requisitos sobre el modelo de calidad.


Importancia Descripción

2 Alto - Mayor

1 Medio

0,5 Bajo - Menor

1.3.2.9.1.1 1 1 2 1 1 1 1 1 9 12%

1.3.2.9.1.2 1 1 2 1 1 1 1 1 9 12%

1.3.2.9.1.3 1 1 2 1 1 1 1 1 9 12%

1.3.2.9.1.4 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 4 5%

1.3.2.9.1.5 1 1 1 2 1 1 1 1 9 12%

1.3.2.9.1.6 2 1 1 2 2 1 1 1 11 14%

1.3.2.9.1.7 1 1 1 2 1 1 1 1 9 12%

1.3.2.9.1.8 1 1 1 2 1 1 1 1 9 12%

1.3.2.9.1.9 1 1 1 2 1 1 1 1 9 12%

8,5 7,5 7,5 16 8,5 7,5 7,5 7,5 7,5 78 100%

Saldo actual de la factura

Valores por mora

Saldo total de la factura incluido interés por mora

Totales

1.3

.2.9

.1.1

1.3

.2.9

.1.2

Números físicos de las facturas,sin cancelar

Números internos de las facturas sin cancelar

Fecha de emisión de los documentos

Estado del documento

Descripción del documento

Forma de pago

1.3

.2.9

.1.7

1.3

.2.9

.1.8

1.3

.2.9

.1.9

To

tal

Peso

po

nd

era

do

1.3

.2.9

.1.3

1.3

.2.9

.1.4

1.3

.2.9

.1.5

1.3

.2.9

.1.6

Figura 17.10. Ejemplos de asignación de pesos utilizando una matriz cuadrada.

• 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:

o Objetivos directos. Los factores de calidad determinan objetivos por sí 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 modelo de calidad), más factores (y por ende, requisitos) se encuentran implicados en el objetivo.

o 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.

Una buena forma de conducir la identificar los objetivos de evaluación, consiste en utilizar los factores incluidos en el modelo de calidad a modo de checklist, e identificar los objetivos aplicables a requisitos de similar naturaleza y orden jerárquico, por ejemplo considerando alguna de las capas de subcaracterísticas (v. fig. 17-11).


Objetivo

EvaluacionDescripcion % Rel. Punt.

1 Proveedor

1 Estructura Organizacional Análisis de RiesgoDescripción de la estructura de la organización de la empresa del

proveedor

2 Posicionamiento y fortaleza Análisis de RiesgoDescripción del nivel y orientación de la empresa del proveedor en el

mercado

3 Reputación Análisis de RiesgoReconocimiento de la capacidad del proveedor de realizar proyectos

similares basado en certificaciones y experiencias pasadas

4 Servicios Ofertados Directa Descripción de los servicios ofrecidos por el proveedor 20,00% 200

5 Soporte DirectaDescripción de los mecanismos de soporte ofrecidos por la empresa del

proveedor.20,00% 200

2 Negocio

1 Esquema de Licencia Análisis de Costo Descripción de las opciones de licencia posibles para el producto

2 Propiedad Análisis de RiesgoDescripción de aspectos relacionados con los derechos de propiedad

intelectual del producto

3 Garantías Directa Detalle de las garantías que se ofrece para el producto 20,00% 200

4 Costes de Licencia Análisis de CostoDescripción de los costes de los componentes del producto, y el coste

total de propiedad según los tipos de licencia disponibles

5 Costes de plataforma Análisis de Costo Estimación de costes para la plataforma de explotación requerida

6 Costes de implementación Análisis de CostoEstimación de los costes de implantación del producto basada en

anteriores experiencias.

7 Coste de red Análisis de Costo Estimación de los costes adicionales para la operación de red

3 Producto

1 Historia Análisis de Riesgo Evolución del producto desde que apareció en el mercado

2 Entregables Directa Detalle de los entregables que se ofrecen una vez implantado el producto 20,00% 200

3 Parametrización / Customizacion Análisis de RiesgoDescripción de el esfuerzo inicial requerido para preparar el producto para

su puesta en explotación

Subcaracteristicas

Figura 17-11. Objetivos de evaluación para subcaracterísticas no técnicas a nivel 2.

• 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 por las que los requisitos serán evaluados. Podemos citar, entre otras: puntajes totales asignados a los modelos de calidad; puntajes asignados a los requisitos individuales; puntajes asigandos en métricas multivaluadas; esquema de toma de decisiones; orden de evaluación; y criterios de aprobación de las etapas de evaluación.

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.

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:

• 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 modelos de calidad, 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 (Alves et al., 2005): 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 (v. fig. 17-12). 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 por etapas, 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.


Figura 17-12. Identificación de desajustes utilizando modelos de calidad.

• 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. Para ello, se deberán considerar las reglas de evaluación definidas para el proceso, y los puntajes totales computados en cada etapa del proceso.

17.9 CONCLUSIONES En este capítulo hemos abordado la problemática de la selección de

componentes Off-The-Shelf (OTS). Después de una presentación general de conceptos y enumeración de aproximaciones existentes, hemos estudiado en profundidad la forma que toma un proceso de selección basado en modelos de calidad. Los modelos de calidad ofrecen catálogos estructurados de factores de calidad, junto con sus métricas, y al fin y al cabo éstos son los dos conceptos fundamentales en la selección de componentes OTS: factores, para identificar los criterios de selección relevantes; métricas, para evaluarlos en los distintos componentes candidatos. Hemos ilustrado la propuesta con una experiencia industrial de selección de una herramienta de gestión de flujos de trabajo, y hemos enumerado las lecciones aprendidas más relevantes en este contexto.

La utilización de modelos de calidad en la selección puede ser de utilidad en diversos escenarios de uso, por ejemplo:


• Para conducir ofertas públicas por pliegos de condiciones, tal y como hemos estudiado en detalle en este capítulo. Los factores de calidad del modelo se utilizan para guiar el proceso de obtención y documentación de los requisitos. Las métricas se utilizan en el proceso de evaluación de los candidatos.

• Para proyectos aislados de selección. Aquellas organizaciones sin experiencia en el campo pueden beneficiarse del uso de este tipo de artefactos, altamente estructurados, y para los que podemos encontrar gran cantidad de propuestas fácilmente consultables (entre ellas, en el capítulo 10 de este mismo libro).

• Para organizaciones de IT que proveen de soporte continuado a este tipo de procesos. Por naturaleza, los modelos de calidad son artefactos altamente reusables, y si se explota esta característica es posible reutilizar conocimiento de diverso tipo (factores, métricas, evaluaciones, etc.) de un proyecto a otro.

Una línea de investigación futura es la exportación del conocimiento obtenido en en el ámbito de la selección de COTS, al campo de la selección de servicios web (Papazoglou, 2008). Si bien los servicios web podrían simplemente considerarse como un tipo particular de componente OTS, lo cierto es que existen particularidades que aconsejan no hacerlo así. En el campo concreto de la selección de OTS, existe la noción de descubrimiento de servicios web que en cierta manera cumple la misma función.

17.10 AGRADECIMIENTOS Este trabajo ha sido parcialmente apoyado por el proyecto de investigación

TIN2007-64753 subvencionado por el Ministerio de Ciencia e Innovación.

17.11 REFERENCIAS ALBERT, C. y BROWNSWORD, L. (2002). “Meeting the Challenges of

COTS Products”. En: Procs. 1st International Conference on COTS-Based Software Systems (ICCBSS’02), LNCS 2255, Springer-Verlag.

ALVES, C., FRANCH, X., CARVALLO, J.P. y FINKELSTEIN, A. (2005). “Using Goals and Quality Models to Support the Matching Analysis during

COTS Selection”. En: Procs. 4th International Conference on COTS-Based Software Systems (ICCBSS’05), LNCS 3412, Springer-Verlag.


AYALA, C.P. y FRANCH, X. (2006). “Domain Analysis for Supporting Commercial-Off-The-Shelf Components Selection”. En: Procs. 25th International Conference on Conceptual Modeling (ER’06), LNCS 4215, Springer-Verlag.

BASILI, V. y BOEHM, B. (2001). “COTS-Based Systems Top 10 List”. En: IEEE Computer, 34(5).

BERTOA, M.F. y VALLECILLO, A. (2002). “Quality Attributes for COTS Components”. En: Procs. 6th International Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE’02).

BEUS-DUKIC, L. y BØEGH, J. (2003). “COTS Software Quality Evaluation”. En: Procs. 2nd International Conference on COTS-Based Software Systems (ICCBSS’03), LNCS 2580, Springer-Verlag.

BROWNSWORD, L., OBERNDORF, T. y SLEDGE, C.A. (2000). “Developing New Processes for COTS-Based Systems”. En: IEEE Software, 17(4).

BURGUÉS, X., ESTAY, C., FRANCH, X., PASTOR, J.A. y QUER, C. (2002). “Combined Selection of COTS Components”. En: Procs. 1st International Conference on COTS-Based Software Systems (ICCBSS’02), LNCS 2255, Springer-Verlag.

BHUTA, J. y BOEHM, B. (2007). “Attribute-Based COTS Product Interoperability Assessment”. En: Procs. 6th IEEE International Conference on COTS-Based Software Systems (ICCBSS’07).

CARNEY, D. y LONG, F. (2000). “What do you mean by COTS? Finally,

a useful Answer”. En: IEEE Software, 17(2).

CARVALLO, J.P., FRANCH, X., y QUER, C. (2006). “Managing Non-

Technical Requirements in COTS Components Selection”. En: Procs. 14th IEEE International Requirements Engineering Conference (RE’06).

CARVALLO, J.P., FRANCH, X. y QUER, C. (2007). “Towards a Unified Catalogue of Non-technical Quality Attributes to Support COTS-Based Systems

Lifecycle Activities”. En: Procs. 6th IEEE International Conference on COTS-Based Software Systems (ICCBSS’07).

CARVALLO, J.P., FRANCH, X. y QUER, C. (2007b). “Determining Criteria for Selecting Software Components: Lessons Learned”. En: IEEE Software, 24(3).


CARVALLO, J.P., FRANCH, X., QUER, C. y RODRÍGUEZ, N. (2004). “A Framework for selecting Workflow Tools in the Context of Composite

Information Systems”. En: Procs. 15th International Conference Database and Expert Systems Applications (DEXA’04), LNCS 3180, Springer-Verlag.

CARVALLO, J.P., FRANCH, X., QUER, C. y TORCHIANO, M. (2004b). “Characterization of a Taxonomy for Business Applications and the Relationships among them”. En: Procs. 3rd International Conference on COTS-Based Software Systems (ICCBSS’04), LNCS 2959, Springer-Verlag.

CHUNG, L. y COOPER, K. (2004). “Defining Goals in a COTS-Aware Requirements Engineering Approach”. En: Systems Engineering Journal, 7(1), Wiley.

COMELLA-DORDA, S., DEAN, J., MORRIS, E. y OBERNDORF, P. (2002). “A Process for COTS Software Product Evaluation”. En: Procs. 1st International Conference on COTS-Based Software Systems (ICCBSS’02), LNCS 2255, Springer-Verlag.

FINKELSTEIN, A., SPANOUDAKIS, M. y RYAN, M. (1996). “Software Package Requirements and Procurement”. En: Procs. 8th IEEE International Workshop on Software Specification and Design (IWSSD’96).

FRANCH, X. y CARVALLO, J.P. (2003). “Using Quality Models in

Software Package Selection”. En: IEEE Software, 20(1).

FRANCH, X. y TORCHIANO, M. (2005). “Towards a Reference Framework for COTS-Based Development: A Proposal”. En: Procs 2nd International Workshop on Models and Processes for the Evaluation of COTS Components (MPEC’05).

GALSTER, M., EBERLEIN, A. y MOUSSAVI, M. (2007). “Matching

Requirements with Off-the-shelf Components at the Architectural Level”. En: Procs. 2nd International OTS-Based Development Methods Workshop (IOTSDM'07).

GRAU, G., CARVALLO, J.P., FRANCH, X. y QUER, C. (2004). “DesCOTS: A Software System for selecting COTS Components”. En: Procs. 30th IEEE Euromicro Conference.

INTERNATIONAL STANDARDS ORGANIZATION (2001). “ISO/IEC Standard 9126-1: Software Engineering – Product Quality – Part 1: Quality

Model”.


KIM, S. y PARK, J. (2003). “A Practical Quality Model for Evaluating

Business Components”. En: Proceedings of IASTED International Conference on Software Engineering (IASTED’03), Acta Press.

KITCHENHAM, B., HUGHES, R.T. y LINKMAN, S.G. (2001). “Modeling Software Measurement Data”. En: IEEE Transactions on Software Engineering, 27(9).

KONTYO, J. (1996). “A Case Study in Applying a Systematic Method for

COTS Selection”. En: Procs 18th ACM/IEEE International Conference on Software Engineeering (ICSE’96).

KORNYSHOVA, E. y SALINESI, C. (2007). “MCDM Techniques

Selection Approaches: State of the Art”. En: IEEE Symposium on Computational Intelligence in Multicriteria Decision Making (MCDM’07).

KRYSTKOWIAK, M., BÉTRY, V. y DUBOIS, E. (2004). "Efficient COTS Selection with OPAL Tool”. En: Procs. 1st International Workshop on Models and Processes for the Evaluation of COTS Components (MPEC’04).

KUNDA, D. (2003). “STACE: Social Technical Approach to COTS Software Evaluation”. En: Component-Based Software Quality - Methods and Techniques, LNCS 2693, Springer-Verlag.

LAUESEN, S. y VIUM, J. (2005). “Communication Gaps in a Tender Process”. En: Requirements Engineering Journal, 10(4), Springer-Verlag.

LI, J., CONRADI, R., SLYNGSTAD, O.P.N., TORCHIANO, M., MORISIO, M. y BUNSE, C. (2008). “A State-of-the-Practice Survey of Risk Management in Development with Off-the-Shelf Software Components”. En: IEEE Transactions on Software Engineering, 34(2).

LIU, A. y GORTON, I. (2003). “Accelerating COTS Middleware

Acquisition: the i-Mate Process”. En: IEEE Software, 20(2).

MADANMOHAN, T.R. y RAHUL, D. (2004). “Open Source Reuse in Commercial Firms”. En: IEEE Software, 21(6).

MAIDEN, N.A.M., CROCE, V., KIM, H., SAJEVA, G. y TOPUZIDOU, S. (2003). ”SCARLET: Integrated Process and Tool Support for Selecting Software Components”. En: Component-Based Software Quality - Methods and Techniques, LNCS 2693, Springer-Verlag.


MAIDEN, N.A.M. y NCUBE, C. (1998). “Acquiring Requirements for COTS Selection”. En: IEEE Software, 15(2).

MOHAMED, A., RUHE, G. y EBERLEIN, A. (2007). “COTS Selection: Past, Present, and Future”. En: Procs. 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS’07).

MORRIS, T. (2007). “Revealing the ISO/IEC 9126-1 Clique Tree for COTS Software Evaluation”. En: AIAA Infotech@Aerospace Conference and Exhibit.

PAPAZOGLOU, M.P. (2008). “Web Services: Principles and

Technology”. Prentice-Hall.

PASTOR, J.A., FRANCH, X. y SISTACH, F. (2002). “Methodological

ERP Acquisitions: the SHERPA Experience”. En: The Guide to IT Service Management, vol I, Addison-Wesley.

POTTS, C. (1995). “Invented Requirements and Imagined Customers”. En: Procs. 2nd IEEE International Symposium on Requirements Engineering (ISRE’95).

RAWASHDEH, A. y MATALKAH, B. (2006). “A New Software Quality Model for Evaluating COTS Components”. En: Journal of Computer Science, 2(4), Science Publications.

REGNELL, B., HÖST, M., OCH DAG J.N., BEREMARK, P. y HJELM, T. (2001). “An Industrial Case Study on Distributed Prioritisation in Market-

Driven Requirements Engineering for Packaged Software”. En: Requirements Engineering Journal, 6(1), Springer-Verlag.

REIFER, D., BASILI, V. R., BOEHM, B.W. y CLARK, B. (2003). “Eight Lessons Learned during COTS-Based Systems Maintenance”. En: IEEE Software, 20(5).

RENAULT, S., MÉNDEZ, O., FRANCH, X. y QUER, C. (2009). “PABRE: Pattern-Based Requirements Elicitation”. En: Procs. 3rd IEEE International Conference on Research Challenges in Information Science (RCIS’09).

TORCHIANO, M. y MORISIO, M. “Overlooked Aspects of COTS-Based Development”. En: IEEE Software, 21(2).


VITHARANA, S., ZAHEDI, F. y JAIN, H. (2003). “Design, Retrieval, and Assembly in Component-Based Software Development”. En: Communications of ACM, 46(11).

VAN LAMSWEERDE, A. (2001). “Goal-oriented Requirements

Engineering: A Guided Tour”. En: Procs. 5th IEEE International Symposium on Requirements Engineering (ISRE’01).

WORKFLOW MANAGEMENT COALITION (1995). “The Workflow

Reference Model”. TC-00-1003, accessible en http://www.wfmc.org.

YU, E. (1995). “Modelling Strategic Relationships for Process

Reengineering”. Tesis doctoral, Univ. de Toronto, 1995.

SELECCIÓN DE COMPONENTES; OFF-THE-SHELFfranch/papers/libro-calidad-cap-17-jpc-xf-10... · CALIDAD...

Documents

Transcript of SELECCIÓN DE COMPONENTES; OFF-THE-SHELFfranch/papers/libro-calidad-cap-17-jpc-xf-10... · CALIDAD...