SELECCIÓN DE COMPONENTES; OFF-THE-SHELF

Transcripción

1 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

2 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 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

3 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 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

4 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 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 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 SELECCIÓN DE COMPONENTES OTS

5 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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 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

6 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 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

7 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. detallado de una propuesta concreta, el estándar ISO/IEC , 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 seleccionar 4. 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 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 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).

8 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 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: Obtención de los requisitos del sistema En un primer paso, se decidieron los objetivos generales más importantes del sistema, v. fig (2 columnas de la izquierda) para una muestra 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

9 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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 El sistema debe ofrecer interfaces de usuario en múltiples idiomas El sistema debe definir diferentes tipos de usuario con sus propios derechos de acceso El sistema debe ser capaz de gestionar versiones de documentos El sistema debe mantener la privacidad de los datos sensibles El sistema debe reaccionar rápidamente a estímulos externos x x x x x x x x x x x x x x x x Figura Una muestra de los objetivos generales del caso del WMS 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

10 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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). CARACTERÍSTICAS Funcionalidad Usabilidad Eficie ncia SUBCARACTERÍSTICAS Nivel 1 Nivel 2 Definición de Procesos Adecuación Seguridad Capacidad para ser entendido Facilidad de aprendizaje... ATRIBUTOS Gestión de Tareas... Administración de reglas de notificación Tipos de notificación Organización y Notificaciones Monitorización de Procesos y Actividades Mecanismos de notificación Formato de notificación por Administración del modelo organizacional Reglas de sustitución Reglas de soporte Importación de directorios... Reportes... Proveedor de seguridad Protección de Datos Manejo de ACLs Parametrización de Interfaz Lenguajes de Interfaz Documentación y soporte Parametrización de Interfaz Capacidad para ser administrado Administración de Cuentas Comportamiento temporal Tiempo de Respuesta Protocolos de transmisión segura Servicios de certificación Algoritmos de encriptación Firmas electrónicas Soporte ACL Derechos de acceso Gestión de autorizaciones Restricciones de grupo (ver descomposición más abajo) Lenguajes de interfaz disponibles Etiquetas de texto modificables Soporte del vendedor a configuración del interfaz... Estándares 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 Conexión con otros directorios Tiempo estimado de trabajo de cada actividad

11 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. Tiempo medio para completar las tareas en una instancia de proceso Figura Esbozo del modelo de calidad para los WMS 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

12 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 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 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

13 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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 página de táreas mensaje (pantalla) página de táreas mensaje (pantalla) español español Lenguajes de Interfaz Disponibles Español, catalán e inglés catalán inglés catalán inglés... otros 13 idiomas... otros 27 idiomas Protocolos de Transmisión Segura SSL SSL SFTP SSL SFTP por rol Gestión de Autorizaciones Tan diversas como sea posible por usuario por grupo por rol por usuario por departamento Figura 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

14 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 (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

15 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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) 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

16 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 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 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

17 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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).

18 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. Figura 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).

19 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 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 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 2 SO servidor 3 BDs soportadas 4 Lenguaje de programación 5 Interfaz cliente SOcli: Nominal SOcli = (Windows XP, Windows Vista, Linux,...) SOserv: Nominal SOserv = (Windows 2003, Linux,...) BD: Nominal BD = (MS SQL Server 2005, Oracle,.) LP: Nominal LP = (.NET, Java,...) Interfaz: Nominal Interfaz = (Web browser, MS Terminal Server,...) Windows XP Windows Vista Windows 2003 Server Oracle 10g Java,.NET Web Browser Figura Ejemplos de requisitos sobre el modelo de calidad.

20 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. Importancia 2 Alto - Mayor 1 Medio 0,5 Bajo - Menor Descripción 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 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 4 5% Descripción del documento % Forma de pago % Saldo actual de la factura % Valores por mora % Saldo total de la factura incluido interés por mora % Totales 8,5 7,5 7,5 16 8,5 7,5 7,5 7,5 7, % Figura 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 ) Total Peso ponderado

21 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. 1 Proveedor Subcaracteristicas Objetivo Evaluacion 1 Estructura Organizacional Análisis de Riesgo 2 Posicionamiento y fortaleza Análisis de Riesgo Descripcion % Rel. Punt. Descripción de la estructura de la organización de la empresa del proveedor Descripción del nivel y orientación de la empresa del proveedor en el mercado 3 Reputación Análisis de Riesgo Reconocimiento 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% Soporte Directa Descripción de los mecanismos de soporte ofrecidos por la empresa del proveedor. 20,00% 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 Riesgo Descripció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% Costes de Licencia Análisis de Costo Descripció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 Costo Estimació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% Parametrización / Customizacion Análisis de Riesgo Descripción de el esfuerzo inicial requerido para preparar el producto para su puesta en explotación Figura 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,

22 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 ). 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.

23 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. Figura 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 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:

24 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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 AGRADECIMIENTOS Este trabajo ha sido parcialmente apoyado por el proyecto de investigación TIN subvencionado por el Ministerio de Ciencia e Innovación REFERENCIAS ALBERT, C. y BROWNSWORD, L. (2002). Meeting the Challenges of COTS Products. En: Procs. 1 st 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. 4 th International Conference on COTS-Based Software Systems (ICCBSS 05), LNCS 3412, Springer-Verlag.

25 CAPÍTULO 17: SELECCIÓN DE COMPONENTES; OFF-THE-SHELF. AYALA, C.P. y FRANCH, X. (2006). Domain Analysis for Supporting Commercial-Off-The-Shelf Components Selection. En: Procs. 25 th 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. 6 th 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. 2 nd 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. 1 st 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. 6 th 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. 14 th 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. 6 th 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).

26 CALIDAD DE PRODUCTO Y PROCESO SOFTWARE. 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. 15 th 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. 3 rd 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. 1 st 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. 8 th 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 2 nd 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. 2 nd 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. 30 th IEEE Euromicro Conference. INTERNATIONAL STANDARDS ORGANIZATION (2001). ISO/IEC Standard : Software Engineering Product Quality Part 1: Quality Model.