Bashar Altakrouri
email: altakrouri@itm.uni-luebeck.de

Andreas Schrader
email: schrader@itm.uni-luebeck.de

Dynamic Interaction Plugins Deployment in Ambient Spaces

Keywords: Ambient Assisted Living, Natural User Interfaces, Kinetic Interactions, Dynamic Interaction Deployment, Sharing Interactions

A large-scale dynamic runtime deployment of existing and future interaction techniques remains an enduring challenge for engineering real-world pervasive computing ecosystems (ambient spaces). The need for innovative engineering solutions to tackle this issue increases, due to the ever expanding landscape of novel natural interaction techniques proposed every year to enrich interactive eco-systems with multitouch gestures, motion gestures, full body in motion, etc. In this paper, we discuss the implementation of Interaction Plugins as a possible solution to address this challenge. The discussed approach enables interaction techniques to be constructed as standalone dynamically deployable objects in ambient spaces during runtime.

Introduction

The human computer interaction (HCI) research continues to enrich users' interactions with real-world pervasive ecosystems (ambient spaces), with an increasing interest in designing for the whole body in motion as part of the Natural User Interface (NUI) paradigm [START_REF] England | Whole body interactions: An introduction[END_REF] [START_REF] Fogtmann | Kinesthetic interaction: revealing the bodily potential in interaction design[END_REF]. Various definitions of NUI can be found in the literature. Nonetheless, those definitions mostly refer to the user's natural abilities, practices, and activities to control interactive systems [START_REF] Iacolina | Natural interaction and computer graphics applications[END_REF] and can be simplified to voice-based and kinetic-based interactions [START_REF] Wachs | Vision-based hand-gesture applications[END_REF]. The later defines those interactions, which are mostly caused and characterized by motion and movement activities, ranging from pointing, clicking, grasping, walking, etc. [START_REF] Altakrouri | Towards dynamic natural interaction ensembles[END_REF]. Herein, we focus on motion-based interactions as a dominant subset of Kineticbased interactions. This type of interaction has been adopted widely in various commercial domains and became accessible to the end user, ranging from gaming (e.g., motion-controlled active play by Microsoft Kinect 1 or the Wii system 2 ), data browsing, navigation scenarios (e.g., tilting for scrolling photos as in iOS 3and Android4 devices) and many more.

Despite its success, the NUI paradigm poses a number of significant challenges to the design, engineering and deployment of NUI technologies, especially when considering a far more diverse and heterogenous user population, e.g., due to aging and demographic changes; unknown interaction context, due to increasing user mobility to unknown environmental settings at design time; and spontaneous construction of interactive environments in-situ at runtime. Thus the focus on isolated design of natural interface techniques will not be adequate in current and future ambient spaces, which rapidly experience increasing emergence of interconnected mobile devices, smart objects, and seamlessly integrated context-aware services.

In our previous work, we proposed a shift towards completely dynamic onthe-fly ensembles of interaction techniques at runtime. The Interaction Ensembles approach is defined as "Multiple interaction modalities (i.e., interaction plugins) from different devices are tailored at runtime to adapt the available interaction resources and possibilities to the user's physical abilities, needs, and context" [START_REF] Altakrouri | Towards dynamic natural interaction ensembles[END_REF]. This shift imposes new dissemination, deployment, and adaptation requirements for engineering interaction techniques and interactive systems for NUIs.

In this paper, we tackle some of the emerging deployment aspects of interaction in ambient spaces. We believe that the deployment of interaction in NUIs is a key player to enable a realistic adoption of NUIs in the design and engineering of interactive systems. The paper presents a detailed overview and a reference implementation for building and deploying interaction components for ambient spaces, called Interaction Plugins. We have previously defined an Interaction Plugin (IP) as "an executable component in ambient interactive systems that encapsulates a single natural interaction technique with a set of interaction tasks as input and delivers higher level interaction primitives to applications based on specific interaction semantics" [1] [START_REF] Altakrouri | Towards dynamic natural interaction ensembles[END_REF]. While our previous work in [START_REF] Altakrouri | Documenting natural interactions[END_REF] [START_REF] Altakrouri | Towards dynamic natural interaction ensembles[END_REF] proposed the concept of IP on a high conceptual level, the work presented in this paper primarily describes a detailed description of this approach and the resulting implementation.

To the best of our knowledge, there is no research specifically targeted at community-based creation and sharing of encapsulated natural interaction techniques for ambient spaces. The Interaction Plugin approach is based on three main design characteristics, namely, matching users and natural physical context, precise and extensible natural interaction descriptions (human and machine readable), and flexible deployment of interactions at runtime [START_REF] Altakrouri | Documenting natural interactions[END_REF].

Interaction Plugin approach fosters soft-wired (de-coupled) applications and devices in order to overcome the limitations of the static binding and to address one of the most challenging requirements in pervasive environments, namely the "come as you are" requirements. This approach matches calls from the HCI community to overcome various challenging issues for user interfaces in ambient spaces. Pruvost et al. [START_REF] Pruvost | User Interaction Adaptation within Ambient Environments[END_REF] noted that interaction environments are becoming increasingly heterogeneous and dynamic, hence they are no longer static and closed; the interaction context is becoming increasingly more complex; and, increasing adaptability is required for sustainable utility and usability.

We believe that investigating this approach is essential to understand some of the challenges for engineering interactive systems in ambient spaces and setting proper interaction dissemination guidelines, where interactions are becoming increasingly dynamic, adaptive and multi-modal. Our approach aims at avoiding mismatch problems between user's needs and device's offers by employing the best matching natural interaction techniques to the given context, hence the user independence (acceptability by permitting customizability) and usability qualities required by Wachs et al. [START_REF] Wachs | Vision-based hand-gesture applications[END_REF] are inherently enhanced.

Background and Related Research

Reviewing HCI literature reveals an extensive effort in the area of traditional user interfaces adaptation in terms of context modeling, user modeling, automatic generation of interfaces, etc. Most of the well-established concepts mainly target the conventional Graphical User Interface (GUI) paradigm such as plasticity [START_REF] Calvary | Embedding plasticity in the development process of interactive systems[END_REF] and the WWHT framework [START_REF] Rousseau | A framework for the intelligent multimodal presentation of information[END_REF]. Despite their strong relevance, most available adaptation approaches fail to satisfy four enduring challenges drawn from the natural characteristics of ambient environments, presented by Pruvost et al. [START_REF] Pruvost | User Interaction Adaptation within Ambient Environments[END_REF]:

-Heterogeneity and Distributivity: The interaction eco-system contains a variety of interaction devices with various capabilities. -Dynamic Media Mobility: Interaction capabilities are highly dynamic as interaction devices may join or leave the ambient space at anytime. -User Mobility: The user mobility in ambient spaces challenges the interactive system attention to the user's interaction needs.

In addition, most adaptation approaches focus on interface issues such as information presentation but not the interaction per se. Pruvost et al. [START_REF] Pruvost | User Interaction Adaptation within Ambient Environments[END_REF] clearly indicated that locking interaction devices in their own closed world is certainly an issue for interaction systems adaptability in ambient spaces. This closeness results into reducing the richness and unity of those interaction devices in various context scenarios. They also argued for highly adaptable user interfaces that preserve utility and usability across contexts. In their described adaptation vision, they have presented the concept of Off-the-shelf Interaction Objects, which are pre-implemented bundles of code, intended to be reused and composed at runtime. The objects aim to provide the necessary adaptation required for the interaction technique. While their vision is focused on the structural adaptation of user interfaces and the adaptation of a running dialogue, our work is more concerned with the sharing and deployment aspects of NUI, especially kinetic interactions. The Gestureworks Core 5 , which is limited to multitouch interactions, is one of the earliest multitouch gesture authoring solution for touch-enabled devices on a variety of platforms such as Flash; C++; and Java. Based on the GML (GML), the solution comes with a rich library of pre-built gestures and allows for new custom gestures and gesture sequences to be built by designers. For motion-based interactions, the OpenNI6 is an open source SDK used for the development of 3D sensing applications and middleware libraries. The main targets of this framework include enhancing the natural interaction techniques development community; making it possible for developers to share ideas and problems; to share code with each other; and to address the complete development lifecycle by a standard 3D sensing framework.

Standalone deployable interaction components for NUIs are becoming essential needs for ambient spaces. To our best knowledge, the work presented in this paper is one of few HCI research efforts to tackle this problem. Interestingly, dynamic component integration has been a rich and yet challenging investigation aspect for the ubiquitous and pervasive computing research. The dynamic component integration approach enables software components to be discovered, downloaded, and integrated on-demand, as a means of adapting an application's behavior and enhancing its features [START_REF] Schrader | Modular framework support for context-aware mobile cinema[END_REF]. This area of investigation has been recently successfully applied to mobile environments as in the Mobile USers In Ubiquitous Computing Environments (MUSIC) system that supports dynamic component integration on Android using OSGi (OSGi) containers [START_REF] Consortium | ist-music: Context-aware self-adaptive platform for mobile applications[END_REF]; the Context-Aware Machine learning Framework for Android (CAMF) that promotes plugin-based adaptation on Android [START_REF] Wang | Camf -context-aware machine learning framework for android[END_REF]; and the Funf Open Sensing Framework7 that promotes statically-linked context modeling plug-ins integration. More recently, the Dynamix framework [START_REF] Carlson | Dynamix: An open plug-and-play context framework for android[END_REF] was introduced as an open plug-and-play context framework for Android.

STAGE architecture and implementation

Our current implementation utilizes the wide spread and adoption of mobile devices for rich personalization, customization, and context acquisition in ambient spaces. Hence, this work fosters the use of mobile devices as customized and personalized interaction hubs. In our implementation, called STAGE, we leverage Dynamix framework [START_REF] Carlson | Dynamix: An open plug-and-play context framework for android[END_REF] as a mechanism for deploying natural interactions. Dynamix is used due to its unique capabilities and flexibility, especially related to dynamic discovery and deployment of suitable context plugins during runtime. Hence, it was feasible to adopt and extend context plugins for interactions. Although grounding the implementation on mobile devices may appear limiting from the first glance, the use of the mobile devices as a personalized interaction hub to facilitate interactions in ambient spaces provides various benefits in terms of personalization, decentralization, user control, and lightweight infrastructure. Figure 1 illustrates our underlying technical approach for implementing natural interaction techniques as deployable and shareable IPs, based on the Dynamix framework on the Android platform. As intended, the Dynamix framework runs as a background service (Dynamix Service) and is situated between Dynamix enabled applications and the device's interaction resources (i.e., interaction devices). The STAGE technical implementation appears mainly in two areas: first, the interaction application side; second, the context plugin side. Dynamix-enabled applications are standard Android applications with extra context modeling functionality provided by a local Dynamix Service. In STAGE implementation, two new components are introduced, namely the Interaction Manager and Ability Manager, to adjust the Dynamix framework to our needs. Additionally, Dynamix context plugins were adopted and extended in the IP implementation.

Context modeling and deployment with the Dynamix framework

The Ambient Dynamix framework was first proposed as a rich framework for on-demand discovery and runtime integration of plugins for context acquisition (sensors) and modification (actuators) in wide-area mobile contexts. Interestingly, Dynamix features strong and flexible discovery and deployment of context plugins at runtime. The framework was successfully used to model and deploy context in different none-HCI related scenarios as in [START_REF] Carlson | An ad-hoc smart gateway platform for the web of things[END_REF][6] [START_REF] Carlson | Ambientweb: Bridging the web's cyber-physical gap[END_REF]. The two features are essential building blocks for the implementation of the Interaction Plugin concept. In fact, our work is the first to utilize and build on this framework for deploying interactions in ambient spaces. In this section, the most relevant internal components of the framework based on [START_REF] Carlson | Dynamix: An open plug-and-play context framework for android[END_REF] will be described. The full specifications and more extensive discussion can be found in the Dynamix online portal 8 . Dynamix runs as a background service on Android-based devices, which allows multiple Dynamix-enabled applications to subscribe to Dynamix context events. Principally, a Dynamix-enabled application is a normal Android application that implements the necessary Dynamix API. Various context resources deliver raw sensor data to the framework, which are then modeled by Dynamix according to the available context plugins.

A context plugin is a standalone deployable OSGi container that allows for seamless runtime deployment (i.e., installation, uninstallation) according to the application needs. The flexibility of the Dynamix plugin's technical structure provided an adequate ground for our development of IP, as discussed lengthly in this section.

The OSGi Manager resides at the core of Dynamix implementation, which is build based on the Apache Felix OSGi. The manager is mainly dedicated for all plugins deployment actions, including the installation and un-installation of plugins from their OSGi containers. The OSGi framework allows for seamless integration of software units (called bundles) at runtime. Internally, the OSGi framework is composed of multiple layers responsible for bundle execution, bundle management, bundle life cycle, service and binding management, and security control. There are various communication aspects in Dynamix. We will focus, herein, only on the communication between plugins and applications. The communication between the Dynamix framework and Dynamix-enabled application is featured using the Facade and Event API. The Facade API controls all requests for context modeling support. Moreover, Dynamix currently uses POJO (Plain Old Java Objects) objects to encode the events shared between plugins and applications. The use of POJO objects allows both sides to work with Java objects, hence increasing the operability and reducing the programming and modeling load.

Implementing STAGE-enabled applications

Dynamix applications are designed to subscribe to dynamix and receive modeled context events. Those two features ease the implementation of context-based applications dramatically. Nonetheless, Dynamix-enabled applications are not fully adequate to the Interaction Plugin conceptual design. Hence, STAGE introduces two important extensions to the architecture, in order to facilitate the use of this framework for IPs, on the application and plugin levels. The changes and extensions are distinctly tinted (i.e., fully or partially shaded) in Figure 1. The STAGE components on the application side are further illustrated in Figure 2. STAGE-enabled applications contain the STAGE Manager (which contains the Interaction and Profile Managers) and the Interaction Profile Manifest (which encapsulates all necessary information about the required and relevant interaction capabilities by the application).

STAGE Interaction Manager

This class controls the activation of the available IP, based on the ability (the physical abilities required for the interaction e.g., major life activities), movement (the exact movements required for the interaction e.g., body part involved, type, and degree of movements), and interaction (the interaction semantic) profiles. The communication between the Interaction Manager and Dynamix service is facilitated using the Dynamix Facade API. Following the dynamix context plugin model, Interaction Plugins are tailored OSGi-based Bundles, which are loaded into the Dynamix embedded OSGi container at runtime. Once loaded and activated, an Interaction Plugin sends interaction encoded events to subscribed applications (as interaction primitive events) using POJO. Principally, Interaction Plugins are hosted in an Internetbased plugin repository, which in addition to the IP Bundle files, hosts the IP profiles and (optionally) additional related plugins.

In addition to the usual Dynamix context sensing tasks, IPs can be queried by the Interaction Manager to access the information encoded in the IP profiles. Currently, the Dynamix Service provides all plugin discovery services, plugin filtering based on the interaction requirements (interaction primitives required), and plugin installation support. Filtering and activating the available interaction plugins are currently handled by the Interaction Manager. The STAGE Interaction Manager is composed from the following components, as shown in Figure 2: -Subscription Manager is responsible for communicating directly with the Dynamix facade API, in order to control and mange IP subscriptions; -Event Handler consumes all Dynamix context events and filters all relevant Interaction Events; -Interaction Profile Builder is responsible to serialize the content of the Interaction Profile Manifest into a runtime object; -Plugin Manager keeps track of all accessible IPs and handles the status, subscription, plugin information, and discovery requests of all plugins;

-Ensemble Engine is responsible for monitoring interaction resources (i.e., IP) and build possible Interaction Ensembles adequate for the given context based on the application's required interaction capabilities, the available IP, and the user's physical ability profile; and -STAGE Interface Controller : STAGE-enabled applications require to control the application's GUI elements according to the fired interaction primitives from the IP (once an interaction primitive is fired, the corresponding action on the interface is executed, e.g., a selection interaction primitive may be interpreted as a button press).

Fig. 2. STAGE-enabled application architecture

Ability Manager This module is responsible for extracting the user's ability and disability qualities, based on the available Ability profile and Movement profile. Currently, both profiles are modeled and represented in tailored XML formats. This component is essentially split into the following modules:

-Ability Profile Builder is essentially an XML parser responsible to extract and serialize the content of the Ability Profile into a runtime object; and -Ability Provider provides all necessary information regarding the required physical abilities for executing the interaction tasks adequately by the user.

Interaction Profile Manifest This profile manifest captures the main interaction semantics including the interaction primitives such as pointing, selecting, dragging, etc. This is particularly important in ambient spaces because it provides indication on the main use of the interaction technique and its offerings.

We are considering interaction profile as a prime key for interaction adaption and matching in ambient spaces. In ambient spaces, interaction profiles offer the needed manifestation for coupling interaction techniques with applications.

Principally, it is used to in order to identify the required interaction capabilities for the application. The manifest file is constructed in XML format, and contains essentially the required interaction primitives. Figure 3 resembles a simple profile example (i.e., an application requires a selection interaction primitive).

STAGE-enabled application interaction sequence

The interaction sequence, shown in Figure 4, illustrates the communication steps between Dynamix and the STAGE Manager. The sequence illustrates the process of interaction requesting a certain IP, deploying IP in runtime, and delivering the event information to the requesting application. The Interaction Manager triggers and establishes the connection with the Dynamix framework. Upon connection, it receives all Dynamix related events as long as the Dynamix connection remains alive. For instance, the received events involve Dynamix activation events, deactivation events, and plugin installation events. Next, the Interaction Manager requests the ability profile from the Ability Manager. Moreover, it serializes the application's interaction profile, using its profile builder module. The Interaction Manager requests Dynamix for all accessible plugins (i.e., those plugins available in its repository). Once the list is received, the Interaction Manager identifies all accessible IPs and ignores all other context plugins. Plugins that implement the required "InfoObject" datatype object proposed by STAGE are identified as IPs. Otherwise, the plugins are considered conventional Dynamix context plugins (i.e., not related to interactions). The "InfoObject" contains the essential Uniform Resource Identifiers (URIs) for the IP and its three profiles, which are used later for filtering adequate IP in a given context. Next, it configures the Interfaces Controller event listener, in order to allow the controller to utilize the detected events for controlling the interface controllers accordingly. Moreover, the Interaction Manager sends Dynamix subscription requests to the available IP. While getting accepted subscriptions, the manager requests the plugin's ability and interaction profiles in order to build a map of IP and physical abilities required for each. This information forms the core base for the Ensemble Manager's matching algorithm. Accordingly, the Interaction Manager requests the Interface Controller to activate those GUI elements that are possible to be controlled by the available interaction resources (i.e., IPs). Other GUI elements, not supported by the available interaction resources, are not activated for NUI interactions, but can be still used conventionally (using the conventional touch interface).

At the end of interaction sequence, the STAGE Manager is able to receive modeled interaction events from the various IPs. The triggered interaction primitives are then sent to the Interface Controller to perform the required interaction tasks. It is important to know that multiple plugins may deliver the same interaction primitive. In this case, the Ensemble Engine may decide on which plugin should be used according to the best match with the user's physical abilities (Ensemble Engine's matching algorithms are not covered in this paper due to the size limits).

Implementing Interaction Plugins

An IP is essentially an OSGi Bundle containing the plugin's logic and context acquisition code. In our case, Dynamix is responsible for handling the plugin's lifecycle, based on its embedded OSGi framework. Figure 5 illustrates the technical implementation of the IP. The distinctly tinted (i.e., fully or partially shaded) components in the diagram indicate the core STAGE components and extensions:

-Context Acquisition & Modeling module resembles the logic required to access the context provider and its raw context data. The raw context data resources may be local resources (i.e., running on the same device, for example a built-in orientation sensor) or remote sources (i.e., accessible ambient context providers available in an accessible ambient space, for example an external camera sensor); -STAGE Handler is responsible to model the interaction events based on the received information from the previous module; -Plugin Factory provides the required mechanisms for plugin instantiation (handled completely by Dynamix); -PluginRuntime component contains the plugin's core lifecycle methods; serializing and building the interaction, movement, and ability profiles associated with each IP. Those profiles are modeled as XML embedded in the plugin's file structure and accessible though the IPluginInfo object; -ContextTypeInfo Objects contains the plugin's supported datatypes. In our implementation, those context type objects are used as interaction primitive objects; and -IPluginInfo Object, which is introduced as a new plugin information datatype and dedicated for the necessary movement, ability, and interaction profiles.

Examples and Scenarios

The practical benefits of IPs can be seen in an endless variety of showcases and scenarios. For instance, a person with limited arm rotation may take advantage of replacing the arm-based rotation IP exceeding a certain rotation degree with a foot-based rotation IP which utilizes an accelerometer sensor embedded in her smart sport shoes and wirelessly connected to her smartphone. Another example is allowing a person with total absence of three fingers due to an injury to interact with typical mobile operation systems, which often requires swipe gestures with three or more fingers. In such a case, one possible ensemble might comprise two IPs combining two fingers multitouch swipe with one foot-based motion swipe to replace the original three fingers swipe. In principle, the potential for building useful scenarios for interaction plugins and ensembles is only limited by the creativity of interface designers and engineers developing sensing devices in various forms and shapes to be used in future ambient scenarios. For further illustration, this section presents a full description of an interactive demonstration scenario, called the AmbientRoom, to showcase the dynamic aspects of dynamic interaction deployment at runtime.

The AmbientRoom is a STAGE-enabled mobile application for controlling the ambient lighting of smart rooms. The application provides three simple functionalities, namely dimming the light, changing light's color (i.e., rotate between the rainbow colors), and switching the light on/off. The application relies on our implementation of the Art-Net Light Controller plugin, which uses the Art-Net protocol to send DMX512 data for controlling lighting equipment over the Internet Protocol networks. The Art-Net plugin is a conventional Dynamix context plugin that acts as an actuator in this scenario, extensive discussion about this type of plugins is covered in [START_REF] Carlson | Ambientweb: Bridging the web's cyber-physical gap[END_REF]. Therefore, it should not be mixed with the IP concept discussed in this paper.

Because the application is STAGE-enabled, it adapts its interactivity to the user's physical capabilities. In the case of difficulties touching the interface controls with fingers (due to finger injury), the AmbientRoom application searches for alternative and adequate IPs allowing the user to perform the interaction tasks required by the application. In this scenario, the applications finds two motion-based interaction plugins for replacing the position (i.e., navigation) interaction task with a shaking IP (shaking the device for positioning the focus on the next GUI component) and the selection interaction task with an IP utilizing head movement respectively. Those plugins are found and dynamically deployed at runtime. The rest of this section will demonstrate the flow of the various processes involved in this scenario. Once the application is started, the application will show the user with a disabled GUI presenting the application main functional capabilities, as in Figure 6 (1). These capabilities are initially looked or disabled until the required plugins are requested by the application and dynamically deployed and activated by dynamix. In this case, the application starts by requesting the Art-Net Light plugin. Once the plugin is found, downloaded, and activated successfully by Dynamix, the application GUI controls will be activated, as shown in Figure 6 (2).

Next, the AmbientRoom application requests two motion-based IPs to enable users to interact with the application using two motion gestures. The first IP relies on the mobile device built-in accelerometer for detecting device shaking gesture to position the focus on the next button. The second IP relies on the Asus Xtion PRO LIVE9 motion sensor for detecting head movements to select (i.e., click) the selected button. Upon a successful deployment of the two plugins, the corresponding GUI control are marked with a green symbol to indicate the possibility to be controlled using motion gestures in addition to the conventional multitouch interface as shown in Figure 6 (3).

Figure 7 demonstrates the NUI style interactions with motion gestures enabled by the deployed IP. Figure 7 (1) shows the NUI-enabled buttons. Using the shaking gesture, the user positions the focus on the control of choice (each device shake will position the focus on the next button) as illustrated in Figure 7 (2). Using the head movement, the user is able to select (i.e., push) the button in focus as illustrated in Figure 7 (3). Despite its limited scope, the AmbientRoom scenario illustrates the possibility to turn a mobile device into an interaction hub to enable the user to control ambient resources (i.e., lighting) using natural interactions techniques (i.e., different motion gestures). Most importantly, it demonstrates the potential and power of the soft wiring approach where interaction capabilities are deployed (as plugins) at runtime using the STAGE system.

Provisioning Interaction Plugins

Provisioning IP undergoes a number of phases as illustrated in Figure 8. In the first phase, the interaction techniques passes the usual design and implementation processes. In the second phase, the interaction developer (i.e., designer, developer, or team) makes sure that the techniques satisfies the function and utility defined in the interaction design. In the third phase, the interaction developer should define the interaction's movement profile, based on an acceptable level of movement description; define the interaction's ability profile, based on the most important physical qualities that impact the interaction; and assign the interaction semantics, based on the envisioned utility of the technique. In the fourth phase, the interaction developer wraps the interaction's internal logic as a Dynamix plugin. In the fifth phase, the IP is published to an accessible repository. Dynamix supports two types of accessible plugin storage locations (file-system or network). Our implementation supports the later type as shown in Figure 1. The repository hosts the plugins OSGi bundles and the corresponding context plugin description XML documents. This paper argues that a large-scale dynamic runtime deployment of existing and future interaction techniques for Natural User Interfaces remains an enduring challenge for engineering interactive systems for ambient spaces. Only few research projects aim to target this problem in the context of HCI. In this paper, we have presented the architecture and implementation of the STAGE system, which enables interaction techniques to be constructed as standalone dynamically deployable objects (Interaction Plugins) for Android mobile platforms during runtime. The presented implementation is one of many possible ways to realize the proposed concept. Hence, the proposed implementation should not be necessarily considered as an ultimate implementation solution, instead the implementation aims to demonstrate and evaluate the feasibility of the approach. The current implementation utilizes the wide adoption of mobile devices for rich personalization, customization, and context acquisition in ambient spaces. Hence, this work fosters the use of mobile devices as customized and personalized interaction hubs. As future work continuation to this paper, we are working on an extended performance evaluation of the Interaction Plugins and rich feasibility tests by implementing a number of demonstration scenarios. We also aim at increasing the richness of Interaction Plugins and improving plugin's filtering and matching according to the user's physical context.

Fig. 1 .

 1 Fig. 1. A high-level overview -STAGE realization based on Dynamix (based on [1])

Fig. 3 .

 3 Fig. 3. STAGE-enabled application architecture

Fig. 4 .

 4 Fig. 4. Sequence Diagram for STAGE-enabled application

Fig. 5 .

 5 Fig. 5. IP internal architecture

Fig. 6 .

 6 Fig. 6. AmbientRoom application (screenshots): (1) deactivated GUI controls; (2) activated GUI controls after Art-Net plugin runtime deployment; (3) GUI controls are marked after IPs runtime deployment

Fig. 7 .

 7 Fig. 7. AmbientRoom application NUI-enabled Interactions

Fig. 8 .

 8 Fig. 8. IP provisioning lifecycle

7 Acknowledgement

 7 This work was partially supported by the Graduate School for Computing in Medicine and Life Sciences funded by Germany's Excellence Initiative [DFG GSC 235/1].

http://www.apple.com/ios/, latest access on 26.06.2014.

http://www.android.com/, latest access on 26.06.2014.

http://gestureworks.com, accessed on 26.06.2014.

http://www.openni.org, latest accessed on 26.06.2014.

http://funf.org, latest access on 26.06.2014.

http://ambientdynamix.org, visited on 26.06.2014.

http://www.asus.com/Multimedia/Xtion PRO LIVE/, latest access on 26.06.2014.


Andrés Rodríguez

Extending OpenUP to conform with the ISO Usability Maturity Model

Keywords: User Centered Design, Usability Maturity Model, OpenUP

Integrating practices and methods of Interaction Design and Usability into Software Engineering processes has posed some challenges. In this paper we extend a SE process to enable its instantiation as user centered in order to improve the usability level reachable by the final system. Also, we suggest a kind of a road map that enables software organizations to instantiate cumulative versions of this process to grow in their capability regarding the usability practices. The paper is organized in two parts. First, we describe de open source version of the Unified Process (OpenUP) and the ISO Usability Maturity Model (UMM-ISO) and present the results of an assessment made on the first to determine its conformity with the latter. In the second part we present an extension to OpenUP to fill the gaps discovered and report the highlights of an implementation of these contributions in a real project and the lessons learned.

Introduction

Integrating practices and methods of usability and interaction design into the Software Engineering (SE) processes has posed some challenges. As Seffah has explained "the structure and techniques of Human Computer Interaction (HCI) are still relatively unknown, underutilized, hard-to-master and with little integration essential in software development teams" [START_REF] Seffah | Human-Centered Software Engineering -Integrating Usability in the Development Process (Human-Computer Interaction Series)[END_REF]. The magnitude of the integration effort is often wrongly minimized. Many developers still think that usability is affected only by the user interface. However, even early decisions on the software architecture may affect the usability a system can reach [START_REF] Bass | Supporting Usability Through Software Architecture[END_REF][START_REF] Folmer | Case studies on Analyzing Software Architectures for Usability[END_REF]. If usability is considered as the result of the whole development process, its activities must be included throughout the process. It has shown from HCI that there is a direct relationship between the level of usability that a product can reach and the use of a User Centered Design (UCD) process (there are many references on the topic, see for example [START_REF] Mayhew | The usability engineering lifecycle: a practitioner's handbook for the user interface design[END_REF][START_REF] Sharp | Interaction Design: Beyond Human Computer Interaction[END_REF]). However, not all SE processes can become focused on user simply by making a few modifications. From SE, this topic has been recognized too (e.g. [START_REF] Joshi | Measuring effectiveness of HCI integration in software development processes[END_REF] for example) .

Another challenge deals with the improvement of processes that enable an organization grow in usability capabilities as predictable and controlled as in SE capabilities. Some model of capability and maturity in usability have been proposed trying to provide a basis for planners and process engineers to know what user centered activities to include in a particular project, as well as to assist those who wish to improve the whole process carried out by an organization.

Our work deals with these two challenges with the Usability Maturity Model presented in ISO Standards (UMM-ISO) as a base. First, we extend a SE process to enable its instantiation as a user centered one. Then, we suggest a kind of a road map that enables software organizations to grow in capability regarding the usability practices. The paper is organized in the following form. In Section 2 we contextualize our proposal analyzing related works. In Section 3, we describe the open source version of the Unified Process (OpenUP) and the UMM-ISO and present the results of an assessment made to determine the conformity of OpenUP with the UMM-ISO. In Section 4 we present the main contribution of this paper: an extension to OpenUP to fill the gaps discovered in Capability levels 1 to 3. Finally, we report the highlights of an implementation of these contributions and the lessons learned. Concluding remarks and further work needed are mentioned to close the paper.

Related work

There have been several proposals to integrate HCI in SE processes. The common approach has been identifying some key HCI activities to be included a SE process to create a somewhat modified version. Proposals for augmenting waterfall, agile or unified processes can be found in literature. For the waterfall cycle, can be mentioned for example the proposals of Costabile [START_REF] Costabile | Usability in the software life cycle[END_REF] and Joshi and Sarda (see [START_REF] Joshi | Measuring effectiveness of HCI integration in software development processes[END_REF]). Costabile augments de process including user and task analyzing, scenarios and User Interface (UI) specifications activities. She emphasizes on the evaluation as the central activity of a UCD process. Joshi and Sarda add several HCI activities at the Communication, Modeling and Construction phases.

The Unified Process (UP) has received different types of proposals for integrating HCI activities. Göransson [START_REF] Goransson | Usability design -Exteding Rational Unified Process with a new discipline[END_REF] proposed a new discipline for RUP. After identifying identified some RUP characteristics that can be obstacles for implementing a UCD Process (centrality of architecture, prevalence of the use cases, usability activities concentrated only in the Elaboration phase) proposes a new discipline, Usability Design containing key elements from HCI and spanning the whole RUP lifecycle. Other proposals for RUP are the work by Krutchen [START_REF] Kruchten | User interface design in the rational unified process[END_REF], Heumann [START_REF] Heumann | User experience storyboards : Building better UIs with RUP , UML , and use cases[END_REF], Sousa and Furtado [START_REF] Sousa | RUPi -A Unified Process that Integrates Human-Computer Interaction and Software Engineering[END_REF]. The first two, propose the inclusion of HCI models, activities and artifacts to the basic RUP (user experience model, prototypes and storyboards are the most important). Sousa and Furtado present the RUP for Interactive Systems (RUPi). It adapts the four RUP workflows. In the requirement workflow RUPi includes several modeling tasks and an explicit definition of usability requirements. In the Analysis and Design workflow a UI conceptual design and class model of UI are added. The Implementation workflow is increased with guidelines and in the Test workflow a strong focus is made on Usability evaluation.

The open source version of UP has received some contributions too. For example, the DSDM Consortium published the plugin OpenUP/DSDM [START_REF]DSDM-Consortium: OpenUP/DSDM Plugin[END_REF] that adds specifics Business roles and assign them some responsibilities on tasks and work products: Executive sponsor, Visionary, Ambassador user, Advisor User. The goal of this plugin is to promote collaboration between business and technical communities during the project. In the same line, the Plugin Web Enabled UCD [START_REF]IconATG: Web Enabled UCD v1.0[END_REF] is a proposal to augment UP as an UCD process for web development adding many new elements (11 new roles, 12 new work products and 6 new activities).

In the realm of agile methods, Beyer, Holtzblatt and Baker [START_REF] Beyer | An Agile Customer-Centered Method: Rapid Contextual Design[END_REF] describe a combination of the Rapid Contextual Design techniques [START_REF] Holtzblatt | Rapid Contextual Design. A how to guide to key techniques for user centered design[END_REF] with a user stories based development process. Their proposal includes a separate UI design team as long as these skills are usually held by different people on the team. Nielsen [START_REF] Nielsen | Agile development projects and usability[END_REF] proposes a threefold integration between agile methods and usability field: perform usability activities in a few days, adopt a parallel track approach (where the UX 1 work is continuously done one step ahead of the implementation work) and make foundational user research going beyond feature development (ideally this should be conducted before a development project starts). Joshi [START_REF] Joshi | Index of Integration (IoI)[END_REF] has proposed a similar integration: HCI activities hard to fit in a typical iteration should be done before the agile iterations begin, there must be a synchronization between software development iterations and HCI activities, the HCI team should closely coordinate with the software development team giving some "development support" to ensure that UI is implemented as close to its original intent as possible.

All these proposals show different ways of integrating the key HCI activities within SE processes. In some way or another the HCI elements that most contribute to the final usability according to Joshi and Sarda [START_REF] Joshi | Evaluating Relative Contributions of Various HCI Activities to Usability[END_REF] are at the center of the different proposals (user modeling, UI prototyping, usability evaluation, collaborative work between HCI staff and development staff). Also an iterative cycle, user centered work is present at most of them. In our approach we try to extend these contributions on a side that has not been fully addressed in our opinion. In this paper, we are proposing a roadmap intended not only to help including HCI activities in a typical SE process but to provide a predictable way for improving that process and grow in HCI capability. We base our work on the concept of Capability Maturity Models, adopted in SE as a guide for process improvement.

3

OpenUP and the UMM-ISO Group OMG [START_REF][END_REF]. This framework includes definitions of method content and application delivery processes. The content is manifested through definitions of work products, roles, tasks and guidance. A relation between some work products (input, output), tasks and roles makes an Activity and a chain of activities build a Process. Finally, there is the concept of Practice: "an approach to solving one or several commonly occurring problems. Practices are intended as "chunks" of process for adoption, enablement, and configuration" [START_REF]Eclipse: Eclipse Process Framework Practice Library[END_REF]. Eleven practices are contained in the EPF Practices Library (EPL). OpenUP presents itself as "a lean UP that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development". Its simplest version is OpenUP/Basic (a minimum, complete and extensible process oriented to work on projects of small and medium scale). OpenUP/Basic includes all the practices defined in the EPL, organized into two categories, Management practices (Iterative development, Risk-value lifecycle, Release planning, Whole team, Team change management) and Technical ones (Concurrent Testing, Continuous integration, Evolutionary architecture, Evolutionary design, Shared Vision, Test driven development, Use case driven development). Development lifecycle with OpenUP can be analyzed in three layers: a) personal effort is organized in micro-increments (short units of work typically measured in hours or a few days); b) team effort for delivering incremental value to stakeholders is organized in iterations (planned, time-boxed intervals typically measured in weeks); c) the project lifecycle is structured into four phases: Inception, Elaboration, Construction, and Transition (this provides stakeholders and team members with visibility and decision points throughout the project) [START_REF]Eclipse: OpenUP version 1.5.0.1[END_REF]

3.2

The ISO Usability Maturity Model (UMM-ISO)

Different models have been proposed to drive process improvement in usability aspects (e.g., [START_REF] Nielsen | Corporate usability maturity: stages 1-4[END_REF][START_REF] Ehrlich | Cost justification of usability engineering: a vendors's perspective[END_REF][START_REF] April | Trillium: a model for the assessment of telecom software system development and maintenance capability[END_REF][START_REF] Schaffer | Institutionalization of Usability: A Step-by-Step Guide[END_REF][START_REF] Bevan | Proposed usability engineering assurance scheme[END_REF][START_REF] Jokela | The KESSU Usability Design Process Model[END_REF]). The UMM-ISO was presented in the report ISO TR18529 "Human-centered lifecycle process descriptions" [START_REF]Ergonomics of human system interaction. Human-centred lifecycle process descriptions[END_REF]. The UMM-ISO attempts to provide a basis for planners to know what human centered activities include in a particular project, as well as to assist their improvement. UMM-ISO's reference model is contained in ISO 15504 SPICE [START_REF]Information Technology and Software Process Assessment[END_REF]. This model has two dimensions: processes and capabilities. Each process can be assessed with a degree of compliance on a scale of six Levels: incomplete, performed, managed, established, predictable, optimizing. The way to determine the Capability level in a process is to analyze which attributes of such process are checked according to the evidence collected. Each attribute is evaluated on a four ranges scale: unmet, partially achieved, widely reached, fully met.

Dimension of the Human Centered Development (HCD) processes.

Processes are described as practices that are required to implement for including system stakeholders and users during the whole lifecycle. Each process is described with purpose, suc-cess indicators, input work product and output work products. ISO TR18529 defines seven HCD process: ─ HCD1.Ensure the HCD content systems strategy ─ HCD2.Plan and manage the process ─ HCD3.Specify the requirements of stakeholders and the organization ─ HCD4.Understand and specify context of use ─ HCD5.Produce design solutions, ─ HCD6.Evaluate designs against requirements. ─ HCD7.Introduce and operate the system These seven processes can be grouped at three different levels of analysis: the organization (HCD1 and HCD7), the project technical development (HCD4, HCD3, HCD5 and HCD6) and its management and control (HCD2).

Dimension of capability and maturity levels.

To assess the capability level reached a number of desirable process attributes that has to be met in each HCD process. These attributes are cumulative, at every level of capability is expected that all attributes of the lower levels are achieved.

─ Level 1: Performed. The degree to which output work products are produced from inputs work products through the enactment of the practices which comprise the process. There is one Process performance attribute to be assessed: "Ensure that base practices are performed to satisfy the purpose of the process". ─ Level 2: Managed. The degree at which the process is managed to produce work products of acceptable quality within defined timescales and resource needs. The achievement is demonstrated assessing two kinds of attributes: Performance management (e.g., Identifying resource requirements to enable planning and tracking of the process, Plan the performance of the process by identifying the activities and the allocated resources according to the requirements, etc.) and Work product management (e.g., Identify requirements for the integrity and quality of the work products, Manage the configuration of work products to ensure their integrity) ─ Level 3: Established. The established process ensures the deployment of a defined process based upon good SE principles. The evaluation will analyze the extent to which a given process is defined with an appropriate standard to contribute to the goals of the organization through definition of a standard process (e.g., Tailor the standard process, Implement the defined process) and through use of suitable, skilled human resources an process infrastructure (e.g., Define human resources competencies required, define process infrastructure requirements)

Level 0 (Incomplete) has no attributes to identify, while Levels 4 and 5 require an assessment on the organization beyond the scope of a particular project process (e.g., Process measurement attribute at Level 4: Define process goals and associated measures that support the business goals of the organization).

3.3

Assessment of OpenUP in the light of the UMM-ISO.

An assessment has been done to determine the capability profile of OpenUP in terms of UMM-ISO. The goal was not to find if OpenUP is fully compliant with UMM-ISO. It is clear that OpenUP is not a full UCD process so gaps with UMM ISO will be found. The assessment is used here as a structured approach to discover those gaps.

To collect evidence of achievement we use the complete specification of OpenUP/Basic 1.5.0.1 [START_REF]Eclipse: OpenUP version 1.5.0.1[END_REF]. Any item contained in that specification, either method or process, that enable us to interpret that it could satisfy some UMM-ISO attribute will be considered evidence enough of such capability. Assessment on levels 4 and 5 require evidence from the organization management practices beyond the specific development process used. That evidence cannot be got from the OpenUP specification, so the scope of our assessment is constrained to levels 1 to 3 of UMM-ISO.

The evaluation cycle is the following:

1. Take a UMM-ISO HCD process 2. Take a Level to assess. For each process attribute at the chosen level, analyze the OpenUP/Basic specification and look for content or processes which allow satisfying the attribute. 3. Determine the degree of achievement of the attribute in a ranking of 4 levels: In cases of doubt about the achievement between two levels for a particular practice, apply the benefit of the doubt and qualify in the higher level. 5. The process is repeated for the next attribute of the level. 6. The process is repeated for the next level, until there is no evidence of the preparation of any practice at this level or until reaching the upper limit established for the evaluation. 7. The cycle 2 to 6 repeats for the next HCD of UMM-ISO process

We use an evaluation form adapted from Earthy [START_REF] Earthy | Usability Maturity Model: Processes[END_REF] (see Fig. 1). For each UMM-ISO attribute (column 1) we identify the OpenUP Practices including enough evidence to cover the attribute (column 2). Within each Practice we detail Process contents (Activities and Capability patterns, in column 3) and the Method contents (Roles, Artifacts, Tasks, in column 4) that allow that coverage. For each of the attributes of UMM-ISO the degree of achievement is recorded in the above-mentioned scale. Then we calculate the mean for all the attributes in a group (Process performance, Performance management, Product management, Process definition, Process resources definition). This mean set the achievement at that capability level for the HCD process. Fig. 1. Recording form (adapted from [START_REF] Earthy | Usability Maturity Model: Processes[END_REF]). First column lists UMM ISO's attributes, the following three columns show evidence collected (Practice, Process and Method). Last column shows numeric score achieved for each row and the calculated mean for a group Results. Evidence collected shows that OpenUP/Basic doesn't achieve full coverage of any attribute for Levels 1 to 3. We measured a total of 156 attributes. Achievement was Partial in 76 cases, Large in 10 and Null in 70 attributes. The capability profile at three levels assessed is shown in Fig. 2. It is clear that the only areas that achieve some degree of conformity are the core (HCD2 and HCD3 to HCD6). Achievement is minimal on HCD1 and null for HCD7. The Management practices included in OpenUP contribute to show some evidence of achievement. However none of them qualify for an F or L. Only some method elements (or part thereof) could reach a partial achievement if they were carried out by staff members with background in HCI. Technical practices also exhibit a partial achievement (particularly, Shared Vision, Evolutionary architecture and Evolutionary design). Use Case Driven Development could reach a greater achievement when staff members with HCI background are included. Specially, for identifying, specifying stakeholders, their tasks and contexts of use (however, this background is not a must by any role, just a suggestion in the Guideline "Staffing a Project").

In total, 10 attributes out a total of 156 has been assessed to a higher level using this "benefit of the doubt". For example, on HCD3 (Specifying requirements) OpenUP covers all attributes at Level 1. Three of them achieve a Large fulfillment. Practices like Shared Vision, Iterative development, Use Case Driven Development contribute to cover Performance attributes such as Clarify and document system goals, Assess risks to stakeholders, Generate the stakeholder and organizational requirements. However broader gaps are found for the other attributes. There is no evidence for a complete and detailed specification of stakeholders (Performance Attribute: Analyze stakeholders), nor is required taking into account the system context beyond the software (Attribute: Define the use of the system). Finally, OpenUP is too brief about quality in use goals (Attribute: Set quality in use objectives). Just one Guideline suggests 3 steps in order to identify key issues in usability, choose the right style to express requirements and write them. Assuming the scenario that staff members had enough HCI background we can give the benefit of the doubt and consider that OpenUP can reach Partial achievement on these attributes. Finally, a Large coverage at Level 1 for this HCD process is scored (mean=0.5).

Table 1. Score achieved at HCD2 at Level 1 and actions required to improve capability

Actions to fill the gaps. Our proposal is to provide an OpenUP based development process that can reach Full compliance with UMM-ISO at the Level 1 and at least Large at Levels 2 and 3. In order to achieve a full capability profile at Level 1 three actions are to be taken on the OpenUP/Basic configuration: ─ Take from Large to Full (LtoF): Add or modify method and process contents to fill the gap between the Large coverage to the Full one. ─ Take from Partial to Large (PtoL): extend OpenUP/Basic processes that were assessed with a Partial coverage so they can reach at least the Large one. ─ Take from Null to Large (NtoL): generate method and process contents to cover that HCD processes with no evidence of achievement by OpenUP/Basic.

Extending OpenUP to conform with the UMM-ISO

The EPL's guidelines offer two scenarios for extension that are useful in our case [START_REF]Eclipse: Eclipse Process Framework Practice Library[END_REF]:

• IF you need to add roles, tasks or work products that reflect a different approach, THEN create a new Practice including them and processes to articulate them • IF you need to modify a current process by adding elements from other Practice, THEN customize an existing Configuration of Practices with the lacking elements.

Given these scenarios we propose to fill the gaps discovered with the following tasks:

1. Adding new items to base practices. All missing HCD contents included by the UMM-ISO should be incorporated in the Practices offered by EPL. 2. Adding and modifying cross practice processes. On Level 1 to ensure the convergence of the Evolutionary architecture, Evolutionary design and HCD. At levels 2 and 3, to include HCD process and product management. 3. Using an alternative set of role assignments, to set the responsibility for some processes to the new roles, in order to improve their human centeredness.

After doing these tasks, we add a new practice to the EPL: Practice User Centered Development and extend the OpenUP/Basic configuration generating three new process configurations.

The Practice User Centered Development (UCDev) 2

This practice articulates the method elements (roles, tasks, work products and guidance) needed to instantiate a development process that actively involves all stakeholders during the whole cycle.

Roles. OpenUP/Basic offers three generic definitions relevant to UCD: Stakeholder, Analyst and Developer. However, their definitions do not ensure that necessary profiles and skills for carry out a UCD process can be met. Other UP or OpenUP extensions have already identified this problem and proposed adding new roles (e.g. [START_REF] Goransson | Usability design -Exteding Rational Unified Process with a new discipline[END_REF][START_REF]DSDM-Consortium: OpenUP/DSDM Plugin[END_REF][START_REF]IconATG: Web Enabled UCD v1.0[END_REF]). In order to keep OpenUP with low level of bureaucracy and ceremony while including in the process the skills needed, we have identified six roles to be added: four Business actors (Sponsor, Domain Technical Leader, Users Representative, End User), an Analyst (UX Specialist), a Developer (UX Designer) and a Tester (UX Tester). Complete descriptions can be seen in [START_REF] Rodríguez | OpenUP/MMU-ISO. Soporte para un proceso de desarrollo de software conforme al Modelo ISO de Madurez en Usabilidad[END_REF].

Work products. The first element that must be included explicitly is central in any iterative, user centered process: the user experience prototype in any of its versions [START_REF] Sharp | Interaction Design: Beyond Human Computer Interaction[END_REF], [33][18]. We also include other two artifacts with strong relations with prototypes: the UX Storyboard and the Navigation map. The Storyboard will allow analyze the dynamic aspects of UX prototype, while the navigation map will leave clearly stable the relationship between all the Storyboards. The list of the new definitions of work products that we include in UCDev comprises: User model, Usability Goal, Task model, UX Concept, UX prototype, UX Storyboard, Navigation map and User and training document (details in [START_REF] Rodríguez | OpenUP/MMU-ISO. Soporte para un proceso de desarrollo de software conforme al Modelo ISO de Madurez en Usabilidad[END_REF])

Tasks. As for the Roles and Work Products, will use as background the UMM-ISO specifications, UCD literature and tasks definitions from configurations in the UP family (e.g., RUP [START_REF] Krutchen | The Rational Unified Process: an introduction[END_REF], Agile Unified Process [START_REF] Ambler | The Agile Unified Process (AUP)[END_REF]). We have incorporated the following definitions of tasks: Each Task is defined by: purpose, description and relations with other method elements and steps to be done. Some tasks also include specific guidelines. For example, the definition for Task Specify requirements and UX goals includes the following contents:

─
• Purpose (why including this task? What is its goal?): The relations between all tasks included in UCDev and the UMM-ISO processes are shown in Fig. 3 (HCD processes organized in the figure as mentioned in Section 3.2) Guidance. We propose the integration of two basic guidelines. The first one contains the definitions of the UCD processes. The other guide details the UMM-ISO levels. As a road map, both give guide the process engineer for the total or partial adoption of the practice and their inclusion in the development process. We propose a scheme of three configurations that can be instantiated to achieve usability capability at UMM-ISO Level 1, 2 or 3. These configurations can be seen as incremental steps that guide for growing in usability capability in a predictable, structured way. Configuration for Level 1 (OpenUP/UMM-ISO N1) adds the new Practice UCDev to OpenUP/Basic. For levels 2 (managed) and 3 (established) we use the variability "extends" on previous level incorporating activities for process and work product management.

─
In the following descriptions, we use the four phases of UP (Inception, Elaboration, Construction and Transition) to show the customizations included.

OpenUP/UMM-ISO N1. The goal in the Inception phase is to understand the scope of the problem and the feasibility of a solution. The deployment process for a typical iteration of this phase in our configuration contains the same four core activities: Start the project, Identify and refine requirements, Agree on the technical approach and Plan and manage the iteration.

Some changes are implemented to the interior of each activity. Our main contributions are in the Activities Start the Project and Agree on technical approach. In the first one we modified the tasks Develop technical vision and Plan the project. UCD roles are assigned and an extra step is included to Identify and Sketch Use Context. Usability related requirements are specified by the new task Specify UX Goals assigned to the UX specialist. So, this Task is developed in synchronized with Identify and outline requirements (from OpenUP/Basic specification) as long as outputs from one are inputs to the other. In the Activity Agree on technical approach we propose two simultaneous tasks: Outline the architecture (in OpenUP/Basic) and Outline UX (in UCDev), providing the team with an architecture that consider UX goals.

On the phase Elaboration (aiming to better understand the requirements of the system, create and establish a basis for the system architecture) we include the task Design the UX as part of Activity Develop architecture and UX. The Activity Develop Solution Increment includes two tasks from UCDev, Design interaction components and Review UX Design to ensure the inclusion of user issues from the early design. Finally, in the Activity Test solution other two tasks are added: Prepare usability tests and Run usability tests.

The third phase, Construction, starts when architecture has reached stability and focuses on implementing remainder requirements. Tasks Develop solution increment and Test solution are done here in a loop. Throughout this phase iterations the functionality will continue being implemented, tested and integrated. The phase can include one or more beta releases towards the end.

The final phase Transition focuses on deployment the software to users and ensuring that their expectations are met. However, in the basic version of OpenUP, the main objective of the phase is reduced to fine tune the functionality, performance and quality of the beta version of system generated at the end of the construction phase, excluding specific activities that are specific to the preparation of the deployment such as the final acceptance test or user support. To overcome this lack, we include the task Guide and give support to user during implementation (Practice UCDev). Also refine the extension of the activity: Test solution adding the User acceptance as a variant of usability testing.

OpenUP/UMM-ISO N2.

In this level is necessary to identify attributes of process and work product management for UCD elements. In the first case, it is important to generate products of work within the established time and resource requirements. The configuration at this level is conceived as an extension of OpenUP/MMU-ISO N1.

So, this level incrementally adds method and content items needed to meet those requirements. We need to ensure the use of Change and Configuration management practices and Quality control. OpenUP/Basic includes them with the Practice Iterative Development, we took it as a guide to extend these activities on UCD elements.

The main change happens in the task Plan the project from the Inception Phase. The original task from OpenUP/Basic includes the steps Establish a cohesive team, Estimate project size, Evaluate risks, Forecast project velocity, Outline project lifecycle, Establish costs and articulate value, Plan deployment. We add two additional steps: Plan the UX Quality (define a minimal plan for quality assurance on tasks and work products from UCDev) and Plan UX Change and Configuration management (set management politics for configuration management on UX work products). The tasks related to Iteration planning and management (Plan iteration, Manage Interaction, Assess results) are customized in the same line to ensure those plans are met. In the other phases, the Task Request Change allows to meet the management requirements on UCDev elements.

OpenUP/UMM-ISO N3. For the level 3 we need to ensure that the process configuration used in each project is adjusted to the specific situation and available resources as much as possible. The configuration for this Level is again built incrementally on the previous one.

We add the Task Tailor the UCD Process to the Activity Start the Project. The task's primary performer is obviously from Project manager, but roles form UCDev such as the Sponsor and Domain technical leader should be included as additional performers. The inputs are the development process as defined by OpenUP/UMM-ISO N2 and the two Guidelines HCD Processes Definitions and UMM-ISO specifications. The output is a customized configuration. Six steps are defined: Analyze the project, Determine adaptation effort, Develop specific content, Define lifecycle, Publish the process, Manage the process.

The task Assess results (in the four phases) adds the step Manage the process, to ensure that customizations are met as planned.

The family of OpenUP/UMM-ISO plugins. The EPF Composer [START_REF]Eclipse: EPF Composer 1.0 Architecture Overview[END_REF] is a toolkit for engineers to implement and maintain software development processes. It provides the contents of the EPL and tools to select, customize, assemble and publish parts of this library as a specific process. We used the Composer to implement the extensions described before in plugins: a Practice Plugin that contains the definitions for Practice UCDev and three Configuration Plugins, one for each Capability Level to cover.

An initial implementation

The OpenUP extensions described were initially implemented during the development of a financial management system for the Argentine government. Here we briefly introduce some initial highlights of this experience in order to show the feasibility of implementing these extensions. A full assessment of this and other instantiations will be the goal of further works. The project had been initially organized using a customized version of UP. The process was gradually adapted through the evaluation and selection of artifacts and activities using an iterative dynamic "evaluate-modify-implement". It was early detected the need to include and integrate UCD practices in the process. The system would be operated by many users working at geographically distributed agencies and it would replace a previous version that users were accustomed to for many years. So, in order to achieve acceptance and effective operation the impact of the change should be minimized and usability maximized.

First steps included hiring a usability expert and following the guidelines in the RUP Plugin for the UX. Storyboards modeled as UML class diagrams using stereotypes were implemented. These models represent the screen components, the logical data groups and data grids. Static screen content (field names, labels, titles, images, etc.) is not represented in this model because it relates only to the appearance of UI and has no implication in the system logic. The model was very complex for the system screens and presented a number of disadvantages: it required a long time for an analyst to generate, it was very difficult to be understood by designers and programmers, wasn't good for users validation, it didn't allow to easily deduce the UI prototype and finally it was difficult to set a general standards for creating similar screens (conspiring directly against one golden rule in usability). This solution also limited the participation of user representatives at the early stages of requirements elicitation and for the testing of built modules, generating delays and rework.

To circumvent these obstacles it was decided to adapt the process configuration to adhere to our OpenUP/UMM-ISO N1 including the contents of the Practice UCDev. Some roles were added, such as User Representative and UX Designer. The task of Analysts was enriched with new definitions to include specific work products for UCDev as more understandable Screen prototypes. In each phase of the process, there was the correspondent validation and testing with users as stated for UCDev and OpenUP/UMM-ISO N1. Over a period of a year the project run with the implementation of this level of configuration.

Good responses by users and successful achievement of project goals gained in the first year motivated the team to adapt the process to the second level of configuration. In the second year, the project configuration was again customized by adhering to our proposed OpenUP/UMM-ISO N2. Then method elements related to the change, configuration and quality management for usability artifacts and processes were included. The project continued on this configuration for a full second year.

Some lessons learned

After these implementations, we analyzed two sources of information to extract lessons from this experience. We get qualitative feedback from questionnaires to key members of team project. Also we collected evidence from project repository, where work products (plans, models, prototypes, testing reports, etc.) are versioned and stored. We sought for evidence supporting the feedback got from questionnaires. We found that adding the Practice UCDev and implementing configurations OpenUP/UMM-ISO N1 and N2 had the effect to improve the inclusion of UCD activities in the project and integrate usability tasks in the whole team. Both initial and specified requirements and increment solutions could be validated by users during the complete process. Also, the UX expert wasn't seen anymore as an external auditor reviewing the designs made by other team members. It was understood that a set of practices and skills included in isolation and not framed in the whole process would not have the desired effectiveness in improving the usability of the final system.

It was possible to implement the practice in the project re-arranging available resources, with a few modifications of the process while running the project without significant deviations from the initial planning and with an increase in the degree of user acceptance.

The move to a higher level of capability was conducted in a non-traumatic and predictable way as long as before its starting it was clear what activities should change, what skills would be necessary to improve and what to expect from this new level of capability.

Concluding remarks and further work

A proposal of using a capability maturity model as roadmap for the predictable and systematic improvement of usability processes is presented. In particular, we describe the maturity model in usability in the ISO standards, which identifies seven UCD processes and a scale of capability that includes six levels (from incomplete to optimizing). We take the Unified Process in its agile, open source version (OpenUP).

After an assessment of it in the light of the UMM-ISO several shortcomings that cannot be covered just by modifying ad hoc some of their practices have been identified. In the first place, it is necessary to incorporate new roles usually not taken into account in the process of development to transform it into a user centered process. This implies not only engage stakeholders and end users, but add a new battery of skills and abilities in the project. Also, the way to make real UCD activities related to the UX must traverse the entire lifecycle. There is no way to guarantee good levels of usability in a product if all aspects of the quality of the use are reduced to the design of the user interface.

Our proposal has been to extend OpenUP so that it can be instantiated as a UCD process through two contributions. On the one hand, added the new practice UCDev to the EPL. This practice articulates specific method content items, their roles, tasks and work products, taking as a reference the life cycle proposed by the UMM-ISO. The second contribution is to extend the instantiation of OpenUP with three method configurations that allow reaching usability capability at levels 1, 2 or 3 in the UMM-ISO. In these configurations is articulated as practice with the rest of the framework to allow instantiations of the unified process which can conform to the UMM-ISO.

These extensions have been implemented as plugins for the EPF to enable process engineers to implement them as is or customize them using the EPF Composer.

Further works will include extending the analytical work on others instantiations of OpenUP/UMM-ISO, full assessment of these instantiations and evaluate the feasibility of OpenUP extensions to reach the highest levels at UMM-ISO.

  (a) N (Not achieved): there is no evidence of the achievement (numeric score: 0) (b) P (Partial): implementing the activities included in OpenUP allows a partial achievement of the attribute (0 <= score <= 0.3) (c) L (Large): implementing the activities included in OpenUP allows a large achievement of the attribute (0.3 <= score <= 0.7) (d) F (Full): implementing the activities included in OpenUP allows a full achievement of the attribute ( 0.7 <= score <= 1) 4.

Fig. 2 .

 2 Fig. 2. UMM-ISO capability profile for configuration OpenUP/Basic. References: Range 0 to 0.3: Partial achievement, 0.3 to 0.7: Large achievement, 0.7 to 1: Full achievement

  Tailor the UCD process ─ Specify requirements and objectives of user experience ─ Understand and specify the context of use ─ Designing the user experience ─ Components of interaction design ─ Review the design of the user experience ─ Preparing for usability testing ─ Run usability tests ─ Design and produce material training and user support ─ Providing training and user support

  To keep the focus on UX during the entire lifecycle giving developers concrete guides for developing and evaluating design solutions. ─ To set acceptance criteria for usability testing • Relations (roles involved, input and output work products): ─ Roles: UX specialist (primary performer), Users representative, Technical domain leader, Analyst (additional performers) ─ Input: User model, Task model, Project goals ─ Output: Usability goals • Steps (instructions for the performer, fully described in real specification) ─ Get information from available models ─ Identify and outline usability goals ─ Prioritize usability goals ─ Document usability goals ─ Review and get agreement on usability goals

Fig. 3 .

 3 Fig. 3. Relations map between UCDev tasks and UMM-ISO processes

3.1 Open source Unified Process (OpenUP)

	OpenUP is the open source version of the Unified Process (UP) released as part of the
	Eclipse Process Framework (EPF) project[19] (an extensible set of framework, tools
	and sample content for authorship, configuration and publication of methods and
	processes). The EPF's metamodel is based on version 2.0 of the Software & Systems
	Process Engineering Metamodel Specification (SPEM) by the Object Management

UX stands for User eXperience

Henceforth, we will use the term "User Centered" instead of "Human Centered" used in UMM-ISO. While both express the centrality of all those involved in the final system, User Centered is the preferred term by the HCI community.

Acknowledgments. The author thanks to the team of Project eSidif (Ministry of Economy, Argentine) for the collaboration provided during the work reported here; also to the reviewers for their insightful comments to the first version of this paper.

0.3 X HCD.5Produce design solutions HCD.5.1Allocate functions 0.3 X HCD.5.2Produce composite task model X HCD.5.3Explore system design 0.7 X HCD.5.4Use existing knowledge to develop design solutions 0.3 X HCD.5.5Specify system and use X HCD.5.6Develop prototypes 0.3 X HCD.5.7Develop user training X HCD.5.8Develop user support X HCD.6 Evaluate designs against requirements HCD.6.1Specify and validate context of evaluation 0.3 X HCD.6.2Evaluate early prototypes in order to define the requirements for the system X HCD.6.3Evaluate prototypes to improve the design 0.3 X HCD.6.4Evaluate the system in order to check that the stakeholder and organisational requirements have been met 0.3 X HCD.6.5Evaluate the system in order to check that the required practice has been followed X HCD.6.6Evaluate the system in use to ensure that it continues to meet organisational and user needs X