SciELO - Scientific Electronic Library Online

 
 número17EmoRemSys: Sistema de recomendación de recursos educativos basado en detección de emocionesMejoras del proceso endoscópico usando aplicaciones móviles índice de autoresíndice de assuntosPesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

versão impressa ISSN 1646-9895

RISTI  no.17 Porto mar. 2016

https://doi.org/10.17013/risti.17.96-114 

ARTÍCULOS

Evaluando Adecuación Funcionaly Usabilidad en Herramientas de Composición desde la Perspectiva del Usuario Final

Evaluating Functional Appropriateness and Usability of Composition Tools from an End-User Perspective

Yadira Jarvio Hernández1, Perla Velasco-Elizondo2 y Edgard Benítez-Guerrero1

 

1 Universidad Veracruzana, Facultad de Estadística e Informática, Xalapa, VER, 91020, México. E-mail: zs13015663@estudiantes.uv.mx , edbenitez@uv.mx

2 Universidad Autónoma de Zacatecas, Unidad Académica de Ingeniería, Zacatecas, ZAC, 98000, México. E-mail: pvelasco@uaz.edu.mx

 

RESUMEN

Cada vez más personas realizan tareas apoyándose de sistemas que son construidos a partir de la composición de componentes de software. A pesar de la popularidad del desarrollo centrado en composición y las herramientas existentes para soportarlo hay evidencia sobre que el uso de éstas sigue siendo complicado. Sin embargo, existe pocaevidencia que permita comprender esta problemática en un contexto de usuarios finales. En este artículo se presenta una evaluación de herramientas de composición de componentes centrada en el usuario final. Una contribución importante de esta evaluación es que, considerando un conjunto de características intrínsecas al desarrollo centrado en composición y a los usuarios finales, seproponen un conjunto de funcionesy heurísticas relevantes para detectar problemas generales de adecuación funcional y usabilidad. Estas funciones y heurísticas proveen una base de conocimiento que puede ser extendida en dominios específicos de aplicación para mejorar el diseño de herramientas de composición.

Palabras-clave: herramientas de composición; evaluación heurística;inspección de características; usuarios finales.

 

ABSTRACT

A growing number of people perform tasks supported by systems that are built through the composition of software components. Despite the popularity of component-based software development and related tools, their use remains complicated for experts, not to mention for end users. This paper provides an evaluation of composition tools focused on end users. A major contribution of this assessment is that, given a set of characteristics that are intrinsic to composition-based software development and to end users, a set of relevant functions and heuristics to detect general problems of functional suitability and usability are proposed. These functions and heuristics provide a knowledge base that can be extended in specific application domains to improve the design of composition tools.

Keywords: composition tools; heuristic evaluation; characteristic inspection; end-user.

 

1. Introducción

En la actualidad cada vez más personas realizan diversas tareas apoyándose de sistemas de software.Se puede observar que muchos de estos sistemas son construidos a partir de la composición de componentes. En términos generales, un componente es un elemento de software pre-existente que implementa alguna funcionalidad, la cual puede ser accedida a través de interfaces bien definidas(Sommerville, 2006). Usando mecanismos de composición específicos, estos componentes pueden combinarse para crear sistemas. Ejemplos de componentes en muchos de estos sistemas son los COTS (Commercial Off-The-Shelf)(Morisio, Seaman, Basili, Parra, Kraft, & Condon, 2002), los Servicios Web (Cauldwell, Chawla, & Chopra, 2002), los Mashlets (Abiteboul, Greenshpan, & Milo, 2008) o las (Web) APIs.

Enfoques de desarrollo como el Desarrollo Basado en Componentes (Sommerville, 2006), las Líneas de Productos de Software (Clements & Northrop, 2001), la Arquitectura Orientada a Servicios (Erl, 2005)o más recientemente las arquitecturas de microservicios (Fowler, 2014) han adquirido popularidad puesto que soportan el desarrollo de sistemas de software usando un enfoque centrado en la composición. De forma similar, existen diversas herramientas, componentes y repositorios de componentes en dominios específicos que permiten el desarrollo de sistemas bajo este enfoque. Algunos ejemplos de herramientas y repositorios incluyen:

- BioCatalogue. Es un repositorio público de servicios web sobre biología(Bhagat, et al., 2010).

- Taverna. Es una herramienta de composición y ejecución de workflows basados en servicios web. Proporciona acceso a una amplia gama de servicios web y bases de datos principalmente del área de biología(School of Computer Science, 2010).

- API de Twitter. Es un componente de tipo web API el cual incluye métodos que permiten a los desarrolladores acceder a los datos básicos de Twitter, así como interactuar con Twitter Search(Twitter, 2015).

- Yahoo Pipes!. Es una herramienta de composición y publicación de aplicaciones web tipo mashups. Proporciona varios componentes para la creación de dichas aplicaciones(Yahoo!, 2014).

La disponibilidad de herramientasy (repositorios de)componentes ha contribuido a que nuevas comunidades de usuarios incursionen en el desarrollo de este tipo de sistemas. Un ejemplo es la comunidad de usuarios finales(Mehandjiev, Namoune, Wajid, Macaulay, & Sutcliffe, 2010), (Garlan, Dwivedi, Ruchkin, & Schmerl, 2012), (Roy Chowdhury, 2012). En términos generales este tipo de usuarios y los sistemas que construyenpresentan las siguientes características:

a. Son expertos en su dominio profesional pero inexpertos en materia de desarrollo de sistemas.

b. Soportan sus tareas diarias mediante sistemas de software que ellos mismos construyen a partir de la composición de componentes de software que son provistos por terceras partes.

c. Los sistemas que construyen tienen una arquitectura “data-flow”. En términos generales, una arquitectura “data-flow” se caracteriza por tener un conjunto de componentes que realizan una transformación sucesiva de flujos de datos(Taylor, Medvidovic, & Dashofy, 2009).

Ejemplos de estos usuarios incluyen a sociólogos realizando análisis de influencia en redes sociales (Knoke & Yang, 2008)conscriptsque usan lasAPIs de Twitter eigraph para R(team, 2015)o biólogos realizando análisis de cadenas de proteínas con workflows creados con la herramienta de composición Taverna y servicios Web en BioCatalogue.

A pesar de la popularidad del desarrollo centrado en composición y las herramientas existentes para soportarlo hay evidencia sobre problemas que hacen que el uso de éstas sigue siendo complicado. Además, existe muy poco material que permita comprender esta problemáticaen un contexto de usuarios finales.Este artículoreporta una evaluación de herramientas de composición de componentes centrada en el usuario final. En contraste con trabajos relacionados, una contribución importante de esta evaluación es que, considerando un conjunto de características intrínsecas al desarrollo centrado en composición y a los usuarios finales, se proponeny utilizan un conjunto de funciones y heurísticas relevantes para detectar problemas generales de adecuación funcional y de usabilidad. En términos generales, la adecuación funcional tiene que ver con la capacidad de la herramientas de composición de incorporar funciones que satisfacen necesidades declaradas o implícitas. La usabilidadtiene que ver con la facilidad de uso de dichas herramientas. Las funciones y heurísticas identificadas proveen una base de conocimiento que puede ser extendida en dominios específicos de aplicación para mejorar el diseño de herramientas de composición.

El artículo está organizado de la siguiente manera. La sección 2 discute trabajos relacionados con la evaluación funcional y de usabilidad de herramientas de composición de componentes. En la sección 3 se describen las particularidadesde la evaluación realizada, incluyéndose las funciones y heurísticas propuestas. En la sección 4 se muestran los resultados obtenidos de la evaluación. Finalmente, en la sección 5 se presentan las conclusiones y posibles líneas de trabajo futuro.

 

2. Trabajos Relacionados

En términos generales la funcionalidad de un producto de software puede entenderse como la capacidad que éste tiene para tomar datos de entrada, procesarlos y proveer los resultados esperados a través de funciones específicas.El estándar ISO/IEC 25100(ISO/IEC, 2011), que es un modelo de calidad de producto, considera la funcionalidad como una de las ocho características relevantes a tener en cuenta para evaluar las propiedades de un producto software determinado. En este estándar la funcionalidad es denotada como adecuación funcional y se definecomo “la capacidad del producto software para proporcionar funciones que satisfacen las necesidades declaradas e implícitas, cuando el producto se usa en las condiciones especificadas.”

Por otra parte, la usabilidades un atributo de calidad quetiene que ver con la facilidad de uso de un sistema de software.Existen diversas definicionesde usabilidad. Sin embargo, dos ampliamente adoptadas son las provistas por losestándares 9241 (ISO/IEC, 1998)y 25100 de la ISO/IEC. El estándar ISO/IEC 9241 define usabilidad como “el grado en el que un producto puede ser utilizado por usuarios específicos para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un determinado contexto de uso”. Similarmente, en el estándar ISO/IEC 25100 la usabilidad se define como “la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condicionesespecíficas de uso”.

En el pasado se han realizado evaluaciones de funcionalidad y usabilidad relacionadas al desarrollo centrado en composición. Por ejemplo, evaluacionesde métodosy lenguajes para realizar la composición de componentescomo BPEL, OWL-S, autómatas, redes de Petri, Álgebras de Procesos, (Beek, Bucchiarone, & Gnesi, 2007), (ter Beek, Bucchiarone, & Gnesi, 2007), (Feenstra, Janssen, & Wagenaar, 2007),(Baryannis & Plexousakis, 2010), (Portchelvi, Prasanna Venkatesan, & Shanmugasundaram, 2012). Igualmente se han reportado resultados de evaluacionesde herramientasde composición en trabajos como(Minhas, Sampaio, & Mehandjiev, 2012), (Insfran, Cedillo, Fernández, Abrahão, & Matera, 2012), (Yeltayeva, 2012). Todas estas evaluaciones reportan problemas relevantes. Sin embargo, la principal limitación de estas evaluaciones es que no consideran a los usuarios finales como usuarios potenciales de estas herramientas.

Por otra parte trabajos como(Zhao, Bhattarai, Liu, & Crespi, 2011), (Malinga, Gruner, & Koschmider, 2013) reportan resultados de evaluaciones a herramientas de composición para usuarios finales. Aunque se reportan problemas relevantes de funcionalidad y usabilidad, estas evaluaciones presentan doslimitaciones importantes: (i) son evaluaciones de una sola herramienta lo cual hace difícil el determinar si los problemas detectados se presentan en otras, y (ii)las evaluaciones no consideran característicasintrínsecas al desarrollo centrado en composiciónque impactan en la funcionalidad y usabilidad de herramientas de composición de componentes cuando son utilizadas por usuarios finales. La Tabla 1 describe estas características.

 

 

3. Descripción de la Evaluación

En las siguientes secciones se describen los detalles de la evaluación de la adecuación funcional y de la usabilidad de algunas herramientas representativas para soportar la composición automática de componentes.

3.1.Herramientas Seleccionadas

La selección de herramientas de composición se inició con una búsqueda en fuentes bibliográficas y sitios web. Producto de esta búsqueda se obtuvo información sobre 23 herramientas. Posteriormente, se realizó un análisis de esta información para conservar solamente las herramientas que soportaran losiguiente:1

1. Acceso a servicios pre-existentes (SP). Que permitan acceder a componentes pre-existentes provistos por terceras partes; esto es porque generalmente los usuarios finales no desarrollan sus propios componentes y tienden a utilizar componentes pre-existentes.

2. Facilidades “drag and drop” (DD). Que provean un ambiente gráfico de composición de componentes con facilidades “drag and drop”; esto es porque se considera que este tipo de facilidades permite de forma práctica y poco técnica seleccionar y ensamblar componentes.

3. Composiciones con una arquitectura “data-flow” en la forma de “worfklows” o “mashups”(WM). Que permitan construir composiciones de este tipo; esto debido a que generalmente los usuarios finales construyen sistemas de este tipo.

4. Disponibilidad de la herramienta (DI). Que se encuentren disponibles actualmente y no sean propietarias.

La Tabla 2 muestra las 23 herramientas indicándose el soporte o no soporte de los criterios listados anteriormente con los símbolos P y Î respectivamente. Como se puede apreciar las únicas herramientas que cumplen con los criterios son las siguientes: 1. Apache ODE, 3. BonitaSoft, 12. LONI Pipeline, 20. Taverna, 21. Wave Maker, 22. Yahoo Pipes!.

 

 

3.2. Composición Realizada

Para evaluar estas herramientas se consideró un sistema, creado a partir de la composición de componentes de software, que debe automatizar lo siguiente:

“Se desea obtener una lista de comentarios de Twitter. Dichos comentarios deben estar ordenados por fecha de forma ascendente y traducidos al Español. Además se necesita que la composición se ejecute en un tiempo aproximado de 900-1000 milisegundos y que tenga una disponibilidad de al menos 95 %.”

Para poder crear ese sistema, se consideraron 5 componentes de tipo servicio web; 3 son provistos por diferentes fabricantesy 2 fueron desarrollados por los autores de este trabajo. Estos componentes se describen con mayor detalle en la Tabla 3. Es importante mencionar que los atributos de calidad de cada componente se obtuvieron de la página del fabricante de cada servicio, y en el caso de los componentes desarrollados por los autores de este trabajo, sus respectivos atributos de calidad se calcularon de forma local.

 

 

3.3. Método de Evaluación

Se pretende detectar un conjunto general, (no de dominio específico) de problemas en el proceso de composición de componentes. Se prefieren métodos prácticos, efectivos y con poca demanda en tiempo, esto debido a la naturaleza, alcance y tiempo disponible para el desarrollo de este trabajo. Es por esto que los métodos de inspección se consideran adecuados para este trabajo, ya que son métodos en donde un grupo de expertos examinan aspectos relacionados con el funcionamiento del software y la usabilidad de la interfaz (Hollingsed & Novick, 2007). Entre los métodos de inspección relevantes se encuentran: Recorrido cognitivo, Inspección de estándares, Recorrido de usabilidad plural, Inspección de características y Evaluación heurística.

La Inspección de características y la Evaluación heurística fueron los métodos seleccionados para evaluar la funcionalidad y la usabilidad de las herramientas de composición de componentes seleccionadas. En las siguientes secciones se presentan los detalles correspondientes.

3.3.1. Evaluando Funcionalidad: Inspección de Características

Considerando nuestro objetivo de identificar un conjunto de problemas generales deadecuación funcional en herramientas de composición de componentes que sean relevantes al contexto de usuarios finales, se considera que la inspección decaracterísticas es un método apropiado.La inspección de características es un método en el cual un grupo de expertos inspecciona un producto de software para determinar si provee un conjunto de funciones que son generalmente extraídas a partir de la definición de un escenario de uso y desus tareas asociadas.

El estándar ISO/IEC 25010considera la adecuación funcional desde tres perspectivas:

1. Completitud funcional: grado en el quelas funciones provistas por el sistema corresponden a las funciones especificadas.

2. Correctitud funcional: grado en el que las funciones del sistema proveen resultados correctos con el nivel de precisión requerido.

3. Pertinencia funcional: grado en el que las funciones del sistema facilitan la realización de las tareas y los objetivos especificados.

Tomado en cuenta lo anterior, así como también las características intrínsecas al desarrollo centrado en composición (mostradas en la Tabla 1), en la Tabla 4 se describen las funciones propuestas para evaluar la adecuación funcional de las herramientas de composición. En esta evaluación se medirá el radio de funciones presentes en relación con el total de funciones consideradas en la evaluación; los detalles del cálculo de ésta métrica se describen en la sección 4.1.

 

 

3.3.2. Evaluando Usabilidad: Evaluación Heurística

Para evaluar problemas generales de usabilidad en herramientas de composición de componentes que sean relevantes al contexto de usuarios finales, se considera que la evaluación heurística es un método apropiado (Nielsen & Molich, 1990).

La evaluación heurística es un método en el cual un grupo de expertos inspecciona un producto de software con el fin de determinar si se adhiere o no a un conjunto de principios o heurísticas de diseño. La palabra “heuristica” viene de la griega “eureka”, y en el contexto de la evaluación heurística, se refiere a una serie de principios generales que consideran los expertos para llevar a cabo dicha evaluación. Estos principios se adecúan para asegurar que se adaptan al contexto de la interfaz del software que se va evaluar.

Existen evidencias sobre que bastan entre tres y cinco expertos para encontrar, aproximadamente, el 75% de los problemas de usabilidad (González, Lorés, & Pascual, 2006).

La evaluación heurística es considerada económica, intuitiva y utilizable en las primeras fases del proceso de desarrollo, esto para detectar la mayor cantidad posible de problemas de usabilidad antes de que el software esté en producción. Además permite hallar tanto problemas mayores como menores(Martins, Alexandra, & Rocha, 2013), (Saltiveri, Fransi, & Salla, 2013).

Existen varias propuestas de heurísticas o principios de diseño que pueden ser considerados en la evaluación heurística de la usabilidad. Enla Tabla 5se listan algunas de las más relevantes en la literatura:las propuestas por Nielsen (Nielsen J. , 1994), Tognazzini (Tognazzini, 2014) y, Shneiderman y Plaisant(Shneiderman & Plaisant, 2010). Para facilitar su comprensiónse hanorganizado en categorías. Teniendo en cuenta los aspectos que afectan la usabilidad en el contexto de los usuarios objeto de estudio y la tarea realizada, se indican con letras negritas cursivascuáles de estas heurísticas han sido consideradas en esta evaluación. A continuación se describe esta selección.

 

 

El principio de anticipación, definido por Tognazzini, hace referencia a que los sistemas deberían anticiparse a las necesidades y deseos del usuario. Se debe evitar que los usuarios tengan que buscar o recordar mucha información durante el uso del sistema y, en cambio, mostrarle la información y herramientas necesarias para realizar su trabajo. De esta forma, la consideración de este principio en el diseño de las herramientas de composición facilitaría a un usuario final realizar la selección de los componentes que satisfagan no solo las características funcionales requeridas (aspecto: selección de componentes disponibles en la Tabla 1), sino también los que satisfagan la calidad servicio de la composición requeridas para la composición (aspecto: estimación de calidad de servicio de la composición en la Tabla 1).

Como se observa en la Tabla 5, en la categoría manejo de errores hemos agrupado heurísticas y principios, propuestos por los tres autores, relacionados con este tema. En todos estos se comparte la visión de que el sistema debe ser capaz de reconocer, diagnosticar y recuperarse de errores. Así, el considerar las heurísticas y principios en esta categoría en el diseño de las herramientas de composición evitaría que el usuario final tuviera que detectar, diagnosticar y resolver manualmente incompatibilidades entre los componentes que va a utilizar (aspecto: detección de incompatibilidades entre componentes en la Tabla 1).

Heurísticas como relación entre el sistema y el mundo real y reconocimiento antes que recuerdo, propuestas por Nielsen,establecen que el sistema debe hablar el lenguaje de los usuarios prefiriendo los conceptos y frases familiares a éstos. Por otra parte el principio de aprendizaje de Tognazzini indica que se debe reducir la curva de aprendizaje del uso sistema. De esta forma, estas heurísticas y principios en el diseño de las herramientas de composición contribuye a mejorar el nivel abstracción del lenguaje utilizado (aspecto: uso de un lenguaje de bajo nivel de abstracción en la Tabla 1).

La Tabla 6 define las sub-heurísticas que se consideraron para la evaluación del conjuntode heurísticas y principios presentados en la Tabla 5. Estas sub-heurísticas se seleccionaron de listas predefinidas --por ejemplo, (Nielsen J. , 1994), (Shneiderman & Plaisant, 2010), (Tognazzini, 2014). Algunas sub-heurísticas fueron adaptadas para corresponder mejor al contexto de los usuarios objeto de estudio, la composición realizada y las herramientas evaluadas. En esta evaluación se calculará el nivel del severidad del error provocado por el desapego a las sub-heurísticas. Esta métrica es muy común en la evaluación heurística; los detalles del cálculo de éstamétrica se describen en la sección 4.2.

 

 

3.4. Participantes en la Evaluación

La evaluación de las herramientas seleccionadas fue realizada por cinco evaluadores, cuatro de ellos Licenciados en Informática y actualmente alumnos del cuarto semestre del programa de Maestría en Sistemas Interactivos Centrados en el Usuario de la Universidad Veracruzana. El quinto evaluador es Licenciado en Informática y Maestro en Redes y Sistemas Integrados y cuenta con 3 años de experiencia laboral en el desarrollo de sistemas basados en componentes.

 

4. Resultados Obtenidos

En las siguientes secciones, se muestran los resultados consolidados de las evaluaciones realizadas por los expertos.

4.1. Resultados de la Evaluación de la Adecuación Funcional

En las Tablas 7 y 8 se muestran los resultados obtenidos por los cinco expertos (E1 - E5) en la evaluación de la adecuación funcional de las herramientas de composición seleccionadas.En la tablas, si la herramienta provee lafunción se denota con un 1 y si no con un 0.La columna “R” es el promedio obtenido de los valores de los cinco expertos.

 

 

 

 

Como se puede observar, la mayoría de las herramientas permiten generarla composición automáticamente (función CA). Solamente LONI PipeLine no cuenta con esta capacidad. También se puede ver que todas las herramientaspermiten verificar de forma automática la correctitud de la composición (función VA). Cuando se tratade aumentar componentes y/o operaciones a la composición (función ES), la mayoría de las herramientascuentan con esta capacidad; la excepción fue Yahoo Pipes!.

La adecuación funcional (AF)de cada herramienta (h), podría ser evaluada usando la siguiente fórmula:

AF (h)=1 – A/B

donde:

Adenota el número de funciones ausentes o problemáticas en la evaluación,

Bdenota elnúmero de funcionesconsideradas,

quedando como sigue:

AF (Apache ODE) = 1 – 0/3 = 1

AF (BonitaSoft) =1 – 0/3 = 1

AF (LONI Pipeline) =1 – 1/3 = 0.6

AF (Taverna)= 1 – 0/3 = 1

AF (Wave Maker)= 1 – 0/3 = 1

AF (Yahoo Pipes! ) = 1 – 1/3 = 0.6

Considerando que un valor de AFlo mas cercano a 1 es mejor, solamente las herramientas de composición LONI Pipeline y Yahoo Pipes! tienen un valor no óptimo de adecuación funcional.

4.2. Resultados de la Evaluación de Usabilidad

En la Tablas 9 y la Tablas 10 se muestran los resultados obtenidos por cada experto (E1 – E5) durante la evaluación de usabilidad de las herramientas de composición seleccionadas. Los valores denotan el nivel de severidad del error (NS) detectado en la evaluación el cual se calcula como sigue:

NS = (F)x(I)

donde:

F denota la frecuencia con la que se incurre en el error.

I denota el impacto asociado a cada sub-heurística.

La frecuencia (F) puede tomar los siguientes valores:

0 = nunca.

1 = a veces.

2 = muchas veces.

El impacto (I) puede tomar los siguientes valores:

0 = No es problema de usabilidad.

1 = Problema sin importancia, no es necesario arreglarlo a menos que haya tiempo.

2 = Problema de poca importancia, arreglarlo no tiene mucha importancia.

3 = Problema grave, es importante arreglarlo.

4 = Problema catastrófico, es vital arreglarlo.

Con base en lo anterior, el nivel de severidad (NS) puede tomar los siguientes valores:

0 = No es un error.

1 - 2 = Error sin importancia.

3 - 4 = Error de grado medio.

5 - 6 = Error grave.

7 - 8 = Error catastrófico

 

 

 

 

En la Tabla 9 y la Tabla 10 el valor mostrado en las columnas E1, E2, E3, E4, E5 indica el nivel de severidad del error (NS) detectado por cada experto. La columna “R” es el promedio obtenido de los valores de los cinco expertos. Este promedio está graficado en la Figura 1 y se observa lo siguiente.

 

 

La anticipación es un problema que va de grave a catastrófico (valores de 5 a 7), debido a que ninguna de las herramientas ofrece soporte para especificar, al inicio del proceso de composición, los aspectos funcionales y de calidad del servicio que se espera del sistema a construir (sub-heurística A1). Como consecuencia de lo anterior, ninguna de las herramientas evaluadas ofrece soporte para realizar la selección de componentes considerando los aspectos funcionales y de calidad de servicio requeridos (sub-heurística A2). El usuario final tiene siempre que resolver todo esto de forma manual.

En lo que se refiere al manejo de errores se detectó que es un problema que va de grado medio a catastrófico (valores de 4 a 8), ya que algunas herramientas brindan cierto soporte para prevenir errores (sub-heurística E1). Sin embargo, cuando se presentan errores,los mensajes de error no brindan información de la causa y tampoco de cómo resolver el error presentado (sub-heurísticas E2 y E3), además los mensajes se comunican al usuario usando un lenguaje técnico (sub-heurística E4).

Finalmente, el uso de un lenguaje de bajo nivel en la composición es un problema que va desde grado medio hasta catastrófico (valores de 4 a 7), esto porque todas las herramientas utilizan íconos poco intuitivos y un lenguaje muy técnico para los usuarios finales (sub-heurísticas L1 y L2). Sin embargo, algunas tienen un lenguaje que puede ser más técnico que el utilizado en otras y dado que los evaluadores tienen conocimientos en desarrollo de sistemas, no calificaron el lenguaje utilizado como un lenguaje muy técnico.

 

5. Conclusiones y Trabajo Futuro.

En este trabajo se presentó una evaluación de herramientas de composiciónpara detectar problemas generales de adecuación funcional y usabilidad relevantes al contexto de un usuario final. En contraste con algunos trabajos relacionados, una contribución importante de la evaluación presentada esque se usaronfunciones y heurísticas que fueron identificadas considerando un conjunto de aspectos intrínsecos al desarrollo centrado en composición y a los usuarios finales.

A partir de los resultados de la evaluación realizada se puede concluir que las herramientas evaluadas presentan pocos problemas de adecuación funcional y varios problemas de usabilidad para un usuario final. Entre los más importantes de usabilidad se encuentran el nulo soporte ofrecido para la especificación de aspectos funcionales y de calidad del servicio del sistema a construir y para la selección de componentes basada en dichas especificaciones. Además de que las herramientas no proveenfunciones que brinden el soporte necesario a los usuarios para resolver los errores que puedan tener al hacer una composición, ya que como se observó, las herramientas no muestran las causas ni las posibles soluciones a dichos errores.

Aunque estos problemas son generales, consideramos que es importante conocerlos pues proveen un conjunto inicial que puede ser considerado para, como trabajo futuro, mejorar las muchas herramientas de composición actuales. Igualmente estos problemas proveen la base para realizar futuras evaluaciones considerando contextos más específicos a determinados tipos de usuarios finales --por ejemplo, sociólogos, biólogos.

Con base en los resultados obtenidos, consideramos que la evaluación heurística fue un método apropiado para detectar problemas de usabilidad generales. Sin embargo, en dominios de aplicación específicos seríanecesario utilizar otras técnicas de evaluación; preferentemente aquellas que involucren a usuarios finales.

 

Agradecimientos

Los autores desean reconocer a los revisores anónimos de este artículo por sus útiles sugerencias. La primera autora agradece a CONACYT-Mexico el apoyo para la realización de sus estudios de Maestría en Sistemas Interactivos Centrados en el Usuario (No. de becario: 297377).

 

Referencias

Abiteboul, S., Greenshpan, O., & Milo, T. (2008). Modeling the mashup space. 10th ACM workshop on Web information and data management (pp. 87-94). ACM.         [ Links ]

Al Sarraj, W. (2014). Toward Usability Evaluation Criteria for Web Mashup Makers for End-Users. International Journal of Advanced Computer Technology , 3, 23-32.         [ Links ]

Apache, S. F. (205). Apache ODE. From http://ode.apache.org/        [ Links ]

Apatar, I. (2014). Apatar. Connecting data. From http://www.apatar.com/        [ Links ]

Baryannis, G., & Plexousakis, D. (2010). Automated Web Service Composition: State of the Art and Research Challenges. Foundation for Research & Technology - Hellas - Institute of Computer Science.         [ Links ]

Beek, M., Bucchiarone, A., & Gnesi, S. (2007). A Survey on Service Composition Approaches: From Industrial Standards to Formal Methods. Second International Conference on Internet and Web Applications and Services (pp. 15-21). IEEE Computer Society .         [ Links ]

Bhagat, J., Tanoh , F., Nzuobontane, E., Laurent , T., Orlowski, J., Roos, M., et al. (2010). BioCatalogue: a universal catalogue of web services for the life sciences. Nucleic Acids Research , 689-694 .         [ Links ]

Bonitasoft, I. (2015). Bonitasoft. From http://www.bonitasoft.com/        [ Links ]

Cauldwell, P., Chawla, R., & Chopra, V. (2002). Servicios Web XML. España: Anaya Multimedia-Anaya Interactiva.         [ Links ]

Clements , P., & Northrop, L. (2001). Software Product Lines: Practices and Patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.         [ Links ]

Erl, T. (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall.         [ Links ]

Feenstra, R. W., Janssen, M., & Wagenaar, R. W. (2007). Evaluating Web Service Composition Methods: the Need for Including Multi-Actor Elements. Electronic Journal of e-Government , 5 (2), 153--163.         [ Links ]

Fowler, M. (2014). Microservices. From http://martinfowler.com/articles/microservices.html        [ Links ]

Garcês, R., De Jesus, T., Cardoso, J., & Valente, P. (2009). Open Source Workflow Management Systems: A Concise Survey. In GWDL: A graphical workflow definition language for business workflows. Springer Berlin Heidelberg.         [ Links ]

Garlan, D., Dwivedi, V., Ruchkin, I., & Schmerl, B. (2012). Foundations and Tools for End-user Architecting. 17th Monterey Conference on Large-Scale Complex IT Systems: Development, Operation and Management (pp. 157-182). Springer-Verlag.         [ Links ]

González, M. P., Lorés, J., & Pascual, A. (2006). Evaluación Heurística. In La Interacción Persona Ordenador (pp. 1-40). AIPO Press.         [ Links ]

Hassan Montero, Y., & Ortega Santamaría, S. (2009). Informe APEI sobre usabilidad. APEI.         [ Links ]

Hollingsed, T., & Novick, D. G. (2007). Usability inspection methods after 15 years of research and practice. Annual ACM International Conference on Design of Communication (pp. 249-255). ACM.         [ Links ]

Insfran, E., Cedillo, P., Fernández, A., Abrahão, S., & Matera, M. (2012). Evaluating the Usability of Mashups Applications. Eighth International Conference on the Quality of Information and Communications Technology (pp. 323-326). IEEE Computer Society.         [ Links ]

ISO/IEC. (1998). ISO 9241-11:1998 Ergonomic requirements for office work with visual display terminals (VDT)s - Part 11 Guidance on usability.         [ Links ]

ISO/IEC. (2011). ISO/IEC 25010:2011 Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models. ISO.         [ Links ]

JOpera.org. (2013). JOpera. Process Support for Web Services. From http://www.jopera.org/        [ Links ]

Kapow. (2015). Kapow Software. A Kofax Company. From http://www.kapowtech.com/        [ Links ]

Knoke, D., & Yang, S. (2008). Social Network Analysis. SAGE Publications, Inc.         [ Links ]

Laboratory, o. N. (2015). Loni Pipeline. From http://pipeline.bmap.ucla.edu/        [ Links ]

Malinga, M., Gruner, S., & Koschmider, A. (2013). Quality and Usability of Mashup Tools: Criteria and Evaluation. South African Institute for Computer Scientists and Information Technologists Conference (pp. 154-159). ACM.         [ Links ]

A.I. Martins, Q. Alexandra, N.P. Rocha (2013). Avaliação de Usabilidade: Uma Revisão Sistemática da Literatura. Revista Ibérica de Sistemas y Tecnologías de la Información. Vol. 11, 31-43.         [ Links ]

Mehandjiev, N., Namoune, A., Wajid, U., Macaulay, L., & Sutcliffe, A. (2010). End user service composition: Perceptions and requirements. 8th European Conference on Web Services (pp. 139-146). IEEE Computer Society.         [ Links ]

Minhas, S. S., Sampaio, P., & Mehandjiev, N. (2012). A Framework for the Evaluation of Mashup Tools. Ninth International Conference on Services Computing (pp. 431-438). IEEE Computer Society.         [ Links ]

Morisio, M., Seaman, C., Basili, V., Parra, A., Kraft, S., & Condon, S. E. (2002). COTS-based software development: processes and open issues. Journal of Systems and Software , 61 (3), 189-190.         [ Links ]

Muñoz Jiménez, J. A. (2010). Programación con AJAX. From http://jamj.webcindario.com/programacion/ajax/AJAX.pdf        [ Links ]

Nielsen, J. (1994). Enhancing the Explanatory Power of Usability Heuristics. Conference on Human Factors in Computing Systems (pp. 152--158). ACM.         [ Links ]

Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. SIGCHI Conference on Human Factors in Computing Systems (pp. 249--256). ACM.         [ Links ]

Patel , A., Na , L., Latih, R., Wills, C., Shukur , Z., & Mull, R. (2010). A Study of Mashup as a Software Application Development Technique with Examples from an End-User Programming Perspective. Journal of Computer Science , 6 (12), 1406-1415.         [ Links ]

Portchelvi, V., Prasanna Venkatesan, V., & Shanmugasundaram, G. (2012). Achieving Web Services Composition – a Survey. 2 (5), 195-202 .         [ Links ]

RedHat. (2014). JBoss Developer. From http://www.jboss.org/        [ Links ]

Roy Chowdhury, S. (2012). Assisting End-user Development in Browser-based Mashup Tools. International Conference on Software Engineering (pp. 1625-1627). IEEE Computer Society.         [ Links ]

RSSBus, I. (2014). RSSBus. From http://www.rssbus.com/        [ Links ]

RunaWFE. (2013). RunaWFE. From http://wf.runa.ru/        [ Links ]

T.G. Saltiveri, E.C. Fransi, Y. M Salla (2013). Análisis de usabilidad de cooperativas del sector de la fruta y aceite en el área de Lleida. Revista Ibérica de Sistemas y Tecnologías de la Información. Vol. 11, 31-43.         [ Links ]

School of Computer Science, U. o. (2010). Taverna. From http://www.taverna.org.uk/        [ Links ]

Seffah, A., Donyaee, M., B. Kline, R., & K. Padda, H. (2006). Usability measurement and metrics: A consolidated model. Software Quality Control , 4 (2), 159--178.         [ Links ]

Shneiderman, B., & Plaisant, C. (2010). Designing the User Interface: Strategies for Effective Human-Computer Interaction: Fifth Edition. Addison-Wesley Publ. Co.         [ Links ]

Sommerville, I. (2006). Ingeniería de Software. Pearson Addison Wesley.         [ Links ]

Taylor, R. N., Medvidovic, N., & Dashofy, E. M. (2009). Software Architecture: Foundations, Theory, and Practice. Wiley Publishing.         [ Links ]

team, T. i. (2015). igraph R package. From http://igraph.org/r/        [ Links ]

ter Beek, M., Bucchiarone, A., & Gnesi, S. (2007). Web Service Composition Approaches: From Industrial Standards to Formal Methods. International Conference on Internet and Web Applications and Services, (pp. 15-21). IEEE Computer Society.         [ Links ]

Together Teamsolutions Co., L. (2011). Together - Professional Open Source. From http://www.together.at/prod/workflow/tws        [ Links ]

Tognazzini, B. (2014). First Principles of Interaction Design. From Ask.Tog: http://asktog.com/atc/principles-of-interaction-design/        [ Links ]

Twitter, I. (2015). REST APIs - Twitter Developers. From https://dev.twitter.com/rest/public        [ Links ]

WaveMaker, I. (2014). WaveMaker. From http://www.wavemaker.com/        [ Links ]

Yahoo!, I. (2014). Yahoo Pipes! From https://pipes.yahoo.com/pipes/        [ Links ]

Yeltayeva, K. (2012). Usability Study of the Taverna Scientific Worflow Workbench. University of Manchester, Faculty of Engineering and Physical Sciences. University of Manchester.         [ Links ]

Zhao, Z., Bhattarai, S., Liu, J., & Crespi, N. (2011). Mashup services to daily activities: end-user perspective in designing a consumer mashups. International Conference on Information Integration and Web-based Applications and Services (pp. 222-229). ACM.         [ Links ]

 

Recebido/Submission: 03/27/2016

Aceitação/Acceptance: 04/14/2016

 

Notas

1Estos criterios fueron establecidos por los autores considerando principalmente las características de los usuarios finales descritas en la Sección 1.

Creative Commons License Todo o conteúdo deste periódico, exceto onde está identificado, está licenciado sob uma Licença Creative Commons