Abstract— In this article, the Activity Theory (AT) is analyzed to take it as a basis for the definition of an Activity classification Model of Interactive Systems called: Activity Taxonomy (ATx) for Interactive Systems. Our purpose is to use the ATx for: a. The incorporation of the Human Computer Interaction (HCI) in the processes of software development, b. Definition of the minimum activity classifiers to specify interactive systems that promote HCI, c. Evaluation and integration of languages and/or software development processes, d. The specification of the execution models of interactive systems.

Keywords— Activity Theory, Activity Taxonomy, Human Computer Interaction.

I. INTRODUCCIÓN A TEORÍA de la Actividad (TA) [1], tiene sus raíces en los trabajos de Vygotsky y se ha definido como un

paradigma psicológico [2]. Hasta el día de hoy es de resaltar su aplicación en la Ingeniería de Software [3], y en la Interacción Humano Computador (HCI) [4]. Específicamente, en el levantamiento de requisitos de sistemas interactivos complejos se ha definido como una herramienta potencial, principalmente, porque hace énfasis en el contexto social en el cual la actividad humana toma lugar [5].

En la literatura se observan diversos trabajos [2], [5], [6], [7], en los que se propone integrar la TA con notaciones, lenguajes y metodologías para el levantamiento de requisitos de sistemas interactivos. Generalmente, estas especificaciones de requisitos se basan en plantillas, por ejemplo las que provee el RUP [8], que clasifican la actividad de una manera muy general sin permitir a los desarrolladores capturar información relevante, p.ej., feedback, awareness, niveles de abstracción, etc. De esta forma es difícil para los desarrolladores tomar conciencia de toda la información que requiere ser capturada en dichas especificaciones. Estas deficiencias metodológicas generan un impacto negativo sobre el entendimiento y la percepción que el usuario final tiene sobre el sistema interactivo que se desarrolla. Lo que se busca es que el desarrollador comprenda perfectamente cuál es el impacto de una mala clasificación de la actividad en la adquisición de información y aceptación del producto, en términos generales,

M. L. Villegas, Universidad del Quindío, Universidad del Cauca,

Colombia, mlvillegas@uniquindio.edu.co C. A. Collazos, Universidad del Cauca, Colombia,

ccollazo@unicauca.edu.co W. J. Giraldo, Universidad del Quindío, Colombia,

wjgiraldo@uniquindio.edu.co J. M. González, Benemérita Universidad Autónoma de Puebla, México,

juan.gonzalez@cs.buap.mx

la calidad vista como el cumplimiento de las características del producto respecto de las necesidades de los usuarios.

Esta investigación está dirigida hacia el análisis de la TA y su integración con aspectos del desarrollo de sistemas interactivos. Se trata de determinar los clasificadores mínimos necesarios para especificar un sistema interactivo desde múltiples contextos. Esto implica la identificación de la relación que existe entre la Actividad y el Desarrollo de Sistemas Interactivos desde la perspectiva de contextos como la colaboración, la interfaz de usuario, la seguridad, etc. Se espera que la estructura taxonómica de clasificación propuesta contribuya a mejorar el desarrollo y uso de los sistemas interactivos. La presente propuesta se centra en la definición de una Taxonomía de la Actividad (TxA) que permita principalmente identificar clasificadores de la actividad que la mayoría de los ingenieros de desarrollo de software no han considerado hasta el día de hoy y que deberían considerar si se tienen en mente atributos como la colaboración, la interfaz de usuario, la usabilidad o la televisión interactiva. Se pretende definir la TxA teniendo en cuenta contribuciones desde la TA [1] y la Clasificación del Modelado de la Actividad (CMA) [9].

La sección II describe los fundamentos conceptuales que soportan la definición de la TxA. En la sección III se presenta la metodología y pasos para la definición de la propuesta. Luego, en la sección IV se describe la TxA. La sección V hace referencia al estado del arte. La sección VI presenta ejemplos de aplicación para la TxA y por último, en la sección VII, las conclusiones y trabajo futuro.

II. FUNDAMENTOS CONCEPTUALES PARA LA DEFINICIÓN DE LA TAXONOMÍA DE LA ACTIVIDAD

Los conceptos que soportan la definición de la TxA para Sistemas Interactivos son: la TA [10] y la CMA [9].

A. Razones para elegir la Teoría de la Actividad Principalmente, nos interesa la TA por sus diversas

aplicaciones en la Interacción Humano Computador (HCI) y en la Ingeniería de Software [11], [12], [13], [14], [15], [16]. Como se comenta en [2], la TA puede ser útil en situaciones donde es necesario explorar el contexto social diverso y complejo de un sistema, particularmente aquellas que tienen componentes humanos y de cómputo.

Adicionalmente, la TA y la HCI tienen puntos de intersección que se reflejan en la participación de actores en actividades y en la naturaleza jerárquica del rendimiento de las actividades. La TA provee una forma coherente de entender y modelar actores como usuarios de herramientas acopladas con otros participantes y artefactos [12].

M. Villegas, C. A. Collazos, W. J. Giraldo and J. M. González

Activity Theory as a Framework for Activity Taxonomy in HCI

L

B. Razones para elegir la CMA La palabra Taxonomía: “Ciencia que trata de los

principios, métodos y fines de la clasificación”, se relaciona directamente con el significado de “Clasificación”. Si lo que se pretende es definir una Taxonomía de la Actividad, se debe tener en cuenta entonces el concepto de la Clasificación de la Actividad como lo define [9], [17].

El modelado de la actividad ha sido estudiado por varias disciplinas (la Psicología Cognitiva, la Planificación y Asignación de tareas, la Ingeniería del Software, Etnografía, Colaboración y otros [18]). Todas estas disciplinas estudian las actividades para asegurar la comprensión de cómo los usuarios pueden interactuar con una interfaz de usuario para la realización de una tarea interactiva, para planificar y asignar tareas a los usuarios de una organización o capturar información de las tareas en una forma operativa que sea comprensible por una máquina en un determinado contexto de uso. La CMA encuentra sus bases en el estudio de múltiples propuestas que se originan en la TA [19] y que consideran a la actividad como concepto mediador para comprender la relación entre conceptos de la TA como: individuo‐división de trabajo, individuo‐objeto, individuo‐herramienta, etc. [6]. Todas estas relaciones pueden definir un contexto distinto para representar la actividad, o viceversa, la actividad representa un contexto distinto para el estudio de estas relaciones.

III. METODOLOGÍA Y DESARROLLO La definición de la TxA para Sistemas Interactivos

inicialmente se enfoca en la integración de los fundamentos conceptuales mencionados en la sección II: TA y CMA. Se sigue la propuesta para la integración de procesos y notaciones definida por [9], ya que define un proceso de integración formal y organizado para clasificar e integrar los elementos conceptuales de las propuestas analizadas. El proceso de integración comprende los pasos A hasta E, que se describen en detalle, a continuación.

La definición del metamodelo base que resulta de aplicar el paso E, permitirá definir un conjunto de elementos clasificadores para la TxA, los cuales conformarán una organización más fuerte y coherente de los conceptos existentes relacionados con la Actividad, más que adicionar nuevos conceptos a partir de las propuestas analizadas.

A. Identificación de elementos conceptuales de interés. Las propuestas de interés para este trabajo, se fundamentan

en la especificación de la Actividad en diferentes áreas del conocimiento. Dado que la Actividad es el concepto base para definir la TxA, es pertinente tomar todos los elementos conceptuales de ambas propuestas para su integración.

B. Normalización de los elementos conceptuales empleando un mismo estándar. El metamodelo que representa la estructura de un Sistema

de Actividad es definido en [2]. Contiene los elementos conceptuales definidos por la TA extendida y define las relaciones y las restricciones que existen entre ellos (Fig.1).

Figura 1. Metamodelo de la TA definido en [2].

Es posible observar que la estructura de un Sistema de

Actividad representa los componentes de una Actividad. Sin embargo el concepto “Actividad” no se considera dentro de dicha estructura. Esto indica que existe una dicotomía en el sentido de que se toma la “Actividad” como algo que tiene entidad, que es el “Todo” pero que para que sea entendible, necesita ser dividido en dos partes complementarias: “Actividad” y sus “Elementos Estructurales”.

El metamodelo que representa la estructura de la CMA se presenta para un solo aspecto (Fig. 2). La especificación de los Metamodelos de ambas propuestas permite identificar relaciones de mapeo y trazabilidad entre sus conceptos.

C. Identificación de puntos de intercambio. Un punto de intercambio es una o más piezas de

información de los elementos conceptuales de la TA que poseen una correspondencia estructural o sintáctica con otras piezas de información en la Clasificación de la Actividad. Este enfoque de integración pretende encontrar el mapeo semántico entre las propuestas y posteriormente identificar la correlación existente entre los elementos conceptuales. Es necesario analizar los mapeos existentes entre las propuestas base para establecer cómo se relacionan y para definir posibles elementos faltantes que contribuyan a completar la TxA.

Los principales elementos de la Clasificación de la Actividad que se mapean con la TA son los que se refieren a los Tipos de Actividad y los Roles que las realizan tanto a nivel de Negocio como a nivel de Sistema (Fig. 3).

El mapeo entre estas dos propuestas muestra que desde la perspectiva del Negocio, la TA se centra en las categorías persona (Community, Subject) y actividad (DoL); y que desde la perspectiva del Sistema, la TA se centra en instrumento (Tool).

Figura 2. Metamodelo de la Clasificación de la Actividad. Se podría considerar que la categoría de motivación (Aim,

Rule) se mapea sobre el Aspecto al que se refiere la Clasificación de la Actividad, el cual se representa como una única capa en el metamodelo. Además, la categoría datos (Outcome) no se considera en la Clasificación de la Actividad.

Por su parte, la Clasificación de la Actividad se centra en separar los niveles de abstracción Negocio y Sistema para todas sus categorías, persona (Actor, Worker, Sistema) y

actividad (Core, Support, Management). La actividad a su vez se especifica en niveles de granularidad.

Nótese que no se mapea alguna metaclase del metamodelo de la Clasificación de la Actividad con la metaclase Sujeto (Subject) del metamodelo de la TA. Esto es porque cada instancia de Sujeto debe estar relacionada con una instancia de Comunidad (Community) por la restricción de multiplicidad 1 sobre la relación entre Sujeto y Comunidad. Cada instancia de Comunidad tiene un mapeo a una instancia de Actor de Negocio (BusinessActor) y de Trabajador de Negocio (BusinessWorker), así que los Sujetos ya están mapeados en dicho metamodelo.

Lo que se pretende es utilizar la TA como base en la creación de notaciones enfocadas en el modelado de la Actividad y que sea posible enlazarlas con otras notaciones enfocadas en modelar otras categorías (Datos, Lugares, Roles, Tiempos, Motivación). Una condición deseable en un marco conceptual es que se proporcione un conjunto de conceptos dentro de una misma categoría, para así representar modelos sobre una vista y una perspectiva en particular.

Desde esta perspectiva, si se observa el metamodelo de la TA se deduce que sólo sería posible especificar una sintaxis concreta (diagrama) en la categoría que contiene conceptos relacionados con los Roles, para representar la relación entre Comunidad y Sujeto. Sería imposible establecer un diagrama que represente de manera jerárquica las tareas que tienen lugar en una comunidad. Para esto, sería necesario que la TA incluyese conceptos como el de tarea y relación entre tareas. Se podría considerar entonces incluir en el metamodelo de la TA el concepto de “Contradicción” (Contradiction) definido por Engeström [20] en su definición de la TA extendida.

Figura 3. Mappings entre la TA y la Clasificación de la Actividad.

Adicionalmente, el uso de un único concepto para describir por completo la información de una categoría, limita la capacidad que tiene un marco conceptual para especificar diagramas [9]. En la TA se puede observar como el concepto División de la Labor (DivisionOfLabor) representa la información de la categoría Actividad y como el concepto Herramienta (Tool) representa toda la información para la perspectiva del sistema. De esta forma, estos conceptos sólo son útiles para describir el nombre y algunos atributos del elemento de modelado que se desea representar. En la mayoría de los casos esto es insuficiente. Por ejemplo, de la Ingeniería de Software se sabe que son muchos los conceptos que son indispensables para describir un sistema informático, por lo que, sólo con el concepto Herramienta (Tool) no sería posible representar los datos, los requisitos, la distribución, los roles, etc. necesarios para llevar a cabo dicha descripción.

D. Definición de los Clasificadores o Conceptos de cada celda. En esta sección, es necesario hacer referencia a la

definición de una capa de integración entre propuestas, al igual que se hace en el proceso de integración que se está siguiendo, propuesto por [9].

Según la información obtenida en el mapeo entre la TA y la Clasificación de la actividad (CA), la capa de integración contiene la siguiente información: perspectivas de modelo de negocio y modelo de sistema y las vistas de datos, función, personas y motivación. La intersección de vistas y perspectivas da lugar a 8 celdas de modelado (Fig. 4).

Figura 4. Capa de Integración para Análisis de Clasificadores.

Los conceptos de cada celda tienen la propiedad de ser una

generalización de los elementos de modelado que representan con el fin de proporcionar un soporte adecuado a la información de dichos elementos de modelado para las distintas notaciones [9]. En la Fig. 4 se observa la definición del concepto “Función” (Function) que generaliza los elementos de modelado “DoL” y “Tipo de Actividad de Negocio” (BusinessActivityType), a nivel de Negocio y los elementos de modelado “Herramienta” (Tool) y “Tipo de Actividad de Sistema” (SystemActivityType), a nivel de Sistema. Se observa también la definición del concepto “Personas” (People) que generaliza los elementos de modelado “Comunidad” (Community), “Sujeto” (Subject), “Actor de Negocio” (BusinessActor) y “Trabajador de

Negocio” (BusinessWorker), a nivel de Negocio y los elementos de modelado “Herramienta” (Tool), “Actor de Sistema” (SystemActor), “Sistema” (System), a nivel de Sistema. La relación denominada “suPersona” (itsPeople) generaliza el elemento de modelado “Mediación” (Mediation), el cual representa una relación de interconexión entre vistas.

El concepto “Persona” (People) está en capacidad de almacenar información tanto de un Sujeto, de una Comunidad, de un Trabajador de Netocio, como de un Actor de Negocio que esté disponible para efectos de la integración. La relación de mapeo indica que se debe especificar un concepto que sea capaz de generalizar todos los conceptos que mapea.

Figura 5. Relación de Conceptos entre la TA, la CA y la Capa de Integración.

Es importante resaltar que la vista de la Función es la vista

donde se deben ubicar los clasificadores de la Actividad “Cómo” (How), tema principal de interés para este trabajo. Las relaciones entre conceptos (Fig. 5), permite observar que si nos referimos a la estructura conceptual de la Teoría de la Actividad (TA), en la Vista de la Función, esta teoría sólo define dos clasificadores que se ubican en esta vista: División de la Labor a nivel de Negocio y Herramienta (Tool) a nivel de Sistema. Los demás clasificadores definidos por la TA se ubican en otras vistas distintas a la de Función. Desde esta perspectiva, la TA se toma como un elemento integrador (Amalgama) entre elementos conceptuales de las demás vistas, en el proceso de definición de la Taxonomía de la Actividad.

El análisis completo, tanto de las relaciones entre conceptos como de los mapeos, permite generar los clasificadores de cada celda de la capa de integración (Fig. 6).

El interés de definir estos clasificadores es que cada celda provea un contenedor para los modelos que abordan una determinada perspectiva y vista. De esta forma será posible proveer una representación desde distintos puntos de vista, en diferentes niveles de granularidad, generalidad y abstracción que posea lo necesario para el modelado de roles, interfaces, colaboración, tareas, y datos.

Figura 6. Clasificadores para Cada Celda de la Capa de Integración.

E. Definición del Metamodelo Base. El metamodelo base se especifica con el fin de mostrar las

relaciones existentes entre los clasificadores ubicados en cada celda de la capa de integración (Fig. 7). A partir del metamodelo se definirá la Estructura Taxonómica para la Taxonomía de la Actividad para Sistemas Interactivos.

Como lo define [9], cada concepto del metamodelo ubicado en una celda de la capa de integración debe ser completamente independiente de los conceptos de las otras celdas, es decir, cada elemento conceptual debe tener independencia taxonómica. Esto hace posible el hecho de generar notaciones con las que se especifiquen modelos de objetivos, de organización, de actividad, de datos y definir las relaciones estructurales entre dichos modelos.

IV. TAXONOMÍA DE LA ACTIVIDAD PARA SISTEMAS INTERACTIVOS

Las taxonomías de objetos y conceptos se han convertido sin duda en una herramienta científica básica, como se resume en [21]. Los sistemas de clasificación permiten la visualización de la teoría de una manera útil y servir, de forma similar a las teorías, como conductores para la investigación [22]. Particularmente, en el ámbito de la Ingeniería de Software, las taxonomías se convierten entonces en un elemento esencial para documentar teorías que acumulan el conocimiento [23].

El propósito principal de la Taxonomía de la Actividad es que provea una sintaxis abstracta que sirva como referencia en la definición de un lenguaje mínimo que represente la actividad y que pueda abarcar múltiples aspectos donde la labor tenga lugar, como la colaboración, la interfaz de usuario, la seguridad, etc. Se pretende que la taxonomía propuesta sea útil como marco de evaluación para propuestas metodológicas y que permita identificar qué aspectos de los mencionados, están siendo capturados en las descripciones de la actividad.

Otro de los propósitos de la TxA es poder proporcionar un conjunto de clasificadores que permitan definir completamente un sistema en torno a una serie de capas, aspectos o facetas (usabilidad, colaboración, funcionalidad, seguridad, interacción, etc.). Dichos clasificadores representarían cada aspecto del modelado de la actividad. El metamodelo propuesto en la sección anterior, proporciona la base para definir un conjunto de elementos clasificadores para la taxonomía (Tabla I).

Figura 7. Metamodelo Base para definir la Estructura Taxonómica para la TxA.

La definición de la TxA contiene también un proceso de

clasificación y un conjunto de reglas [21], [9] para controlar la integridad, la unicidad, la consistencia y la recursividad de la información especificada.

El método de clasificación explica cómo se clasifican los objetos bajo estudio dentro de la taxonomía, de forma repetida

y sin ambigüedades. Se define el proceso (Tabla II) en el cual cada paso responde una pregunta específica. Cada pregunta se formula de acuerdo a si se valora un caso de estudio (1) o una metodología (2) de desarrollo para sistemas interactivos.

A continuación se describe la ejecución detallada del proceso.

TABLA I. ELEMENTOS CLASIFICADORES PARA LA TXA.

Estructura Taxonómica de la Actividad, una sola Capa

Neg

ocio

Función Dato Meta Quién Base Soporte Gestión C I-A C I-A W E R O Re Cl Wo

GranBaja

Gran Alta

Sist

ema

Función Dato Meta Quién Base Soporte Gestión U I U I S E R O Re Us Si

Gran Baja

Gran Alta

C: Intención del Cliente I-A: Inter-Acción W: Intención del Worker E: Entrada R: Resultado O: Objetivo Re: Regla Cl: Cliente Wo: Trabajador (Worker) S: Intención del Sistema I: Interacción Us: Usuario U: Intención del Usuario Si: Sistema

A. Relevancia: La persona que aplica la taxonomía decide si el caso de

estudio o la metodología de desarrollo califican para ser

clasificado con la taxonomía. Su decisión está basada en dos criterios independientes:

• Alcance: Los estudios y metodologías candidatas deben considerar aspectos del desarrollo de sistemas interactivos, funcionalidad, desarrollo de la interfaz de usuario, colaboración, en general de la Interacción Humano Computador.

• Nivel de especificación: Es necesario contar con un

reporte detallado de los estudios a analizar. Así se reduce el margen de interpretación al contestar las preguntas definidas para el proceso

B. Caracterización básica: El propósito es identificar aspectos básicos de los estudios

a analizar. Para los casos de estudio se realiza una caracterización de los procesos que especifican a través de casos de uso, por ejemplo, así como de las metas de negocio a las que apuntan dichos procesos. Para las metodologías, se identifica qué aspecto del desarrollo de los sistemas interactivos se centran en desarrollar.

TABLA II. PROCESO DE CLASIFICACIÓN DE LA TXA.

aso Pregunta Tema 1. ¿El estudio abarca aspectos del desarrollo de sistemas interactivos? Relevancia 2. (1): ¿Cuáles son los procesos que especifica?

(2): ¿En qué aspecto del desarrollo de sistemas interactivos se enfoca? Caracterización básica

3. (1): ¿En qué niveles de abstracción (negocio, sistema) se encuentra especificada la información? (2): ¿En qué niveles de abstracción (negocio, sistema) se proveen elementos de modelado?

Niveles de Abstracción

4. (1): ¿Se diferencian los tipos de actividad (base, soporte, gestión)? (2): ¿Qué elementos de modelado provee para clasificar los tipos de actividad (base, soporte, gestión)?

Tipo de Actividad

5. (1): ¿Cómo clasifica las intenciones del actor de negocio, las intenciones del worker y sus inter-acciones separadamente? (2): ¿Qué elementos de modelado provee para clasificar las intenciones del usuario, las intenciones del worker y sus inter-acciones separadamente?

Especificación a nivel de negocio (si aplica). Si no aplica, pasar a la especificación a nivel de sistema (paso 10)

6. (1): ¿Cómo se diferencia el nivel de granularidad en el que se especifican las actividades a nivel de negocio? (2): ¿Qué elementos de modelado provee para diferenciar el nivel de granularidad en el que se especifican las actividades a nivel de negocio?

Nivel de granularidad a nivel de negocio

7. (1): ¿Cómo se diferencian los roles que intervienen en las actividades a nivel de negocio? (2): ¿Qué elementos de modelado provee para diferenciar los roles que intervienen en las actividades a nivel de negocio?

Roles a nivel de negocio

8. (1): ¿Cómo se clasifican los objetivos a los cuales contribuyen la ejecución de las actividades, a nivel de negocio? (2): ¿Qué elementos de modelado provee para clasificar los objetivos a los cuales contribuye la ejecución de las actividades a nivel de negocio?

Metas-Objetivos a nivel de negocio

9. (1): ¿Cómo se clasifican los datos relacionados con la ejecución de las actividades, a nivel de negocio? (2): ¿Qué elementos de modelado provee para clasificar los datos relacionados con la ejecución de las actividades a nivel de negocio?

Datos a nivel de negocio

10. (1): ¿Cómo se clasifican las intenciones del actor de sistema, las responsabilidades del sistema y sus interacciones separadamente? (2): ¿Qué elementos de modelado provee para clasificar las intenciones del actor de sistema, las responsabilidades del sistema y sus interacciones separadamente?

Especificación a nivel de sistema.

11. (1): ¿Cómo se diferencia el nivel de granularidad en el que se especifican las actividades a nivel de sistema? (2): ¿Qué elementos de modelado provee para diferenciar el nivel de granularidad en el que se especifican las actividades a nivel de sistema?

Nivel de granularidad a nivel de sistema

12. (1): ¿Cómo se diferencian los roles que intervienen en las actividades a nivel de sistema? (2): ¿Qué elementos de modelado provee para diferencian los roles que intervienen en las actividades a nivel de sistema?

Roles a nivel de sistema

13. (1): ¿Cómo se clasifican los objetivos a los cuales contribuyen la ejecución de las actividades, a nivel de sistema? (2): ¿Qué elementos de modelado provee para clasificar los objetivos a los cuales contribuye la ejecución de las actividades a nivel de sistema?

Metas-Objetivos a nivel de sistema

14. (1): ¿Cómo se clasifican los datos relacionados con la ejecución de las actividades, a nivel de sistema? (2): ¿Qué elementos de modelado provee para clasificar los datos relacionados con la ejecución de las actividades a nivel de sistema?

Datos a nivel de sistema

15. Discusión acerca de la Clasificación realizada Conclusión

C. Desde Niveles de Abstracción hasta Datos: Se realiza el análisis de clasificación ubicando elementos

de la actividad de acuerdo a los elementos clasificadores definidos en la Tabla I.

Finalmente, y una vez clasificada la información, se pasa a identificar qué clasificadores no han sido contemplados en la especificación, y es necesario incorporar. También es posible que se identifiquen clasificadores necesarios a incluir en la definición de la taxonomía.

Es importante resaltar que no toda la información que describe un sistema es necesaria para su incorporación en la Taxonomía. Solo es útil la información que se requiere que se transfiera al nivel de la tecnología.

La taxonomía también define una serie de reglas para controlar la integridad, la unicidad, la consistencia y la recursividad de la información especificada tal y como lo sugiere [9]. En este sentido, aplican la mayoría de reglas definidas por la arquitectura de Zachman [24].

• Regla 1: Las columnas Función, Dato, Meta y Quién no tienen orden. Todas son igualmente importantes.

• Regla 2: La estructura taxonómica interna de cada columna debe mantener el mismo orden.

• Regla 3: Cada columna Función, Dato, Meta y Quién tiene un metamodelo base. Es base porque es el mismo para cada celda en la misma columna.

• Regla 4: El metamodelo base de cada columna debe ser único. La unicidad es esencial para cualquier esquema de clasificación útil.

• Regla 5: Cada fila Negocio, Sistema, representa una perspectiva distinta y única. Cada una trata con distintas restricciones del modelo.

• Regla 6: La estructura taxonómica interna de cada fila debe mantener el mismo orden.

• Regla 7: Cada celda es única, porque tiene un único modelo básico, que hace a cada columna única y pertenece a una sola perspectiva.

• Regla 8: La composición o integración de todos los modelos de las celdas en una fila constituye un modelo completo desde la perspectiva de esa fila.

• Regla 9: La lógica es recursiva.

V. ESTADO DEL ARTE El concepto “Taxonomía”, tiene sus raíces en el griego

“Taxis = ordenación” y “Nomos = reglas” y según el diccionario de la RAE [25] se define como “Ciencia que trata de los principios, métodos y fines de la clasificación”. Normalmente, los trabajos relacionados con la definición de Taxonomías en Ingeniería de Software y en HCI, no hacen referencia a esta definición, aunque como lo reconoce [26] sí se menciona que el término fue inicialmente utilizado en las ciencias biológicas y que se ha ido expandiendo a cualquier “clasificación ordenada”.

Por otro lado, la clasificación es una actividad inherente a los humanos, pero cuando se habla de “Taxonomía” puede resultar un poco intimidante y complejo. Puede ser por el hecho de que definir y utilizar una taxonomía suele ser más

exhaustivo que el hecho de definir y utilizar una clasificación o una estructura [27].

La revisión de la literatura relacionada con Taxonomías en el ámbito de la Ingeniería de Software (IS) y de la HCI, permite realizar una recopilación de la información que clasifican para compararla con la Taxonomía de la Actividad para Sistemas Interactivos definida en este trabajo (Tablas III y IV).

Los criterios de comparación se fundamentaron en el metamodelo base definido en la sección III.E: Área, Qué Clasifica, Clasificadores, Clasificadores por Nivel de Abstracción, ¿Define Proceso de Clasificación?, ¿Define Estructura taxonómica?, ¿Define Reglas de la Taxonomía?.

El análisis del conjunto de propuestas permitió concluir que cada taxonomía, a diferencia de la TxA, es definida para un dominio muy específico. La mayoría de taxonomías se utilizan para comparar, identificar ventajas y carencias relacionadas con las características de propuestas que encajan en el conjunto de clasificadores definidos para dichas taxonomías.

Es posible observar también que sólo las propuestas basadas en el Framework de Zachman [24] definen las características generales “Proceso de Clasificación”, “Estructura Taxonómica” y “Reglas”. Adicionalmente, la mayoría de las propuestas analizadas no tienen definidos sus clasificadores de acuerdo a la separación en niveles de abstracción, como sí lo hace la TxA.

VI. EJEMPLOS DE USO EN HCI PARA LA TXA En esta sección se muestra la utilidad de la TxA en: (1) La

incorporación de HCI en los procesos de desarrollo de software; (2) la evaluación e integración de lenguajes y/o procesos de desarrollo de software; y (3) la especificación de los modelos de ejecución de los sistemas interactivos.

A. Utilidad de la TxA para la incorporación de HCI en los procesos de desarrollo de software Se define una aproximación metodológica para la

Incorporación de HCI en procesos de desarrollo de software mediante la TxA. Dicha incorporación se orienta específicamente a la evaluación de la usabilidad durante la fase de requisitos del desarrollo de software, tomando como insumo la información proporcionada por un Modelo de Casos de Uso. La información detallada para este escenario de uso de la TxA se presenta en [38]. Los resultados de la evaluación incluyen un reporte que contiene un listado de observaciones generales al Caso de Uso analizado, seguido por el listado de comentarios y recomendaciones relacionados con cada uno de los pasos especificados en el Flujo Primario del Caso de Uso. Se identifican carencias en la definición de Patrones de Interacción, Tareas de Feedback y de Awareness, a partir de la especificación de la funcionalidad de un sistema, lo cual permite incorporar aspectos del diseño de la interacción, del diseño de interfaces de usuario, desde el inicio del proceso de desarrollo de los productos software. Esta incorporación aporta positivamente en los niveles de usabilidad del sistema.

TABLA III. DESCRIPCIÓN DE TAXONOMÍAS EN INGENIERÍA DE SOFTWARE Y HCI.

Propuesta Área Qué clasifica Clasificadores

Taxonomía REST [21]

IS Métodos para alinear la Ing. De Requisitos (IR) con las Pruebas de Software (PS)

- Complejidad: (Número de métodos, Ramificaciones, Métodos intermedios, Tipo de links “con IR”, Tipo de links “entre fases”, Tipo de links “con PS”). - Enfoque / alcance: (Proporción IR:PS, Alcance).

Una Taxonomía de Métodos de Desarrollo de software

[28]

IS Métodos usados en el desarrollo de software

- Conceptual (Orientado al problema, Orientado al producto). - Formal (Orientado al problema, Orientado al producto).

Taxonomía Zachman [24]

IS Información contenida en los modelos que representan las arquitecturas empresariales.

- Datos (Qué) - Proceso (Cómo) - Red (Dónde) - Personas (Quién) - Tiempo (Cuándo) - Motivación (Por Qué)

Taxonomía de Ingeniería de Software [29]

IS Artefactos utilizados en la Ingeniería de Software según el SWEBOK [55].

- Datos (Qué) - Proceso (Cómo) - Red (Dónde) - Personas (Quién) - Tiempo (Cuándo) - Motivación (Por Qué)

Taxonomía de Riesgos en Desarrollo de Software [30]

IS Riesgos asociados con el desarrollo de un proyecto que involucra software.

- Clase: (Ingeniería de Producto, Ambiente de Desarrollo, Restricciones de Programa). - Elemento: (Requisitos,…, Especialidades en Ingeniería, Procesos de desarrollo,…, Ambiente de trabajo, Recursos,…, Interfaces de programa). - Atributo: (Estabilidad,…, Escala, Formalidad,…, Control de producto, Planeación,…, Facilidades).

Taxonomía para Adopción de Tecnología [31]

HCI Los factores que afectan la aceptación de tecnología y la intención del usuario en utilizar un producto.

- Tarea - Producto: (No-interfaz, Interfaz:, Alta interacción) - Contenido de información - Social: (Contexto del sistema, Usuario y Estados mentales y emocionales) - Intermediario

Taxonomía de HCI [26]

HCI Un rango de variables que impactan sobre los tipos de posibles interacciones humano computador, incluyendo interacciones simbióticas.

- Componentes: (Usuario, Agente autónomo sensible/computador, display de contenido/datos) - Interacciones activas y pasivas - Tipos de respuestas de usuarios: (Explícitas, implícitas)

Taxonomía de Sistemas de Administración de Flujo de

Trabajo para Computación en Malla [32]

IS Propuestas para construir y ejecutar workflows sobre grids.

- Diseño del workflow: (Estructura, Modelo/especificación, Sistema de Composición, Restricciones de calidad). - Planeación del workflow: (Arquitectura, Toma de decisiones, esquema de planeación, estrategias, estimación de rendimiento). - Recuperación de la información: (Estática, histórica, dinámica) - Tolerancia a fallos: (Nivel de tareas, nivel de workflow) - Movimiento de datos: (dirigido por usuario automático)

Taxonomía para Análisis Visual [33]

HCI Interacciones de los usuarios en aplicaciones interactivas de análisis visual

- Visualización de la información: (Cambios en los datos, Cambios en la visualización) - Razonamiento: (Cambios en los datos, Cambios en el razonamiento) - Procesamiento de datos: (Cambios en los datos, Cambios en el procesamiento)

Taxonomía de aplicaciones móviles [34]

IS-HCI

Características de aplicaciones móviles

- Temporal; (Síncrono, Asíncrono) - Comunicación: (Informacional, Reporte, Interaccional) - Transacción: (Transaccional, No-Transaccional) - Público: (Público, Privado) - Multiplicidad: (Individual, Grupo) - Ubicación: (Basado en localización, No basado en localización) - Identidad: (Basado en la identidad, No basado en la identidad)

Una Taxonomía de Gestos en Interacción Humano

Computador [35]

HCI Interacciones humano computador basadas en gestos

- Dominio de la aplicación: (Escritorio, Móvil y pervasive, Ubicua, Virtual y RA, Juegos, Tecnologías adaptativas, Comunicación, Entretenimiento, Interacciones multimodales) - Tecnologías habilitadas: (Perceptiva, No-Perceptiva) - Respuesta del sistema: (Visual, Audio, Comandos) - Estilos de gestos: (Deíctico, Gesticulación, Manipulación, Semáforos, Lenguaje de Señas)

Taxonomía de Interrupción Humana [36]

HCI La interrupción humana en HCI - Fuente de la interrupción - Características de la persona que recibe la interrupción - Método de coordinación - Significado de la interrupción - Método de expresión - Canal de transporte - Actividad humana cambiada por la interrupción - Efecto de la interrupción

Taxonomía de Niveles de Automatización [37]

IS- HCI

Tipos de soporte a la automatización en la Administración de Tráfico Aéreo (ATM)

- Adquisición de la información: (Manual, Soportado por artefactos, Por niveles de automatización) - Análisis de la información: (Basado en el trabajo de la memoria, Soportado por artefactos, Por niveles de automatización) - Decisión y selección de la acción: (Decisión humana, Soportado por artefactos, Soporte automático, Soporte automático rígido, Por niveles de automatización) - Implementación de la acción: (Control y acción manual, Soportada por

Propuesta Área Qué clasifica Clasificadores artefactos, Soporte paso a paso, Bajo nivel de soporte, Alto nivel de soporte, Por niveles de automatización)

Taxonomía para sistemas interactivos colaborativos [9]

IS-HCI

Información expresada en los modelos que especifican los sistemas que dan soporte al trabajo colaborativo

- Datos (Qué) - Proceso (Cómo) - Red (Dónde) - Personas (Quién) - Tiempo (Cuándo) - Motivación (Por Qué)

TABLA IV. CARACTERÍSTICAS GENERALES DE TAXONOMÍAS EN INGENIERÍA DE SOFTWARE Y HCI.

Propuesta Clasificadores por nivel de abstracción Proceso de

clasificación Estructura taxonómica

Reglas de la taxonomía

Taxonomía REST [21] -- Si Si No Una Taxonomía de Métodos de

Desarrollo de software [28]

Conceptual (sistema) Formal (tecnología)

Si Si No

Taxonomía Zachman [24]

Alcance Modelo de Negocio Modelo de Sistema Modelo de Tecnología Componentes

No Si Si

Taxonomía de Ingeniería de Software [29]

Alcance Modelo de Negocio Modelo de Sistema Modelo de Tecnología Componentes

Si Si Si

Taxonomía de Riesgos en Desarrollo de Software [30]

-- Si Si No

Taxonomía para Adopción de Tecnología [31]

-- No Si No

Taxonomía de HCI [26] -- No No No Taxonomía de Sistemas de Administración de Flujo de

Trabajo para Computación en Malla [32]

- Diseño del workflow - Planeación del workflow

No Si No

Taxonomía para Análisis Visual [33]

-- Si Si No

Taxonomía de aplicaciones móviles [34]

-- No Si No

Una Taxonomía de Gestos en Interacción Humano

Computador [35]

-- No Si No

Taxonomía de Interrupción Humana [36]

-- Si No No

Taxonomía de Niveles de Automatización [37]

-- No Si No

Taxonomía para sistemas interactivos colaborativos [9]

Modelo de Negocio Modelo de Sistema Modelo de Tecnología

Si Si Si

El trabajo realizado en [38] sugiere que las especificaciones

de la actividad capturadas por un ingeniero de desarrollo a través de plantillas centradas en flujos y desde su propia perspectiva, no incluyen los aspectos de HCI necesarios para el desarrollo de aplicaciones interactivas. Es decir, las plantillas actuales que se utilizan para especificar los Casos de Uso no resultan estar lo suficientemente estructuradas para capturar información de la estructura y función de la interfaz de usuario. En este sentido, es recomendable definir una nueva plantilla que permita capturar información complementaria a la especificación de los Casos de Uso, con respecto a incidencias relacionadas con la usabilidad.

B. Utilidad de la TxA para la evaluación e integración de lenguajes y/o procesos de desarrollo de software En esta sección se analiza un conjunto de propuestas

metodológicas que se encuentran actualmente en la literatura en relación con el desarrollo de sistemas interactivos y se presenta la clasificación de sus elementos de modelado de la

actividad de acuerdo a la Taxonomía de la Actividad para Sistemas Interactivos. Cada propuesta se distingue por los aspectos (capas) en los que se centra para especificar la actividad (Tabla V), Funcionalidad (Fun), Colaboración (Colab), Interfaz de Usuario (IU), Usabilidad (Usab).

Los elementos de modelado de cada propuesta se ubican en la TxA de acuerdo al aspecto que desea modelar (Fig. 8).

La clasificación tiene como fin evaluar la capacidad de cada propuesta metodológica para representar las actividades que realizan los sistemas modelados por las mismas. Se clasifica la notación y no la metodología porque la notación es la que describe la información del producto, en este caso el sistema interactivo.

Se presenta sólo la clasificación resultante para las capas Funcionalidad y Colaboración por cuestiones de espacio (Fig. 9 a 12).

TABLA V. ASPECTOS EN LOS QUE SE ENFOCAN LAS PROPUESTAS ANALIZADAS.

Propuesta/Aspecto Fun Colab IU Usab

(1) OpenUp [39] X (2) Wisdom [40] X X (3) Model Driven Software Development Framework [41] X

(4) UCD with Activity Modeling [42] X X (5) CIAN [43] X (6) TOUCHE [44] X X (7) Traetteberg [45] X (8) Methodology for Developing UI to Workflow IS [46] X

(9) Limbourg [18] X (10) Dygimes [47] X (11) IDEAS [48] X (12) MPIu+a [49] X (13) HAMSTERS [50] X (14) TD-MBUID [9] X

Figura 8. Estructura de la Clasificación de elementos de modelado con la TxA.

La clasificación de los elementos de modelado de las

propuestas analizadas mediante la TxA, permite visualizar la distribución de los elementos de modelado de la actividad que

provee cada metodología analizada, de acuerdo con la Estructura Taxonómica de la Actividad propuesta.

Se observa que a diferencia de las demás propuestas, el OpenUp y TD-MBUID proveen elementos de modelado de la actividad en los que se separa claramente los niveles de abstracción Negocio y Sistema. Aunque algunas de las demás propuestas proveen elementos de modelado que se ubican en los dos niveles de abstracción, dichas propuesta no lo especifican explícitamente.

En general, la mayoría de propuestas utilizan la notación CTT [51] para realizar modelado de tareas y la notación UML [52] para realizar modelado de la funcionalidad y de dominio. Dichas notaciones se utilizan también como base cuando se requiere introducir nuevos elementos de modelado como se hace por ejemplo en WISDOM [40], IDEAS [48] y HAMSTERS [50].

Particularmente, para esta última propuesta sería interesante analizar si lo que interesa modelar son las tareas de entrada y/o salida, o más bien por ejemplo tareas de feedback (cada vez que el sistema hace algo y el usuario percibe el avance o el resultado de dicha actividad), de awareness (es la información que presenta el sistema acerca de lo que están haciendo los otros usuarios en tiempo real, ej: la imagen del lápiz de Skype que indica que la otra persona está escribiendo), de seguridad, de error, de estado, etc.

Es interesante cómo en la propuesta metodológica [46] se introducen elementos de modelado de Workflow relacionados con la ubicación (dónde se ejecuta la actividad), como “Organizational Unit” y también elementos relacionados con el tiempo (cuándo se ejecuta la actividad), como el concepto de “Agenda”. Elementos que podrían integrarse a la definición de la TxA para tener una especificación más completa de la Actividad en los sistemas interactivos.

Figura 9. Clasificación Taxonómica de la Actividad, Capa Funcionalidad (Tipo de Actividad).

Figura 10. Clasificación Taxonómica de la Actividad, Capa Funcionalidad (Dato, Meta, Quién).

Figura 11. Clasificación Taxonómica de la Actividad, Capa Colaboración (Tipo de Actividad).

Figura 12. Clasificación Taxonómica de la Actividad, Capa Colaboración (Dato, Meta, Quién).

Es importante resaltar también que propuestas como las de TOUCHE [44] e IDEAS [48] proveen un conjunto de plantillas para capturar información relacionada con la actividad en los sistemas interactivos. Y aunque no se provee alguna notación en dicha especificación, es útil analizar cómo se podría integrar esta información a la TxA propuesta.

Un análisis conjunto de las propuestas permite concluir que ninguna de ellas realiza una distinción sintáctica para soportar de manera separada la clasificación del Tipo de Actividad en las categorías Base, Soporte y Gestión, es decir, para cualquier tipo de actividad se usarían los mismos elementos de modelado. Y aunque es posible clasificar las actividades de un sistema informático en dichas categorías, esta falta de elementos de modelado para cada propuesta genera un bajo nivel de expresividad y semántica para modelar cualquier aspecto distinto a los que modela cada propuesta.

Se observa también que las propuestas analizadas proveen pocos elementos de modelado de la actividad en el nivel de abstracción de negocio, tanto en el nivel alto como bajo de granularidad. Es necesario analizar si estos elementos serían suficientes para modelar la actividad en este nivel y también qué otros elementos de modelado se podrían definir para diferenciar los tipos de actividad. En el nivel de abstracción del sistema se observa una cantidad mayor de elementos de modelado que los que aparecen el en nivel de abstracción de negocio, lo que significa que el conjunto de las propuestas se centra más en detallar la información de los sistemas interactivos en este nivel. Sin embargo, no sólo la cantidad de elementos de modelado debe ser el único indicador válido, por lo tanto, es necesario analizar otros elementos o aspectos o atributos de la clasificación, por ejemplo, desde el punto de vista de la calidad de las notaciones podría ser de interés analizar el nivel de expresividad, la economía, la completitud, redundancia, etc [53], además de las capacidades que tiene cada lenguaje para la integración.

C. Utilidad de la TxA para la especificación de los modelos de ejecución de los sistemas interactivos La definición de la estructura taxonómica de la TxA es la

base para la especificación de modelos de ejecución como los que se mencionan en [54]. Como se muestra en este mismo trabajo, a partir de dichos modelos es posible implementar herramientas para la generación de código y estructura funcional de aplicaciones interactivas.

VII. CONCLUSIONES Y TRABAJO FUTURO La Clasificación del Modelado de la Actividad es necesaria

porque la principal función del software es automatizar la labor. Actualmente, la automatización del software se apoya en lenguajes y elementos de modelado como máquinas de estado, diagramas de secuencia, diagramas de actividad, redes de Petrí, CTT. Es posible que sea muy complejo expresar completamente un sistema con estas fuentes o no existe todavía el lenguaje que sirva para esto. Es necesario entonces encontrar o definir un lenguaje que tenga los clasificadores mínimos pero que abarque desde el nivel del negocio hasta el nivel del sistema, es decir, que el lenguaje tenga también los

clasificadores máximos, que sea extensible. De otro lado, se requiere que el lenguaje tenga clasificadores que intervienen en múltiples vistas donde se captura más información.

El hecho de llevar un proceso formal de integración entre propuestas, en este caso la Teoría de la Actividad y la Clasificación del Modelado de la Actividad, provee un soporte teórico en la definición de un metamodelo que describa los elementos relacionados con la Actividad y en la definición en sí de la Taxonomía de la Actividad para Sistemas Interactivos.

La clasificación de las Propuestas Metodológicas haciendo uso de la Estructura Taxonómica de la Actividad, muestra la potencialidad que tiene dicha Taxonomía para ser utilizada como Marco de Evaluación y posiblemente en un mapa de ruta de la actividad que el ingeniero debe seguir en la especificación y desarrollo de un sistema interactivo. Es necesario entonces definir un proceso que integre los distintos modelos necesarios para especificar la actividad.

A partir del análisis de propuestas metodológicas se requiere también analizar qué otros atributos son necesarios para completar la taxonomía, para extenderla, formalizarla y definir la taxonomía ideal de la clasificación del modelado de la actividad que facilite el diseño del dominio de información para que de esta forma se obtenga un mejor diseño de las interfaces de usuario y del sistema interactivo en general.

Es necesario ejecutar un proceso de evaluación y validación que permita establecer si los elementos clasificadores de la Taxonomía de la Actividad son los mínimos y a la vez los suficientes para describir un sistema interactivo completamente funcional y a partir de esto pasar desde el nivel conceptual al nivel práctico, es decir, que la taxonomía sea soportada por una herramienta metodológica, conceptual y tecnológica para ser utilizada por los ingenieros y las empresas que se dedican al desarrollo de software.

El proceso de validación será complementado con el diseño y aplicación de un conjunto de encuestas dirigidas a estudiantes y a expertos en el área de HCI, sobre los elementos de modelado más apropiados para modelar la actividad en sistemas interactivos, tomando como base las propuestas metodológicas analizadas en este trabajo.

REFERENCIAS [1] Y. Engeström, "Expansive Learning at Work: toward an activity

theoretical reconceptualization," Journal of Education and Work, vol. 14, 2001.

[2] G. Georg, G. Mussbacher, D. Amyot, D. Petriu, L. Troup, S. Lozano-Fuentes, et al., "Synergy between Activity Theory and goal/scenario modeling for requirements elicitation, analysis, and evolution," Information and Software Technology, vol. 59, pp. 109-135. 2015.

[3] G. Georg, "Activity Theory and its Applications in Software Engineering and Technology". Technical Report. Colorado State University, Fort Collins, Colorado. 2011.

[4] B. A. Nardi, "Activity Theory and Human-Computer Interaction,"Context and Consciousness: Activity Theory and Human-Computer Interaction, M. Press, Ed., ed. Cambridge,MIT Press, 1996, p. 5.

[5] G. Georg and L. Troup, "Experiences Developing a Requirements Language Based on the Psychological Framework Activity Theory," OCL@MoDELS, 2013, pp. 63-72.

[6] C. R. B. d. Souza, "Interpreting Activity Theory as a Software Engineering Methodology," Second European Conference on Computer Supported Cooperative Work (ECSCW'03), 2003, pp. 249-264.

[7] G. C. Neto, A. S. Gomes, J. Castro, and S. Sampaio, "Integrating activity theory and organizational modeling for context of use analysis," Proceedings of the 2005 Latin American conference on Human-computer interaction, Cuernavaca, Mexico, 2005.

[8] A. K. Shuja and J. Krebs, IBM Rational Unified Process Reference and Certification Guide—Solution Designer: Pearson Education, 2008.

[9] W. J. Giraldo, "Marco de Desarrollo de Sistemas Software Interactivos Basado en la Integración de Procesos y Notaciones," Phd Doctoral, Escuela Superior de Informática de Ciudad Real, Universidad de Castilla-La Mancha, Ciudad Real, 2010.

[10] L. Vygotski, Mind in Society: Development of Higher Psychological Processes, 1980.

[11] P. Collins, S. Shukla, and D. Redmiles, "Activity Theory and System Design: A View from the Trenches," Computer Supported Cooperative Work (CSCW), vol. 11, pp. 55-80, 2002.

[12] L. Constantine, "Human Activity Modeling: Toward A Pragmatic Integration of Activity Theory and Usage-Centered Design," Human-Centered Software Engineering, A. Seffah, J. Vanderdonckt, and M. Desmarais, Eds., ed: Springer London, 2009, pp. 27-51.

[13] H. Hasan, "Integrating IS and HCI using activity theory as a philosophical and theoretical basis," Australian Journal of Information Systems, vol. 6, pp. 44-55, 1998.

[14] V. Kaptelinin, B. A. Nardi, and C. Macaulay, "Methods & tools: The activity checklist: a tool for representing the “space” of context," interactions, vol. 6, pp. 27-39, 1999.

[15] M. Korpela, H. A. Soriyan, and K. C. Olufokunbi, "Activity Analysis as a Method for Information Systems Development: General Introduction and Experiments from Nigeria and Finland," Scandinavian Journal of Information Systems, vol. 12, 2000.

[16] G. G. d. C. Neto, A. S. Gomes, and J. B. d. Castro, "Mapping Activity Theory Diagrams into i* Organizational Models," JCS&T, vol. 5, 2005.

[17] W. J. Giraldo, M. L. Villegas, and C. A. Collazos, "Incorporation of HCI: Classification of activity modeling," Computing Colombian Conference (9CCC), 2014 9th, 2014, pp. 150-155.

[18] Q. Limbourg, "Multi-Path Development of User Interfaces," Phd. , Université catholique de Louvain, Louvain-la-Neuve, 2004.

[19] K. Kuutti, "The concept of activity as a basic unit of analysis for CSCW research," in Second European Conference on Computer Supported Cooperative Work (ECSCW'91), 1991, pp. 249-264.

[20] Y. Engeström, Learning by Expanding: An activity-theoretical approach to developmental research: Orienta-Konsultit Oy, 1987.

[21] M. Unterkalmsteiner, R. Feldt, and T. Gorschek, "A taxonomy for requirements engineering and software test alignment," ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 23, p. 16, 2014.

[22] B. H. Kwasnik, The Role of Classification Structures in Reflecting and Building Theory, 1992.

[23] D. I. K. Sjoberg, T. Dyba, and M. Jorgensen, "The Future of Empirical Methods in Software Engineering Research," 2007 Future of Software Engineering, 2007.

[24] J. F. Sowa and J. A. Zachman, "Extending and formalizing the framework for information systems architecture " IBM Syst. J, pp. 590-616, 1992.

[25] R. A. E. (RAE), "Diccionario de la Lengua Española", 2015. www.rae.es.

[26] J. Lessiter, J. Freeman, A. Miotto, and E. Ferrari, "Ghosts in the Machines: Towards a Taxonomy of Human Computer Interaction," Springer International Publishing Switzerland 2014, pp. 21–31, 2014.

[27] G. Oxton, J. Chmaj, and D. Kay, "Perspectives on Taxonomy, Classification, Structure and Find-ability." Consortium for Service Innovation. Accessed: 07/2015. from http://www.serviceinnovation.org/included/docs/kcs_taxonomy.pdf.

[28] B. I. Blum, "A taxonomy of software development methods," Commun. ACM, vol. 37, pp. 82-94, 1994.

[29] P. Stoll, A. Wall, and C. Norström, "Applying the Software Engineering Taxonomy". Technical Report. 2009.

[30] M. Carr, S. Konda, I. Monarch, C. Walker, and F. Ulrich, "Taxonomy-Based Risk Identification" Software Engineering Institute, Carnegie Mellon University CMU/SEI-93-TR-006, 1993.

[31] C. O. Seneler, N. Basoglu, and T. U. Daim, "A Taxonomy for Technology Adoption: A Human Computer Interaction Perspective", Management of Engineering & Technology, 2008. PICMET 2008. Portland International Conference on, Cape Town, South Africa, 2008, pp. 2208 - 2219.

[32] J. Yu and R. Buyya, "A Taxonomy of Workflow Management Systems for Grid Computing," Journal of Grid Computing, vol. 3, pp. 171-200, 2005.

[33] T. von Landesberger, S. Fiebig, S. Bremm, A. Kuijper, and D. Fellner, "Interaction Taxonomy for Tracking of User Actions in Visual Analytics Applications," Handbook of Human Centric Visualization, W. Huang, Ed., ed: Springer New York, 2014, pp. 653-670.

[34] R. Nickerson, J. Muntermann, U. Varshney, and H. Isaac, "Taxonomy Development in Information Systems: Developing a Taxonomy of Mobile Applications". Technical Report. 2009.

[35] M. Karam and m. c. schraefel, "A Taxonomy of Gestures in Human Computer Interactions" University of Southampton, Technical Report. 2005.

[36] D. C. McFarlane, "Interruption of People in Human-Computer Interaction" Doctor of Science, Faculty of The School of Engineering and Applied Science. The George Washington University, 1998.

[37] L. Save and B. Feuerberg, "Designing Human-Automation Interaction: a new level of Automation Taxonomy," Human Factors: a view from an integrative perspective., 2012.

[38] M. L. Villegas, C. A. Collazos, J. G. William, and J. M. Gonzalez, "Incorporación de HCI: Validación de la Usabilidad en Casos de Uso mediante la Taxonomía de la Actividad," 10 Congreso Colombiano de Computación (10CCC), Bogotá, Colombia, 2015.

[39] R. Balduino. Introduction to OpenUP (Open Unified Process). Eclipse site. 2007. Available: www.eclipse.org/epf/general/OpenUP.pdf.

[40] D. N. J. Nunes, "Object Modeling for User-Centered Development and User Interface Design: The Wisdom Approach" phd Doctorade, Universidade da Madeira, Funchal, 2001.

[41] S. E. Cubillo, "Methodological Integration of Communication Analysis into a Model-Driven Software Development Framework" Doctorado, Universidad Politécnica de Valencia, 2011.

[42] L. L. Constantine, "Activity Modeling: Toward a Pragmatic Integration of Activity Theory with Usage-Centered Design". Technical Report. 2006.

[43] A. I. Molina, M. A. Redondo, M. Ortega, and U. Hope, "CIAM: A methodology for the development of groupware user interfaces," Journal of Universal Computer Science(JUCS), vol. 14, 2008.

[44] V. M. R. Penichet, "Modelo de Proceso para el Desarrollo de Interfaces en Entornos CSCW Centrado en los Usuarios y Dirigido por Tareas" Phd, Castilla-La Mancha, Albacete, 2007.

[45] H. Trætteberg, "Model-based User Interface Design" Phd., Department of Computer and Information Sciences, Norwegian University of Science and Technology, 2002.

[46] J. G. Garcia, "A Methodology for Developing User Interfaces to Workflow Information Systems" Doctor of Philosophy in Economics and Management Sciences, Université catholique de Louvain, 2010.

[47] k. Luyten, "Dynamic User Interface Generation for Mobile and Embedded Systems with Model-Based User Interface Development" PhD. thesis, , Universiteit Limburg, 2004.

[48] M. D. Lozano, "Entorno Metodológico Orientado a Objetos para la Especificación y Desarrollo de Interfaces de Usuario" Phd., Universidad Politecnica de Valencia, 2001.

[49] T. Granollers, "Mpiu+A. Una Metodología que Integra la Ingeniería del Software, La Interacción Persona Ordenador y la Accesibilidad en el Contexto de Equipos de Desarrollo Multidisciplinares" Doctorade, Llenguatges i Sistemes Informàtics, Lleida, Lleida, 2004.

[50] E. Barboni, J.-F. Ladry, D. Navarre, P. Palanque, and M. Winckler, "Beyond Modelling: An Integrated Environment Supporting Co-Execution of Tasks and Systems Models," in EICS’10, Berlin, Germany, 2010.

[51] F. Paternò, "ConcurTaskTrees: An Engineered Notation for Task Models," The Handbook Of Task Analysis For HCI, 2004, pp. 483-501.

[52] OMG. (1999, 12-10). Unified Modeling Language 1.3, Standard. Available: http://www.omg.org/spec/UML/1.3/

[53] D. L. Moody, "The "physics" of notations: a scientific approach to designing visual notations in software engineering," presented at the Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2, Cape Town, South Africa, 2010.

[54] W. J. Giraldo, M. A. Pineda, R. Arias, M. L. Villegas, and F. D. Giraldo, "Herramienta para la generaci´on de código Android a partir de modelos conceptuales," CIBSE 2015, 2015.

[55] A. Abran, J. W. Moore, P. Bourque, R. Dupuis, L. Tripp. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004: IEEE computer Society Press.

Maria L. Villegas, estudiante de Doctorado en Ciencias de la Electrónica, Grupo IDIS, Universidad del Cauca, Colombia. Msc en Ingeniería, Universidad EAFIT, 2012. Ing. De Sistemas y Computación de la Universidad del Quindío, 2002. Docente – Investigadora Grupo SINFOCI. Universidad del Quindío – Colombia.

César A. Collazos, doctor en Ciencias Mención Computación, Universidad de Chile, Enero 2004. Estancias postdoctorales en el Grupo CARL (Collaborative Applications Research Laboratory) de la Universidad de Chile (2004) y en el Grupo C.H.I.C.O (Computer Human Interaction and Collaboration) de la Universidad Castilla-La Mancha, España (2005). Ingeniero en Sistemas y Computación, Universidad de los Andes, Septiembre 1993.

Coordinador Grupo IDIS (Investigación y Desarrollo en Ingeniería del Software), Universidad del Cauca.

William J. Giraldo, doctor en Arquitectura y gestión de la información y del conocimiento en sistemas en red, Universidad de Castilla La Mancha, 2010. Magíster en informática avanzada, Universidad de Castilla La Mancha, 2008. Magíster en Automática, Universidad del Valle, 2000. Ingeniero Eléctrico, Universidad del Valle, 1996. Coordinador Grupo SINFOCI, Universidad del Quindío,

Colombia.

Juan M. González, profesor investigador titular A en la Facultad de Ciencias de la computación de la Universidad Autónoma de Puebla. Fue asistente de investigador de la Universidad Católica de Lovaina (UCL). Obtuvo una maestría en Ciencias de la Computación en el Instituto Nacional de Astrofísica, Óptica y Electrónica (México). Recibió un DEA y un doctorado en Sistemas de

Información en la Universidad Católica de Lovaina. Actualmente está trabajando en los diferentes proyectos relacionados con el diseño y desarrollo de interfaces de usuario en el Laboratorio belga de Interacción Persona Ordenador y el consorcio UsiXML.