Tom Gross

UCProMo-Towards a User-Centred Process Model

Keywords: Software Engineering, Human-Computer Interaction, Process Model, Methods and Tools

The field of Software Engineering has a long tradition of developing sophisticated process models and methods and tools for its support. At the same time in the field of Human-Computer Interaction process models, methods, and tools have been developed and standardised internationally. Approaches from both fields have a lot to offer. However, despite great approaches for joining strengths and advantages of both fields, synergies are not yet fully used. In this paper I present the UCProMo User-Centred Process Model that provides an integrated approach by leveraging on existing process models, methods, and tools from both fields. UCProMo capitalises on clear phases, iteration, and strong involvement and participation of users throughout the whole process, which leads to integrated results and models of technology (esp. software) and ultimately to smooth user journeys through the whole system.

Introduction

In any kind of endeavour to design and develop systems, a structured approach is indispensable. This particularly applies to Software Engineering (SE) and Human-Computer Interaction (HCI). Process models support a structured approach by suggesting process phases and the order in which those phases should be gone through.

In SE over the last decades many great process models have been presented. The traditional waterfall model already provided a list of steps [START_REF] Royce | Managing the Development of Large Software Systems[END_REF]. Later, Boehm published the famous 'Spiral Model of Software Development and Enhancement' in [START_REF] Boehm | A Spiral Model of Software Development and Enhancement[END_REF]. It suggests to go through the steps in a spiral from inside out and to continually expand the results of each phase in each circle. The Unified Process [START_REF] Jacobson | The Unified Software Development Process[END_REF] has been a big leap and seen many variations and refinements. Many other process models contributed to a heterogeneous landscape of process models.

In HCI a parallel emergence and evolution of process models could be witnessed. These models have many similarities with those in SE. Yet, two distinctions are that in general in HCI the involvement of users throughout the whole process played a central role, and the evaluation of the results with users had a high priority. For instance, the 'Star Life Cycle' of Hartson & Dix [START_REF] Hartson | Human-Computer Interaction Development: Concepts and Systems for Its Management[END_REF] suggested that from any phase there should be a connection to an evaluation phase that is in the heart of the process model. The diversity of process models within HCI, eventually led to a standard pro-cess model for the 'Human-Centred Design of Interactive Systems' recommended by the International Standardisation Organisation (ISO) in the ISO 9241-210 [START_REF]Ergonomics of Human-System Interaction -Part 210: Human-Centred Design for Interactive Systems[END_REF].

Great contributions have been made towards combining approaches from SE and HCI. Most prominently, Usage-Centred Design is based on the idea to use 'abstract models to solve concrete problems' [8, p. 26]. It combines the HCI perspective of an early focus on users, their tasks, and their contexts with the SE paradigm of a strong focus on clear abstract models for analysis and design. Later, Activity Theory was integrated into the Usage-Centred Design model to become the Human Activity Modelling approach with better representations of human use of tools and artefacts [START_REF] Constantine | Human Activity Modelling: Towards a Pragmatic Integration of Activity Theory and Usage-Centred Design[END_REF]. Nunes picked up the strong orientation of actual usage or use and suggested a usecase-driven software development approach to combine SE and HCI [START_REF] Nunes | What Drives Software Development: Bridging the Gap Between Software and Usability Engineering[END_REF].

Despite such great approaches for joining strengths and advantages of both fields, the potential for synergies is not yet fully used. Clearly both communities-the SE and the HCI-have reached out mutually. For instance, agile approaches put a strong focus on users and early on put a priority to user stories and user interfaces, etc. [START_REF] Ambler | Agile Modelling: Effective Practices for eXtreme Programming and the Unified Process[END_REF]. Yet, a challenge that remains is that some basic paradigms in SE and HCI are not commensurable. For instance, by and large in SE the perspective is abstract that leads to a great overview by focusing on the fundamental structure and behaviour of the overall system, and in HCI it is concrete that gives a detailed impression of the user interface by early focusing on the user experience. These perspectives shine through-even in combinations such as Usage-Centred Design there is a clear priority for models over interfaces; the authors call it a 'model-driven approach' [8, p. 42]. Other approaches such as the Human Activity Modelling offer a compromise of perspectives, but at the price of losing the original expressive power of both sides (i.e., high abstraction in SE; high concreteness in HCI).

In this paper I present the UCProMo User-Centred Process Model that provides an integrated approach by leveraging on existing process models from SE and HCI. Using the UCProMo model is easy and straightforward-designers and developers individually or in teams just need basic knowledge and experience in either field. Overall the approach follows the requirements for light, agile, and lean development published very recently in [START_REF] Jacobson | Use-Case 2.0[END_REF]. In the next section I discuss the background and related work of process models in SE, HCI, and beyond. Then I present the UCProMo User-Centred Process Model with its generic method-agnostic processes. A discussion and conclusions summarise the contributions and glance at future work.

Background and Related Work

Three categories of process models are relevant to our approach-process models from SE, from HCI, and combinations.

Process Models in SE

The field of SE has a long tradition of sophisticated process models and methods and tools for its support. Sommerville explains: 'the systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product.' [19, p. 9]. And he continues: 'a software process model is a simplified representation of a software process. […] These generic models … are abstractions of the process that can be used to explain different approaches to software development.' [19, p. 28].

The waterfall model and the spiral modal are important early predecessors. The waterfall provided a detailed list of steps everybody should follow: system requirements; software requirements; analysis; program design; coding; testing; operation. It foresaw small iterations [START_REF] Royce | Managing the Development of Large Software Systems[END_REF]. Its fundamental contribution was to lay out basic steps that are still relevant today. Later, Boehm published the 'Spiral Model of Software Development and Enhancement' [START_REF] Boehm | A Spiral Model of Software Development and Enhancement[END_REF]. It suggests to go through the steps in a spiralinside out-and to continually expand the results of each phase in each cycle. The very important take away message-that is still important today-is to iterate and especially to continually re-evaluate the results.

More recently, the Unified Process was suggested as a 'set of activities needed to transform a user's requirements into a software system' [14, p. 4]. It is use-case driven (i.e., it departs from users and functionality for them); architecture-centric (i.e., all static and dynamic aspects of the system to be built); and iterative-incremental (i.e., it 'divides the work into smaller slices or mini-projects.' [14, p. 7]). Each cycle has four phases: inception (i.e., development of ideas), elaboration (i.e., specification of use cases and design of system architecture, construction (i.e., development of the system), and transition (i.e., movement from development via first beta-tests towards deployment). Orthogonal to the phases the Unified Process defines five core workflows. Requirements mainly fall into inception and elaboration; analysis mainly into elaboration; design between elaboration and construction; implementation into construction; and test between construction and transition [START_REF] Jacobson | The Unified Software Development Process[END_REF]. The Unified Process was probably the biggest leap towards systematically including users and users' needs and requirements. Since then many variations and refinements were suggested-a very wide-spread being the Rational Unified Process by Kruchten [START_REF] Kruchten | The Rational Unified Process: An Introduction[END_REF].

Process Models in HCI

In HCI many process models have been suggested. Despite the fact that the basic goal and also some basic steps are the same as in SE there are quite some differences.

For many years the HCI community has been using a standard process model with the title 'Human-Centred Design of Interactive Systems'. It is now part of the ISO 9241 on Ergonomics of Human-System Interaction in the part ISO 9241-210 Human-Centred Design Processes for Interactive Systems [START_REF]Ergonomics of Human-System Interaction -Part 210: Human-Centred Design for Interactive Systems[END_REF] (formerly it was published in ISO 13407:1999 [START_REF]Human-Centred Design Processes for Interactive Systems[END_REF]). Its processes are: identification of the need for human-centred design; understanding and specification of the context of use; specification of the user and organisational requirements; production of the design solutions; and evaluation of the design against the requirements. Also Unified Reference Frameworks have been developed to facilitate the process of developing user-centred systems by abstracting from hardware properties in abstract user interfaces [START_REF] Calvary | A Unifying Reference Framework for Multi-Target User Interfaces[END_REF]. And, Contextual Design offers a process model that has a strong focus on understanding users activities and requirements in the context where the users are using the system [START_REF] Holtzblatt | Contextual Design[END_REF].

Process Models that Combine SE and HCI

Out of the approaches that combine process models from SE and HCI the Usage-Centred Design and the Human Activity Design have been most influential to our approach.

The Usage-Centred Design (UCD) draws from the Unified Process and combines it with principles from HCI. Like the Unified Process it is based on models; it uses 'abstract models to solve concrete problems' [8, p. 26]. Whereas the Unified Process suggests models that roughly correspond to its core workflows (i.e., a use-case model; an analysis model; a design model; a deployment model; an implementation model; and a test model), the UCD has three simple models at its core: the role model representing the relationships between users and the system; the task model showing the structure of the tasks that users need to perform; and the content model laying out the functionality of the user interface. Through the focus on these three principal models UCD aims to move away from an early focus on concrete users and concrete user interface designs that often prevail in HCI.

In the later Human Activity Modelling (HAM) [START_REF] Constantine | Human Activity Modelling: Towards a Pragmatic Integration of Activity Theory and Usage-Centred Design[END_REF] Constantine extended his UCD with Activity Theory. The cornerstones are activities, which are basically seen as a collective endeavour in which a community of participants transforms a material into an object. This community of participants uses tools and applies rules and division of labour to organise itself. HAM has three principal models: the activity context model that did not exist in UCD represents human activities; the participation model is an adaptation of the role model and describes user roles, yet now including the context of the activities in which they occur; and the performance model is based on the previous task model and contains user actions targeted at either other users or artefacts.

Summary of Background and Related Work

Overall the gap between both fields has not been fully bridged. As we have seendespite the great progress in process models in SE and in HCI as well as stimulating combinations of SE and HCI approaches in the UCD and HAM-an integrated approach that leverages on the expressive power of both SE and HCI and can be flexibly applied by designers and developers of software with any knowledge and experience is still missing.

The related work also shows that some terms are not used consistently, which can be misleading-especially with respect to clearly distinguishing users and developers. For instance, as we have seen in the quotes above, the term activity has been used in the literature to refer to both, the things that developers are doing to develop concepts and systems and the things that users are doing with the system. In order to disambiguate terms this paper uses the following: a process refers to the whole endeavour of developing a system from the beginning to the end and independently of the path that is taken. A phase refers to a distinct and significant part of the process. Iteration refers to one cycle of steps that can be repeated eventually. The terms task, activity, and action are only used for user interaction with the system.

The UCProMo User-Centred Process Model

In the this section I present the UCProMo User-Centred Process Model with its generic method-agnostic phases. The related work above provides great stimuli for our process model. It leads to the following requirements for our process model that can be seen as an aggregated summary of the different advantages and strengths: • Phases should be clearly defined and have definite beginnings and endings while at the same time allow flexible coupling, feedback and feedforward to other phases for an iterative as well as incremental process. • Abstract modelling that allows keeping the complete system in focus should be combined with concrete users, user requirements and needs, and designs. • Heterogeneous approaches and results throughout analysis and exploration, specification, design and development, and testing should be supported. • There should be a clear paradigm of analysis (i.e., modelling the status quo) on the one hand and design (i.e., modelling the future system) on the other. At the same time analysis and design should go hand in hand; and appropriate redesign should always be possible (i.e., this is in contrast to UCD and HAM where tasks are primarily analysed and modelled rather than (re-)designed). Subsequently I introduce the core phases of the UCProMo User-Centred Process Model.

Plan the Human-Centred Design Process

Before the actual phases of the human-centred design process (HCD) can start, all parts of the project need to be planned and time and resources need to be allocated. This can be seen as phase zero of the process. At the beginning it should be clarified how usability is addressed throughout the whole process. The ISO 9241-210 recommends: to analyse 'how usability relates to the purpose and use of the product, system or service (e.g., size, number of users, relationship with other systems, safety or health issues, accessibility, specialist application, extreme environments); and to estimate how bad usability might negatively influence the project by analysing 'the levels of the various types of risk that might result from poor usability (e.g., financial, poor product differentiation, safety, required level of usability, acceptance)'; and finally, to be clear about the general conditions of the project in the sense of the 'nature of the development environment (e.g., size of project, time to market, range of technologies, internal or external project, type of contract)' [13, p. 8].

Understand and Define Users, Tasks, and Contexts

After the project planning the first real phase aims at understanding and specifying users, tasks, and contexts. The best way to do that is to go through the following steps: produce an inventory of all items; describe a profile of the most central characteristics for each item; and chart a map of the structure and relationships among all items.

The user model consists of the user inventory; user profiles; and a user map.

The user inventory contains the essential roles (e.g., author of a book), and role characteristics (e.g., expectations, responsibilities), as well as the essential user characteristics that have an influence on how they play their role (e.g., knowledge, skills, experience). For the user profiles it is advisable to identify permutations of common essential user roles and user characteristics and generate profile descriptions for them (e.g., author of a book with limited technical knowledge). The user map is a chart consisting of a node as a standardised labelled icon for each individual user profile and links as lines representing connections between them. In the basic form simple links are used, if needed, links can have types and directions to represent specific relationships among users (e.g., a hierarchy). If more semantics are preferable, further details can be added to the nodes representing central characteristics visually (i.e., an active role which actively participates vs. a focal role which is mandatory vs. a passive role of audience who passively participates). Fig. 1 shows a simple example of a user map.

The task model consists of a task inventory; task profiles; and a task map. The task inventory is a collection of all essential tasks, where each task consists of events and processes that are clustered together and have a logical sequence (e.g., invite coauthor for writing book together). Very often tasks are nested and a hierarchical decomposition helps for gaining a better understanding. Tasks are comparable to usecases in SE, and to scenarios in HCI in that they also represent and structure the users' activities. Each task profile contains a structured description of a sequence of user activities that is free of technical details. The task map is-like the user map-a chart that puts the essential individual tasks into perspective and in relation to each other. Since for large systems task maps can get quite complex, it is very important from the beginning to focus on essential tasks that are of vital interest to the users as well as the project team. In analogy to user maps, in the simplest form, the task map provides a simple, yet informative, overview containing a node as a standardised labelled box for each task and links as lines showing connections between them. To add more semantics links can be typed (e.g., showing temporality, specialisation, extension, or composition). Fig. 2 shows a simple task map.

The context model consists of a context inventory; context profiles; and a context map. Here a context is defined as: 'the interrelated (i.e. some kind of continuity in the broadest sense) conditions (i.e. circumstances such as time and location) in which something (e.g. a user, a group, an artefact) exists (e.g. presence of a user) or occurs (e.g. an action performed by a human or machine)' [9, p. 286]. The context inventory brings together all contexts in which users perform their tasks. Furthermore, mobile use needs to be considered when analysing the context. The context profiles should for each context or trajectory identify all information relevant to the user performing the respective task. A profile should include the technical (e.g., hardware, software, network connectivity), the physical (e.g., noise, thermal conditions, vibration, space and furniture), the organisational (e.g., work practices, assistance, interruptions), and the social environment (e.g., other persons in the same room). The context mapanalogous to the user map and the task map-provides a visual overview of all contexts and their relations. It shows individual contexts as nodes in labelled boxes and links between contexts as simple lines. Again, in the basic form the context map includes all contexts and their connections; in more detailed versions the links represent the relationships between contexts-contexts can have temporal relations (e.g., followed-by) and can be nested (e.g., contains vs. part-of).

Specify System Requirements

This phase also defines a core model-the integration model. Despite the similarities and overlaps with the models that define users, tasks, and contexts there is one essential difference regarding the attitude with which the model is created in this phase: whereas in the previous phase the models have pure analytical purposes and document the state-of-the art, the model of this phase is design-oriented and anticipates, specifies, and defines future aspects of the system and related issues.

The integration model provides a hierarchical description of the task that users can perform with the future system, where activities are interactions with the system towards solving specific problems and with a purpose. Activities are composed of actions, and actions are composed of operations. For instance, an activity could be to write an email, where a specific action could be to add a recipient, which is done operationally by selecting an entry from the address-book and adding it to the 'To:' field of the email program. The integration model consists of integration profiles and an integration map; and it is complemented by the performance map. The integration profiles specify the design of future activities the system should support and aim to inform interaction design. They consist of four parts: purpose describes the motive and objective of the respective activity; place and time describe the context of the activity in terms of time and location it takes place; participation describes the user roles (and characteristics) involved in the activity; and performance provides details how the activity is performed. The integration map is a complex chart that not only builds on and integrates the user map, task map, and context map from the previous phase, but also moves from a presentation of the state-of-the-art to an anticipation and specification of the future system. It consists of different categories of nodes representing users with activity levels, roles, centrality; and tasks that are clustered into contexts. Fig. 3 shows an example of an integration map (please note that the symbols for boundary, control, and entity class resemble to the extensions of the graphical notation of UML by [14, p. 439]).

The performance map goes beyond the task map and is also design-oriented rather than analysis-oriented. In the simple version the performance map includes nodes as standardised labelled boxes representing activities and links as untyped connections between the nodes. The basic model can be extended by tasks-so for each decomposable activity all contained tasks are drawn into the model. This provides more information on the users' interaction with the system. Fig. 4 shows a generic example of a performance map.

Design User Tasks, and User Interactions

The tasks designs and interactions designs should-given they were carefully specified-logically follow from the previous models. Theoretically task designs describe how the users will accomplish their tasks with the system, whereas interaction designs illustrate how the tasks will exactly be performed with the future system. With the aim of remaining generic in the UCProMo process model (i.e., not diving into concrete screen designs, etc.) the two perspectives are combined into one unified interaction space model. This model describes the interaction between the users and the system in the form of summaries of the abstract path the users can take through the system. It consists of interaction space profiles, and an interaction space map.

The interaction space profiles contain abstract, yet detailed, information on individual interfaces in terms of its information contents and interaction components for user input. It is important to note that the interaction space profiles initially do not need to have any visual representation (e.g., showing the proportions of the different parts of the user interface). Interaction space profiles resemble essential use cases of Usage-Centred Design [START_REF] Constantine | Software For Use: A Practical Guide to the Models and Methods of Usage-Centred Design[END_REF]. However, approaches such as Usage-Centred Design [START_REF] Constantine | Software For Use: A Practical Guide to the Models and Methods of Usage-Centred Design[END_REF] and Contextual Design [START_REF] Holtzblatt | Contextual Design[END_REF] often proceed in a bottom-up manner-that is, depart from individual cases and aggregate them. The UCProMo suggests a hybrid approach, where the interaction space profiles and map are developed in sync having the user journey or customer journey in mind. This is important for many reasons-such as for consistency in similar interaction types among individual profiles.

The interaction space map has nodes as standardised labelled boxes for each interaction space as well as links as lines representing connections of interaction spaces. The connections between the interaction spaces are navigation paths that the users can follow when using the system. This map provides a general overview of the interaction space landscape, and additionally serves as a tool to judge and optimise the breadth and depth of the user interaction. In fact, when designing the interaction space model there is a trade-off between having simple interaction spaces with few elements (and consequently a high number of interaction spaces to cover the whole functionality) and having complex interaction spaces with many elements (and consequently fewer interaction spaces and less navigation effort for the users). Fig. 5 shows an excerpt of an interaction space map.

Develop the System

The actual implementation and test of the system are core activities in each process model-both in terms of their importance for the overall success of the project, and in terms of the money, time, and other resources spent in this phase in comparison to the other phases.

Still, the actual implementation is in many process models only briefly covered. This probably has several reasons, one of which being that it is a rather practical endeavour and a completely different terrain. As Jacobson et al. write in their book on 'The Unified Software Development Process' in the introduction to their chapter on 'Implementation': 'Fortunately, most of the system's architecture is captured during design. The primary purpose of implementation is to flesh out the architecture and the system as a whole.' [14, p. 267].

Evaluate the System

The evaluation of the system from a HCD perspective in general (besides expert evaluations and simulations) involves direct contact with users-typically presenting them some results and getting feedback. These results do not only refer to the final product, but also to any result that is generated throughout the process-particularly including the different models that can and should be verified with users.

ISO has clear recommendations on how evaluations should be done. They should include adequate allocation of resources to evaluation; early planning of evaluation; enough testing and analysing of the results and eventually prioritising the reactions triggered by the results; and appropriate communication with all stakeholders involved [START_REF]Ergonomics of Human-System Interaction -Part 210: Human-Centred Design for Interactive Systems[END_REF].

As a matter of fact user evaluation is also a vital part of the overall software testing that is very important for any kind of software (and hardware) project. From this perspective the software test has two goals [START_REF] Sommerville | Software Engineering 9[END_REF]: to show that the software successfully fulfils all requirements; and to eventually find problems which can then be solved. It is important to note what Sommerville-quoting Dykstra-points out: 'Testing can only show the presence of errors, not their absence' [19, p. 206]. Likewise user evaluation can only proof the effectiveness (degree to which the users reach their goal), efficiency (effort that is required to reach the goal), and satisfaction (comfort and pleasure when using the system) of the current users, and only assume that the same holds true for future user populations.

Deploy the System

The final phase after a successful evaluation is Deploy the System. A successful evaluation can happen already in the first iteration, or in later iterations, and at least theoretically it could also be possible that it never happens but that the system is still rolled out. This phase is beyond the scope of this paper.

In this paper I motivated the need for an integrated process model leveraging on both SE and HCI processes. I introduced the generic UCProMo User-Centred Process Model with its phases and models that can be easily followed and produced by designers and developers without an SE or HCI background.

UCProMo supports clearly defined phases and iterative and incremental feedforward and feedback cycles. It combines abstract modelling from SE with concrete user experience design from HCI. And it supports the whole range of activities from analysis and exploration to specification to design and development and testing. Finally, it is lean and lightweight but at the same time has built-in redundancy between analysis and design-that is, it documents the state-of-the-art in user, task, and context models for analysis; and it generates an integration model (i.e., integration map and performance map) as abstract representation of the statics and dynamics of the future system and the interaction space map as concrete design of the interaction with the future system.

It is on purpose that the interaction spaces and the interaction space map in the design phase resemble use-cases that are in many process models very early in the analysis phase. Indeed, human-centred analysis and design should not take for granted and analyse the activities as they are and build a system around them, but rather it should creatively reflect current practice and-together with the users-eventually redesign activities where appropriate. An example of theory-based creative modelling is [START_REF] Beckmann | Social Computing -Bridging the Gap Between the Social and the Technical[END_REF], where the authors depart from a framework of social interaction from social science as input for their models.

The fact that UCProMo aims at rapid modelling should not be confused with other approaches with similar goals. For instance, agile modelling by Ambler has great suggestions on how to apply existing UML models and notations in a lean way [START_REF] Ambler | Agile Modelling: Effective Practices for eXtreme Programming and the Unified Process[END_REF]. The UCProMo, however, suggests generic models that complement existing UML models and notations.

Finally, I did not have the space to address basic principles that apply to many areas of design likewise. For instance, Cockton has suggested 'meta-principles for any design process: receptiveness, expressivity, committedness, credibility, inclusiveness, and improvability' [5, p. 2223].

While the process model leverages on fantastic input from great existing work in HCI and SE, it still would benefit from a proper validation. In the future it should be applied to human-centred software engineering projects to get feedback of designers and developers.

Fig. 2 .

 2 Fig. 2. UCProMo Task Map example.

Fig. 1 .

 1 Fig. 1. UCProMo User Map example.

Fig. 3 .

 3 Fig. 3. UCProMo Integration Map example with a text production context (top) and a text consumption context (bottom).

Fig. 4 .

 4 Fig. 4. UCProMo Performance Map example.

Fig. 5 .

 5 Fig. 5. UCProMo Interaction Space Map excerpt.

Acknowledgements

I would like to thank all members of the Cooperative Media Lab in Bamberg as well as the colleagues from the Madeira Interactive Technologies Institute for inspiring discussions. Thanks to the anonymous reviewers for great feedback.


Balbir S Barn

Do You Own a Volkswagen? Values as Non-Functional Requirements

Of late, there has been renewed interest in determining the role and relative importance of (moral) values in the design of software and its acceptance. Events such as the Snowden revelations and the more recent case of the Volkswagen "defeat device" software have further emphasised the importance of values and ethics in general. This paper posits a view that values accompanied by an appropriate framework derived from non-functional requirements can be used by designers and developers as means for discourse of ethical concerns of the design of software. The position is based on the Volkswagen "Dieselgate" case study and a qualitative analysis of developers views from Reddit discussion forums. The paper proposes an extension of an existing classification of requirements to include value concerns.

Introduction

Values are a key driver of human behaviour and are seen as an important component in societal and environmental sustainability. However, current software engineering practice does not pay sufficient attention to the notion of values given the role of software and systems in so-called "smart city" sustainability actions. Critically, there is no sufficiently expressive machinery to describe how values such privacy and security are elicited, negotiated, mediated and accommodated in systems design beyond either early stages such as contextual design. For the purposes of this paper, values are what Friedman refers to: ownership and property; privacy, freedom from bias, universal usability, trust, autonomy, informed consent and identity. She defines values as : what a person or group of people consider important in life [START_REF] Friedman | Value-sensitive design[END_REF].

The paper's position is motivated by the recent so-called "Dieselgate" media story concerning Volkswagen. On 18th September 2015, Volkswagen, USA was accused by the US Environment Protection Agency (EPA) of installing an illegal "defeat device" software that dramatically reduces nitrogen oxide (NOx) emissions -but only when the cars were undergoing strict emission tests.

This paper advances the notion that (moral) values are distinct from non functional requirements or even softgoals as in goal oriented requirements engineering (GORE) approaches but can benefit from being incorporated into Non-Functional Requirements (NFR) frameworks. In order to present this position, the paper takes a case example approach. Firstly, a summary outlining the key issues arising from the Volkswagen "defeat device" is presented in section 2. The case example is analysed with respect to value concerns. In contrast to other recent analyses of the Volkswagen case [START_REF] Spinellis | Developer, debug thyself. Software[END_REF], the paper augments the analysis by taking concrete views from developers. Evidence is drawn from the Reddit discussion forum section on Coding where developers posted 80 items over a four day period [START_REF]rouge" software engineers blamed for vw emissions ([END_REF]. Section 3 presents this analysis. In doing so, this paper concretely proposes how an existing classification mechanism for requirements can be extended. Section 4 draws on the academic literature on values, ethics and non functional requirements to provide further support for the proposition that values can be classified as a special case of non-functional requirement. In section 5, the paper concludes by offering a roadmap for further research.

Case Study and Approach

Interpretative, exploratory case study research is a first step to understanding phenomena as input for further research. The Volkswagen case study is important from two perspectives: Firstly, its impact on environmental pollution and secondly, the subsequent apportioning of blame on software engineers responsible for the "defeat device" software and their (implicit) unethical actions. A descriptive (non-value laden) account of the Volkswagen case study is presented next using the investigative reports from two quality newspapers, the Guardian and the New York Times.

Volkswagen case study

The story was first reported in the media on the 18th of September, 2015 with a claim that around 482,000 cars were affected in USA. However this story begins much earlier. In 2014, a non-profit group, the International Council on Clean Transportation worked with the California Air Resources Board and researchers at West Virginia University to conduct on-road diesel emissions tests of cars including two Volkswagens and a BMW X5. The researchers found that when tested on the road some cars emitted almost 40 times the permitted levels of nitrogen oxides yet performed flawlessly in lab conditions. Subsequently the federal body and the Environmental Pollution Agency (EPA) were both involved in negotiations with Volkswagen. Eventually in September 2015, when delays on announcing new 2016 models could not be explained, the EPA announced the violation of the Clean Air Act [START_REF]Clean air act (united states)[END_REF]. The basis of this violation was the discovery of software sub-routines that detected when the car was being tested and then activated equipment that reduced emissions. But the software turned the equipment off during regular driving, increasing emissions far above legal limits, possibly to save fuel or to improve the car's torque and acceleration. Note that while all cars undergo strict emission tests, manufacturers have always been able to manipulate the settings of the parameters for emission tests. The story developed and up to 11 million cars were affected [START_REF] Ruddick | Vw scandal: chief executive martin winterkorn refuses to quit[END_REF] leading to around 25 billion Euro being wiped off the company's market value [START_REF] Arnett | The scale of the volkswagen crisis in charts[END_REF]. Eventually, the CEO, Martin Winterkorn resigned but denied personal wrongdoing. At the same time. VW's CEO in USA, Michael Horn in a testimony before US Congress identified the true authors of his company's deception [START_REF]Hearing on volkswagen emissions violations[END_REF]: "This was a couple of rogue software engineers who put this in for whatever reason."

As a further justification, he described the "defeat device" as a line of code "hidden in millions of software code". Since then, following investigations in Germany, other senior managers appear to have been implicated and were suspended. Huber, the acting head of VW's supervisory board, called the crisis a "moral and policy disaster" and went on to say: "The unlawful behaviour of engineers and technicians involved in engine development shocked Volkswagen just as much as it shocked the public" [START_REF]Volkswagen executives describe authoritarian culture under former ceo[END_REF].

Since initial reporting of this case, Federal and California regulators have begun an investigation into a second computer program in Volkswagen's diesel cars that also affects the operation of the cars' emission controls.

Approach

A notable aspect of the media reporting of the Volkswagen defeat device story is the lack of discussion of ethical considerations that engineers are subject to, in the act of engineering a system. Both US and Germany have strong engineering codes of ethics yet these have not featured in any reporting. Given the relationship between ethics and values, this paper analyses this case study from that perspective and by drawing upon a qualitative analysis of the Reddit discussion forum section on coding. The thread, entitled: " 'Rouge'(sic) Software Engineers blamed for VW emissions (would this be a bug or feature?)" received 80 items that were posted over a over four day day period (12 Oct to 15 Oct) [START_REF]rouge" software engineers blamed for vw emissions ([END_REF].

The approach presented has reliability limitations of the analysis of the Reddit posts. A single developer forum was identified through search queries. Various forums such such as StackOverflow were investigated but there were no discussions about the Volkswagen "defeat device". There are a limited number of participants who posted discussion items. Although there are over 65,000 readers who subscribe to the coding forum, 27 participants posted comments, from which 7 posted at least twice. The data is is largely indicative and an appropriate future research avenue would be to explore developer's perspectives.

Case Study Analysis

The first question is one of ethics and its relationship to (software) engineering and the section begin with a provocative prompt:

"Engineers are the un-acknowledged philosophers of the postmodern world." [START_REF] Mitcham | The importance of philosophy to engineering[END_REF].

In part, the reason for this is straightforward: an engineer may not ask about what they should be doing, or may find that a solution that cannot be achieved by technical expertise alone. From this it follows that ethical judgements such as responses to questions of environmental protection following violations of the Clean Air Act are required. Hence, philosophy is an internal practical need. So did the "rogue" engineers alluded to by Horn seek this ethical judgement? A more complex explanation is also offered by Mitcham: engineering is modelling a new philosophy of life. One interpretation of this is: we have moved from a natural environment to one where we increasingly present humans as information-centric entities whose production and consumption of information occurs through engineered artefacts. Such a world demands continuous evaluation of ethical concerns.

The codes of engineering ethics such as that developed by the Association of German Engineers [START_REF] Christ | Fundamentals of engineering ethics[END_REF] 1 provide some insight as to what is expected in terms of norms of behaviour from engineers. For example:

-Engineers are responsible for their professional actions and tasks corresponding to their competencies and qualifications while carrying both individual and shared responsibilities. -Engineers are aware of the embeddedness of technical systems into their societal, economic and ecological context, and their impact on the lives of future generations. -Engineers apply to their professional institutions in cases of conflicts concerning engineering ethics.

The Engineering ethics principles also give guidelines on how to resolve conflicting values. In cases of conflicting values, engineers give priority: to the values of humanity over the dynamics of nature; to issues of human rights over technology implementation and exploitation; to public welfare over private interests; and to safety and security over functionality and profitability of their technical solutions. It would appear that the software developers responsible for developing and installing the "defeat device" violated a normative code of conduct. What is not known is whether the developers concerned were able to escalate it to their managers, their professional body and in the last resort, directly inform the public or refuse co-operation altogether as directed in paragraph 3.4 of the VDI code of ethics for engineers [START_REF] Christ | Fundamentals of engineering ethics[END_REF]. Both the media reporting and the posts on the Reddit Coding forum by developers find no mention of ethical concerns directly. For the latter, there are references and extensive dialogue that tries to account for defensive actions and how to minimise potential fallout:

gullibleboy : I agree. Thankfully, I have never been asked to write code that was blatantly illegal. And I would like to think I would have enough integrity to say no. But, I certainly would make sure to get written confirmation, from my superiors, to ensure that I was not made the patsy. Any seasoned developer would do the same.

Retaining evidence of written confirmation such as in email, while potentially difficult and desirable raises other legal issues.

LongUsername: Will be surprising to see if they have written evidence. It happened at least 5 years ago, and I know many companies with an automatic email deletion policy of about 2 years. Even if there were explicit instructions, unless the engineer thought enough to archive the email off (in violation of data retention policies), it may be gone.

Resolving conflicting values appears to be core philosophical action that engineers will always have to deal with. While the VDI code of ethics provides rules to apply in cases of conflict, it may not always be appropriate to recourse to the professional body. Some times conflict of values are also a proxy for conflicting goals. The comment by frezik below makes that point. It might be the case that the requirements specifications are poorly specified and the design process does not allow for the conflict resolution. It could also be possible that "requirements creep", created un-wanted changes that should not have got through an approval process.

mallardtheduck: In a "normal" vehicle, all profiles should conform to the relevant emissions standards. In this case, my suggestion is that VW's programmers/engineers started with "good" profiles and over the process of tweaking/improving them, ended up making the more common profiles violate said standards. Whether this was done deliberately or not is hard to say. Either way it's something that should have been caught and probably was, but was "hushed up" by persons higher up the chain.

The idea of a "rogue" software engineer is also interesting when observed from different perspectives. A "rogue" engineer could have inserted the software that did exactly what the company required against the express wishes of her manager. In which case, the problem is even bigger in terms of questioning the entire software engineering practice at Volkswagen.

PCLoad_Letter: From this you can draw the conclusion that there are no software audits on the code running millions of these cars and no one in QA or the engineering divisions even questioned when the emissions tests came back much lower that expected? That is a much bigger problem than a Rogue engineer.

Conversely, in his testimony to Congress, Michael Horn, although implausible, may have meant to imply that the engineers were "rogue" because they had not reported the software behaviour as required by the engineering codes of practice and their company. A notion gently supported by a developer:

MuonManLaserJab: For it to be "rogue engineers", they would have had to decide to keep the facts a secret while writing the cheat...

It is constructive to consider why the developers on Reddit have focussed on defence rather than ethical concerns. Partly, it is explained by how engineers work. The way that engineering (and code development) happens as reported in [START_REF] Mitcham | The importance of philosophy to engineering[END_REF] by Louis Bucciarelli in his ethnographic studies of engineers: when students are doing engineering problems it is generally thought that they "ought not to get bogged down in useless 'philosophical' diversions" [6, pp. 105-6]. At this stage of their engineering career, students are practicing to be engineers. The developer's world (when they are engaged in problem solving) is also highly abstract. It is one of programming syntax, data structures, and program comments that refer only to functional requirements. Such an abstract world does not leave room for ethical concerns that might have serious implications for society at large. The question arises: where and how in the process of design can these critical diversions be accommodated? The problem is further compounded by deadline pressures resulting in poor decisions and is also offered as an explanation.

frezik: The situation I'm thinking of here is when the programmer is told "we need the ECU tweaked on this car to make x mpg highway while passing emissions tests, and we need it by date y". They make a profile that makes the mpg requirement, and they make another profile that makes the emissions requirement. They try to combine them to meet both goals, but they run out of time. Under pressure, they do something stupid and illegal, and make the emissions test run when test mode is detected, and mpg mode otherwise.

Following on from ethical concerns, is a consideration of who else was involved the chain of decision making that led to the insertion of the "defeat device" software. The developers point out that software running the engine control unit would have gone through numerous code reviews.

rfinger1337 : VW has a responsibility to know whats in the code. It wouldn't get past testing, code review...

GuyNamedNate2 : It really depends on what their code reviewing /auditing practices are...I would hope and expect an organization as big as VW would have avionics-quality processes.

AllGloryToHypno-Toad : if this company is writing engine management software without code reviews and testing, then that's another issue. This should have come up and many, many times.

Modern software engineering can also create spaces whereby an engineer may not be aware that he has violated his engineering ethics codes. For example, component based design mandates black box design through well defined interfaces that supports specific functional requirements. Developers may end up writing code for a software component without an awareness of the wider context of where that component may be used. Thus we see:

LongUsername: Unfortunately, The real coders may not have known what they were doing. Tell the programmer who does the emissions system to "disable the emissions system when this flag over here is set... It's for test-purposes only." and tell the guy working on the steering system "when the wheel doesn't change position for X amount of time, set this global flag over there that says we're on a Dyno".

Cultural issues within the organisation are also of concern. The engineering community either chose deliberately to not report the rogue engineers to the organisation or even outside, or were not able to because of the cultural climate. A Reuters report published in the Guardian on 10th October described the culture under the former CEO, Martin Winterkorn [START_REF]Volkswagen executives describe authoritarian culture under former ceo[END_REF] as authoritarian. Bernard Osteloh was quoted as saying: "We need in future a climate in which problems aren't hidden but can be openly communicated to superiors...We need a culture in which it's possible and permissible to argue with your superior about the best way to go.". The reality as presented by the developers is different: _Toranaga_: I dunno, fall guys get fired... Whistle-blowers get exiled to Siberia.

Values versus Non Functional Requirements

In this section, it becomes apparent that a common implicit position in current software engineering practice is that of non functional requirements (NFR) being used as as a proxy for accounting for values. The literature is examined and used to argue that existing approaches for managing NFRs would not have sufficed to prevent the Volkswagen case. A further argument advanced is that values need to be unpicked in order for them to be used effectively by engineers. Simply, we want to provide engineers with the necessary machinery to allow them to externalise their philosophical deliberations as they practice their craft.

Non Functional Requirements

NFRs have been extensively studied by the software engineering community as they are recognised as important factors to the success of a software project [12, for example]. Despite their importance, NFRs are poorly understood and often neglected in the software design process. A satisfactory understanding of NFRs remains elusive and is attributed to three key problems: lack of a workable definition; difficulties of classifying types of NFRs; and representing NFRs in the design process [START_REF] Glinz | On non-functional requirements[END_REF]. Further, once NFRs have been identified, they need to be assigned properties (attributes) which can be measured. Not all NFRs have attributes and notably, the systematic review by Mairiza et al shows that of the 252 types of NFR identified, over 50% were without attributes [START_REF] Mairiza | An investigation into the notion of non-functional requirements[END_REF]. This is relevant to values.

One consistent view of NFRs is: they are a quality attribute of a system that its stakeholders care about and hence will affect their degree of satisfaction with the system. These qualities end up being referred to as "ilities". Examples include: reliability, testability, usability, portability etc. Mairiza et al. identify 115 such quality characteristics [START_REF] Mairiza | An investigation into the notion of non-functional requirements[END_REF]. Such sayilities are hard to characterise in ways that can support rigorous engineering and are ultimately subjective and stakeholder specific [START_REF] Dou | An evolutionary theory-systems approach to a science of the ilities[END_REF]. Further, implementations of sayilities may be cross-cutting across many software components and may also impinge on the meta-systems used for constructing a system under question. [START_REF] Matoussi | A survey of non-functional requirements in software development process[END_REF][START_REF] Mairiza | An investigation into the notion of non-functional requirements[END_REF][START_REF] Berntsson Svensson | Managing quality requirements: A systematic review[END_REF][START_REF] Jaramillo | Requirements elicitation approaches: A systematic review[END_REF]. While security and privacy are both moral values, their treatment as NFRs are from a system perspective and not from that of the end user's moral concerns. A survey of software architects to consider NFRs conducted by Ameller et al. also found that values as we define them do not feature as NFRs even in a category of non-technical NFRs (i.e. not those such as performance etc.) [START_REF] Ameller | How do software architects consider non-functional requirements: An exploratory study[END_REF]. Overall, this implies a conclusion where, either values are systematically ignored in the practice of NFR elicitation or values may not be NFRs. Certainly, the ethics/values discussions did not feature strongly in the media reporting and the coder's comments on Reddit.

An inspection of several empirical studies all omit any consideration of treating values as NFRs

We now consider the relevance of techniques of requirements engineering to values. Over recent years, goal oriented requirements engineering (GORE) [START_REF] Mylopoulos | From object-oriented to goal-oriented requirements analysis[END_REF] has began to dominate practice [START_REF] Jaramillo | Requirements elicitation approaches: A systematic review[END_REF] particularly with respect to NFRs with the NFR Framework [START_REF] Chung | Non-functional requirements[END_REF] being the most widely cited. In the NFR Framework, NFRs or goals that are hard to express (softgoals), and their decisions are captured in goal graphs and refined into detailed concrete goals. Others followingthe GORE tradition include i* [START_REF] Yu | Towards modelling and reasoning support for early-phase requirements engineering[END_REF]. GORE based techniques present a variety of options for analysis such as providing a more formal basis of how goals realise other goals, conflict between goals and the positive and negative contributions goals make to other goals and ultimately tradeoffs between goals. GORE approaches would appear to be a promising area for further examination from a values perspective.

Values and Value Sensitive Concerns

Investigating the intertwining and entailment of values and technology development has been an ongoing area of research mostly originating in the domain of human-computer interaction (HCI) [START_REF] Suchman | Do categories have politics? the language/action perspective reconsidered[END_REF]. In the HCI literature, values are identifiable entities that are built in by design or accident through the affordances of the technology [START_REF] Friedman | Value-sensitive design[END_REF]. These considerations have been termed Value Sensitive Design (VSD) by Friedman [START_REF] Friedman | Value-sensitive design[END_REF], who refers to: ownership and property; privacy, freedom from bias, universal usability, trust, autonomy, informed consent and identity.

This is contrasted with sociology and social psychology where values are criteria that are used to evaluate or make judgements about events or people encountered, helping explain individual and collective behaviour [START_REF] Bennett | Factors underlying the inclination to donate to particular types of charity[END_REF]. As social interactions become increasingly mediated by technology then these two interpretations of values merge and in doing so, they govern user action or non-action within technology [START_REF] Edwin | The motivation sequence, the motivation hub, and the motivation core[END_REF]. Thus design choices that explicitly consider values can change the affordances of resulting technologies [START_REF] Friedman | Bias in computer systems[END_REF][START_REF] Shilton | Values levers: Building ethics into design[END_REF].

The problem of identifying and qualifying values has many facets: their individual or shared nature; their realisation in concrete features; their subjective or objective location; their accidental or intended role with respect to system functionality [START_REF] Shilton | Charting sociotechnical dimensions of values for design research[END_REF]. A further complexity is that all these facets operate along a continuum so an intended or accidental property is not simply two possible states of a value. These complexities prevent their widespread acknowledgement and treatment. In particular, there is no general theoretical framework to allow stakeholders in the design process to identify, qualify and successively map into usable data the relevant values for the application at stake. In short, the understanding of values and their contribution to technology acceptance is not theoretically grounded into the entire software development lifecycle. As discussed earlier, GORE approaches (particularly, the use of softgoals) have the potential to represent values. However, softgoals cannot be directly linked to direct or indirect stakeholders. Further, '"Values are not goals, they are assumptions (more precisely, evaluations). A value is a judgment, though very general and vague. It says of something that it is good or bad. A goal is a regulatory state in someone's mind" ( [START_REF] Miceli | A cognitive approach to values[END_REF] reported by Pommeranz et al. [START_REF] Pommeranz | Elicitation of situated values: need for tools to help stakeholders and designers to reflect and communicate[END_REF]). It would appear that values and their multi-dimensional nature requires new GORE-like approaches that allow designers to engage in a philosophical discourse about their systems and their shaping of society.

Value Architectures

In summary, values are not referenced in meta reviews of NFRs, nor are example values listed as an "ility". So either values are systematically ignored in the practice of NFR elicitation or values may not be NFRs. The complexity of values cannot be accounted for by simple attributes and importantly, typical NFR elicitation approaches do not allow designers to engage in a necessary philosophical dialogue about those "...problems that engineers admit cannot be resolved simply with engineering methods alone....professional ethical issues." [21, p.31].

It is also clear that GORE based approaches, particularly the notion of softgoals, is a promising area of research for incorporating values as these provide qualitative mechanisms for resolution that are sufficient. Thus we propose the following:

1. Extend the Glinz classification to include a values category; 2. Develop processes and the necessary vocabularies to allow ethical discussions of the impact of values of design decisions that can contribute a "value architecture" in much the same way as functional requirements contribute to application architectures and NFRs lead to technical architectures of system.

Glinz proposed a classification of requirements based on concerns -something that is a matter of interest to a system. A concern is a performance concern if timing or volume is a matter of interest. The set of all requirements are partitioned into functional requirements, performance requirement, specific quality requirements and constraints. Alongside the classification, are a set of rules that are applied in order in order to classify a given requirement. We propose extending this classification and rule base as follows.

We introduce Value defined as: a requirement that pertains to value concern. Such a concern is classified by the introduction of an additional classification rule. "...a specific moral value that the system or component shall either support or prevent erosion of.". The resulting classification and rule set is shown in figure 1. The benefits of this extension allows us to specifically consider values as a concern in the requirements process. While it is relatively straight forward to develop measures for attributes such as Performance, defining a measure for value is much harder and requires agreement amongst stakeholders. By interacting with stakeholders using the trigger question, we open a channel for that necessary philosophical dialogue alluded to by Mitcham and necessary for the agreement.

Having addressed the requirements classification concern, the next stage is to develop value sensitive processes that can take advantage of the classification. The proposal here is to adapt the work of Yoo et al [START_REF] Yoo | A value sensitive action-reflection model: evolving a co-design space with stakeholder and designer prompts[END_REF] to support value elicitation, ethical discussions of the impact of values of design decisions and their capture suitable for engineers. Their work develops a framework for accounting for values using participatory design approaches. Evaluations on the efficacy of this approach have been reported elsewhere [START_REF] Barn | Resilience and values: Antecedents for effective co-design of information systems[END_REF] but the technical machinery to support this remains an ongoing research challenge. For example, can a value expression language be used to both specify value requirements, and provide input for technology acceptance models such [START_REF] Venkatesh | User acceptance of information technology: Toward a unified view[END_REF]? Such models use survey based research instruments that do not have questions about values. Practical considerations can be dealt with as functional requirement specifications are developed and be part of the descriptive frameworks used in requirement specification. A greater challenge is during the design of the software interactions. It is proposed that the trigger question can be integrated in processes that check if a requirement has been implemented. With regard to the the original case study, stages

Conclusion

The Volkswagen case study illustrates the importance of the role of ethics and its subsuming notion of values in software practice. Developers currently do not appear to engage in meaningful discussions about values that are explicit or those that emerge through the use of systems. It is notable, that the developers on the Reddit platform were relatively subdued in their discussion of ethical / value concerns. This paper has proposed that such hesitancy is partly linked to how functional and non functional requirements are managed. On the surface, values appear to have similarities with NFRs but the view is taken that just as NFRs present problems of representation, definition and classification, values may generate similar issues. Hence an extension of Glinz's concerns-based taxonomy for requirements that accounts for values is presented. In doing so, a channel for necessary dialogue with stakeholders about the ethics of decisions that programmers and designers is opened. Epistemological study to develop the necessary frameworks for such a dialogue is an important first step. Future research plans include: empirical data collection of values and their importance to relevant communities such as developers; the development of informal, semiformal and formal conceptual models of values and related concepts; and experimental evidence of evaluation of such models. Identifying where trigger questions can be incorporated is also a critical element in any processes. In today's hyperconnected world where systems are increasingly delivered in a pervasive form, such as through "apps" on smart phones, the risk to erosion of values, as well as, threats to social and societal sustainability are paramount. Values need to be formally accounted for in software engineering practice.

Fig. 1 .

 1 Fig. 1. Extension of Glinz's concern-based taxonomy and classification rules

http://www.vdi.eu/engineering/


Shinpei Ogata
email: ogata@cs.

Yugo Goto

Kozo Okano
email: okano@cs.shinshu-u.ac.jp

Framework for Relative Web Usability Evaluation on Usability Features in MDD

Keywords: Model Driven Development, Screen Transition Model, Usability Evaluation, Business Web Application, Operability, User Error Protection

Web usability in business applications is crucial for enhancing productivity and preventing critical user errors. One of the effective methods to enhance the usability is employment of usability features such as auto-complete and input validation. Then, such employment should be designed so as to conform to actual end-users. However, its evaluation forces developers to expend a lot of effort to design an application, to create its Web prototypes, to observe user operations with the prototypes, and to assess the usability of the employed usability features. In this paper, a framework is proposed for evaluating the usability depending on the employment efficiently even if the developers are nonusability-specialists. Our framework has characteristics as follows so that the developers can easily determine the usability with low creation costs.

(1) Support for creating Web prototypes, observing user operations, and assessing the usability are integrated centered on a model-driven approach. (2) The usability can be evaluated relatively and quantitatively by recording user operations and analyzing the resulting logs.

Introduction

Web usability in business applications is crucial for enhancing productivity and preventing critical user errors. Efficiency and the ability to avoid user errors belongs to "Operability" and "User error protection" respectively as subcharacteristics of "Usability" [START_REF]Quality Requirements and Evaluation (SQuaRE) -System and Software Quality Models[END_REF].

One of the effective methods to enhance the usability is employment of usability features [START_REF] Folmer | A framework for capturing the relationship between usability and software[END_REF], [START_REF] Juristo | Guidelines for eliciting usability functionalities[END_REF], [START_REF] Roder | Specifying usability features with patterns and templates[END_REF] such as auto-complete and input validation. Developers should evaluate the effectiveness of such employment in the early steps of application development because failure of the employment often causes fundamental restructuring a radical modification of the design of the interaction between the users and the application.

However, the evaluation forces developers to expend a lot of effort to design an application, to create its Web prototypes, to observe user operations with the prototypes, and to assess the usability of the employed usability features. What is worse, such evaluation is often iterated many times to adjust the employment. In addition to the effort problem, the observation and assessment requires a high degree of special knowledge even though usability specialists do not often participate in the development.

In this paper, a framework to improve the effort and special knowledge problems is proposed focusing on an important but limited area in the operability and user error protection. Our framework helps developers to efficiently evaluate the usability of usability features employed with low creation costs even if the developers are non-usability-specialists. The evaluation process is supported by our framework as follows.

Web prototype creation: Several different Web prototypes employing usability features can be generated from a screen transition model by applying our previous work [START_REF] Kamimori | Automatic method of generating a Web prototype employing live interactive widget to validate functional usability requirements[END_REF] in order to mitigate the effort problem. User operation observation: User operation logs consisting of browser events and input values are recorded in order to assess the operability and user error protection with input time and user errors respectively. User operation assessment: Many raw logs are processed in order to compare them relatively and quantitatively. This process also aims to help the developers to grasp the result of the observation easily.

The effectiveness of our framework is preliminarily evaluated by applying it to a part of a virtual e-commerce application. As a result of the evaluation, our framework quantitatively showed how the usability features affected the usability.

Usability in Ordinal Use of Business Web Applications

Usability generally covers various aspects of appropriateness recognizability, learnability, operability, user error protection, user interface aesthetics and accessibility according to ISO/IEC 25010 [START_REF]Quality Requirements and Evaluation (SQuaRE) -System and Software Quality Models[END_REF]. Enhancing usability can also enhance productivity of companies [START_REF] Nielsen | Usability Engineering[END_REF].

Scope Limitation

Our research aims to help skilled end-users to operate their Web application efficiently and correctly in normal use. In addition, our research also assumes that such end-users can be easily specified by a development project. Under this condition, the scope of usability is limited as follows.

-The priority of the appropriateness recognizability, learnability, user interface aesthetics, and accessibility is low in comparison with the operability, and user error protection because we target "skilled and specified" users. -Each skilled office worker knows generally an important or laborious part of his/her work even if he/she has never operated any existing applications. This premise is advantageous in planning usability evaluation as follows.

1. Usage scenarios can be prepared concretely with hearing requirements for the actual users. For "unspecified" users, such preparation is difficult.

Here, a usage scenario means concrete input/output values for achievement. 2. Although a skilled office worker often makes careless mistakes such as incorrect inputs, he/she does not make serious mistakes. Consequently, the evaluation does not need excessive coverage of user operation paths extended over irrelevant use cases.

These premises are important to make the iterative usability evaluation more realistic because the number of combinations of usability features is too numerous to evaluate the usability together with users.

Usability Measurement

Fundamental metrics, which form an essential guideline for improving the operability and user error protection, are defined as follows so that developers who are non-usability-specialists can easily understand effective usability feature employment.

Input time.

Input time is directly related to not only the operability but also the productivity. In our research, input time is measured variously as the time between specific browser events, as explained in Section 3.4. User error. Preventing user errors makes the productivity more reliable. In our research, user errors are defined as follows.

-One is a sequence of user operations that differ from the expected sequence of user operations. The expected sequence means the sequence of user operations that developers, customers or actual users can accept as correct and non-redundant. -The other error is the input of incorrect values. The expected input value is a value that developers, customers or end-users can accept as correct.

3 Proposed Framework

Overview of Proposed Framework

A lot of usability evaluation methods have been proposed [START_REF] Insfran | A Systematic Review of Usability Evaluation in Web Development[END_REF]. Also, methods focusing on metrics which are measured from user operation or access logs have been proposed [START_REF] Atterer | Knowing the user's every move: user activity tracking for website usability evaluation and implicit interaction[END_REF], [START_REF] Nakamichi | Detecting Low Usability Web Pages using Quantitative Data of Users' Behavior[END_REF], [START_REF] Pansanato | An Evaluation with Web Developers of Capturing User Interaction with Rich Internet Applications for Usability Evaluation[END_REF]. As far as we know, there is no method of systematically evaluating the usability feature employment in order to take one step further. Fig. 1 shows the overview of our framework. This framework consists of three phases. The first one is the "preparation" in which several different Web prototypes and scenarios for evaluating the usability are created. The second one is the "observation" in which logs of user operations as browser events are recorded. The last one is the "assessment" in which the logs among different Web prototypes are analyzed and compared. Each of these processes is explained in detail from section 3.2. Our framework provides three tools called Ikazuchi, Akatsuki, and Hibiki respectively, for the process support. The models

Generate Web prototypes

Generate specification code for Akatsuki

The generated Web prototypes with specification code

Create usage scenarios

The usage scenarios Fig. 2. The preparation phase of our framework.

Preparation Phase

Fig. 2 shows the preparation phase of our framework. Developers create Web prototypes and usage scenarios in this phase. Generally, absolute evaluation is difficult for developers who are non-usability-specialists because they may be not able to determine the usability from its evaluation result. Therefore, relative evaluation comparing user operation logs between different Web prototypes is supported in our framework. In the relative evaluation, the developers can easily understand which prototype is better for users. However, the cost for creating several different Web prototypes is not low. To mitigate this problem, our framework applies Ikazuchi [START_REF] Kamimori | Automatic method of generating a Web prototype employing live interactive widget to validate functional usability requirements[END_REF] which is a Web prototype generation tool.

Ikazuchi. Ikazuchi is a tool for generating Web prototypes from a design model of screen transitions. This tool and model have been proposed in previous work [START_REF] Kamimori | Automatic method of generating a Web prototype employing live interactive widget to validate functional usability requirements[END_REF]. A main characteristic of the method of the previous work [START_REF] Kamimori | Automatic method of generating a Web prototype employing live interactive widget to validate functional usability requirements[END_REF] is separation of concerns between the usability features and screen transitions in this model. Then, different Web prototypes can be generated from this model. For example, a Web prototype employing the usability features can be generated by interpreting the whole model as it is. On the other hand, another Web prototype employing no usability features can be generated from the screen transition part without any usability features. Thereby, Web prototypes that are compared in relative evaluation can be obtained at a low creation cost. Ikazuchi tentatively supports four usability features: auto-complete, auto-save, undo, and validator, which can be attached to input items without changing screen's structure. The screen transition model can represent screens, screen components, and the items that are categorized into three types as Input, Output, and Link. Fig. 3

Specification code

{"title": "PaymentSettings", "inputs": {"name": ["input-977674685"], "cardType": ["input-836427078"], "cardNumber": ["input-1322642290"], "expirationYear": ["input-2121199924"], "expirationMonth": ["input-431570856"]}, "links": {"next": ["link-520162288"] } } This specification code can be generated for the generated Web prototypes with the Ikazuchi but not for the product. That is, our framework requires the hard coded values in the specification code so as to conform to the scenarios. Such simplicity is useful for manually inserting the specification code into a Web prototype even if the prototype was created manually. For our framework, the Ikazuchi was extended so as to insert specification code into a generated prototype in order to record user operations corresponding to the model. Specification code can be manually inserted into Web prototype created manually.

Observation Phase

Fig. 4 shows the observation phase of our framework. The precondition of this phase is preparation of both the scenarios and the Web prototypes containing the specification code. That is, developers do not always need the Web prototypes which can be generated with Ikazuchi but which are too simple. The following actions must be conducted by expected users before recording user operations.

-The users have to become skilled in each prototype because the focus is on operability and user error protection and not learnability. By excluding learnability evaluations, it's approximately valid to reuse the prepared scenarios between use of the different prototypes. -The users have to understand and validate the prepared scenarios by using each prepared prototype because it's difficult to imagine that skilled office workers would misunderstand the scenarios even if they often make mistakes.

The validity of normal flow can be ensured at least by the validation. With the above assumption, the users operate Web prototypes in accordance with the scenarios. The Akatsuki tool is utilized to record the user operations.

Akatsuki. Akatsuki consists of a browser extension and a server side program for recording user operations as browser events. The extension inserts a logging script into a rendered Web page, while the server side program receives the user operations from the extension and stores them into a database. The extension is implemented as a Google chrome extension. The server side program and database are implemented with PHP and MySQL respectively. Table 1 shows both the kinds of user operations recorded by Akatsuki and the timing of the recording. Table 2 shows the log contents for each kind of user operation. The page title and input, output, and link items are recorded together with their names represented in the screen transition model so that the developers can review the model on the basis of the analyzed logs. The specification code is used when an HTML tag as an event target is transformed into such names.

Assessment Phase

Fig. 5 shows the assessment phase of our framework. In this phase, the developers relatively evaluate the usability feature employment of the prototypes on the basis of the user operation logs. The raw logs are numerous and difficult to understand. To mitigate this problem, our framework provides the Hibiki tool which analyzes the raw logs and transforms them into useful information.

Hibiki. Hibiki is a server side program in PHP that summarizes the recorded logs into user operation time and input values. The largest unit of the summarized information shows the user operations from the start of the recording to The recorded timestamp, page title, and recording id of a log.

Change of window size

The width and height of a window.

Change of scroll position

The x axis of the horizontal scroll of a page and the y axis of the vertical scroll. Change of mouse position The x and y axis of the cursor in a browser. Operation of mouse buttons The state (press or release) of a button and the button type such as left, right, middle, undefined.

Input of keys

The state (press or release) of an alphabet or number key, the key code, and the state (press) of specific keys such as Shift, Ctrl, Alt.

Start of item input

The name of an input item when the item was focused.

End of item input

The name of an input item and the value of the item when the item was focused.

Screen transition

The name of a link when the link is clicked.

Hibiki Developer

Access to the Hibiki

Analyze the user operation logs Display the results

The analyzed results

Assess the usability by contrasting the results between different prototypes Fig. 5. The assessment phase of our framework.

the end. The information in this unit shows the result when a certain user operated a certain prototype in accordance with a certain scenario. Table 3 shows the summarized information shown by Hibiki. Various differences can be analyzed by collecting this information. For example, differences in the users, in the prototypes, in the scenarios, and in combinations of them can be shown.

Preliminary Evaluation

Overview

This evaluation aims to determine whether the difference in the usability resulting from usability feature employment can be quantitatively recognized from the data shown by Hibiki. A part of a virtual e-commerce application is adopted as an application example because a partial prototype is often used to evaluate specifications in early stages of development. The number of button clicks on a page. One click is countered per release event of the mouse button.

Key input time [millisecond]

Time from a key press to the release on a page. This individual time is measured per release event of the key.

Key type frequency [number of times]

The number of key types on a page. One key type is countered per release event of a key.

Backspace key type frequency

The number of backspace key types on a page. One key type is counted per release event of the key.

Time interval to input next item

Blur time until focusing the next input item. The individual time is measured per focus event of the input item.

Sequence of screen transitions

Sequence of displayed pages in chronological order.

Sequence of input item focuses

Sequence of focused input items in chronological order.

Values of Input item

The last value of an input item in a scenario.

For evaluating the potential effectiveness of the proposed method for observing user operations under conditions assuming actual development is important, weakly restricted prototypes and scenarios which are often create by actual developers are used. In this evaluation, we observed user operations with weakly restricted prototypes because such prototypes are similar to one obtained in an actual development process.

In this evaluation, there were two prototypes, six scenarios, and five users. In this paper, we call the two prototypes A and B. A was automatically generated and B was created manually as shown in Fig. 3. Each prototype represents screen transitions from the CartView screen to the PurchaseComplete screen. This structure simply consists of five screens and transitions between them without any branches. The scale of each of the six scenarios was categorized as large, middle or small resulting in two of each category. Combinations of the prototypes, scenarios, and users were determined so that no bias in learning resulted.

Result

From the evaluation, the total number of the logs obtained was 176,278. Of the 30 combinations that we tried, 26 of them resulted in valid data. Table 4 shows the result of comparing the average input times (avg.) between A and B where the difference between the averages is three or more seconds. ID 1, 2, 3, 4, and 6 shows that the users were able to efficiently operate A than B, in average. All of these items of A employed an auto-complete as a usability feature although these items of B employed no usability features. On the other hand, all items of ID 5, 7, and 8 of B made the user operation more efficient. The items of ID 7 and 8 of B employed a spinner with a default value as "1" although the items of A employed no usability features. Regarding the item of ID 5, both of A and B however employed the same input method without any usability features.

As for user error protection evaluation, we analyzed input mistakes against 222 values expected in the total of all scenarios. A few of the expected values were excluded because some values that were inputted through a date picker written in Javascript were not collected. A total of 906 values were obtained for the 222 expected values. 30 of the actual values were different than the expected ones.

Table 5 shows user errors discovered in the evaluation. Usability features to decrease those errors were not employed in both A and B. The errors such as MI, MC, and a part of O can be automatically corrected employing functions for formatting characters. A part of the errors of MU, O, and T may be avoidable by employing auto-completes because the users inputted the correct value at least once in a scenario although he/she inputted the wrong value in another scenario. Meanwhile, auto-completes were useful to avoid most of these errors but it promoted the error a little. For instance, one of the users inputted the number of a credit card with blind acceptance of the auto-complete even though the completed value was different than the expected value.

Discussion

The effectiveness of usability feature employment was shown quantitatively by utilizing the information analyzed by Hibiki. Hibiki made the analysis of the preliminary evaluation result efficient even though there were numerous logs. However, it seems that the result shown as ID 5 of Table 4 did not depend on the usability features. Consequently, various aspects such as user characteristics and qualitative aspects should be considered for more precise evaluation. Tool support is also needed to make the usability evaluation practical.

In the preliminary evaluation, there were still various non-stable factors such as differences in scenario properties such as the amount of input/output data, rigorous user operation sequences, and exhaustiveness and differences in prototype properties such as layout and input methods. These factors may make the effectiveness of usability feature employment ambiguous. Therefore, a more rigorous evaluation process well supported by proper tools should be considered.

In addition, Ikazuchi can handle a few number of usability features yet. The strategies of attaching usability features, the combinations of usability features and the strategies of comparing the obtained logs should be considered for observing a complex combinations of usability features by improving the capability of Ikazuchi. We plan to extend Ikazuchi to support more existing usability features [START_REF] Folmer | A framework for capturing the relationship between usability and software[END_REF], [START_REF] Juristo | Guidelines for eliciting usability functionalities[END_REF], [START_REF] Roder | Specifying usability features with patterns and templates[END_REF].

Conclusion

A framework for evaluating the operability and user error protection relatively and quantitatively was proposed in this paper. In our framework, Web prototype creation, user operation observation, and usability assessment are supported so as to obtain the prototypes, the user operation logs, and the summarized logs semi-automatically. Our framework strictly controls the evaluation conditions to clarify the effectiveness of usability feature employment. As a result of the preliminary evaluation, this paper quantitatively showed that the usability changed depending on usability feature employment.

As future work, we plan to extend Ikazuchi so as to deal with more usability features and their employment algorithms. We also attempt to extend Hibiki so as to more easily grasp differences between different employment methods by applying artificial intelligent algorithms. In addition, we consider how to obtain the exhaustive scenarios by applying a model-based testing approach. Finally, a large scale and rigorous evaluation applying experimental research approaches is planned to show more reliably the effectiveness of our framework and to evaluate the user error protection from the aspect of user mis-operation sequences.

Acknowledgment

This work was supported by JSPS KAKENHI Grant Number 15K15972.

Fig. 1 .

 1 Fig. 1. The overview of our framework.

Fig. 3 .

 3 Fig. 3. Parts of prototypes to which specification code can be applied.

  (a) shows a part of a Web prototype generated with the Ikazuchi. Fig. 3(b) shows a part of a Web prototype created by hand. Specification Code. The specification code represents correspondence between HTML tag ids and the model. An example of code written in JSON format is shown as follows. The code consists of a page title, input items, and link items.

  Try to operate all combinations of the prototypes and the scenariosStop the recordingEach user starts and stops the recording for each scenario.Each user iterates the recording until all combinations of the prototype and the scenarios are tested.

Fig. 4 .

 4 Fig. 4. The observation phase of our framework.

  Time from the start of user operation recording to the end. The individual time is measured per scenario. Page sojourn time [millisecond] Time between screen transitions. Both the individual and cumulative times are measured per page. Input time [millisecond] Time focusing on any input item on a page. The individual time is measured per page. Mouse input time [millisecond] Time from a button press to the release on a page, except for focus change. The individual time is measured per release event. Click frequency [number of times]

Table 1 .

 1 The kinds of user operations and recording timing by Akatsuki

	User operation	Recording timing
	Change of window size	1) A window.onResize event occurred, or 2) a script
		for the recording was inserted.
	Change of scroll position	1) A window.onScroll event occurred, or 2) the script
		was inserted.
	Change of mouse position 1) A document.onMouseMove event occurred.
	Operation of mouse buttons 1) A document.onMouseDown event occurred, or 2) a
		document.onMouseUp event occurred.
	Input of keys	1) A document.onKeyDown event occurred, or 2) a
		document.onKeyUp event occurred.
	Start of item input	1) A focus event on the item occurred.
	End of item input	1) A blur event on the item occurred.
	Screen transition	1) A click event on a link occurred.

Table 2 .

 2 The user operations and corresponding log contents created by Akatsuki

	User operation	log contents
	Commons

Table 3 .

 3 The kinds of analyzed information by Hibiki

	Information type	Explanation
	Scenario achievement time
	[millisecond]

Table 4 .

 4 The result for operability evaluation

	ID Input item		Avg. of A [sec.] Avg. of B [sec.]
	1 PaymentSettings .name[0]		7.993	13.508
	2 PaymentSettings .cardNumber[0]	8.463	15.442
	3 BillingAddressSettings .billingAddress[0] .ad-	9.051	24.116
	dress[0]
	4 BillingAddressSettings	.billingAddress[0]	10.906	14.551
	.phoneNumber[0]
	5 ShippingAddressSettings	.shippingAd-	26.404	21.995
	dress[0] .address[0]
	6 ShippingAddressSettings	.shippingAd-	7.822	12.533
	dress[0] .assignedItems[0] .name[0]
	7 ShippingAddressSettings	.shippingAd-	5.299	1.774
	dress[0] .assignedItems[0] .quantity[0]
	8 ShippingAddressSettings	.shippingAd-	4.376	0.183
	dress[0] .assignedItems[1] .quantity[0]

Table 5 .

 5 The result for user error protection evaluation

	Kinds of the errors	Freq. Example
	[MI] Mis-input a 1-byte	11
	character instead of a 2-
	byte one
	[MU] Misunderstanding of	11 "Kawakami" as a last name was inputted instead
	the scenarios	of "Kamikawa".
	[O] Omission of a part of a	5 "5300001" as postal code was inputted instead of
	string	"530-0001".
	[T] Typo	2 "Satoru" as a first name was inputted instead of
		"Satoshi". Both of the "ru" and "shi" are one 2-
		byte characters in Japanese.
	[MC] Mis-capitalization	1 "noboru" as the name on a credit card was in-
		putted instead of "NOBORU".