Marek Zachara
email: mzachara@agh.edu.pl

Dariusz Pa Lka
email: dpalka@up.krakow.pl

Detecting Unusual User Behaviour to Identify Hijacked Internet Auctions Accounts

Keywords: internet auctions, identity theft, anomaly detection

For over 15 years auction services have grown rapidly, constituting a major part of e-commerce worldwide. Unfortunately, they also provide opportunities for criminals to distribute illicit goods, launder money or commit other types of fraud. This calls for methods to mitigate this threat. The following paper discusses the methods of identifying the accounts of users participating in internet auctions that have been hijacked (taken over) by malicious individuals and utilised for fraudulent purposes. Two primary methods are described, monitoring users' activities (e.g. the number of auctions created over time) with EWMA and clustering similar auction categories into groups for the purpose of assessing users' sellers profiles and detecting their sudden changes. These methods, utilised together allow for real-time detection of suspicious accounts. The proposed models are validated on real data gathered from an auction web site.

Internet Auctions -Introduction

Since the launch of eBay in 1995, internet auctions have become an important part of the global marketplace. According to the eBay annual report, their income from transactions amounted to 7.7 billion dollars in 2009. Assuming an average fee for a transaction to be below 10%, the total sales through eBay would amount to around 100 billion dollars, compared to 135 billion dollars of total e-commerce retail sales in the US [19] during the same year. There are certainly other auction services beside eBay, but even considering only the numbers related to eBay (which is certainly the largest one), the importance of this transaction medium is obvious.

One of the primary reasons for the success of auction services is the low cost of entry. A person does not need any specific tools nor formalities to start selling their products (or information services). This results in a large number of both sellers and buyers registered with auction sites. A large user-base of the sellers means statistically high chances of users with weak passwords or otherwise vulnerable to hacking methods. A huge amount of buyers, on the other hand, provide an excellent opportunity to find those interested in illicit goods or susceptible to various scam methods. As a result, auction systems are an important medium for criminals, granting them means of expanding their illegal activities, including fraud and/or the provision of prohibited goods. Left unmitigated, this would constitute a serious threat to public security.

Although most readers are probably familiar with how internet auctions work, a brief explanation will be provided here fore reference purposes. A person willing to sell an item, posts its description (often with photos) and an initial asking price at an auction site. Other users can view the offer, may ask additional questions and may also bid a certain sum for the item. Auctions usually end after a specific time (e.g. 14 days), with the item sold to the highest bidder. There might be other types of offers (e.g. a fixed price, multiple items, etc.), but in all cases the transaction is concluded between two registered users of the auction service.

After each transaction the parties have a chance to evaluate it by posting their comments and ratings of the other party. Such ratings for each user are usually aggregated into an overall reputation rating (e.g. a person with 96 positive and 3 negative 'comments' would have a rating of 93).

The reputation system i.e. the method of calculating the reputation rating and the actual numbers are vital to an auctions system. Contrary to traditional sales scenario, where both parties meet in person and the goods are exchanged for money at the same time, purchases made over the internet usually take much longer, with money often being paid up-front and the goods delivered after a few days. Buyers are therefore likely to make the buying decision based on their trust that sellers will keep their part of the bargain. This trust is likely to be higher if a lot of other users have already concluded transactions with this particular seller, and were satisfied with them, which would be reflected in the sellers reputation rating. Similarly, the seller is more likely to offer e.g. a CoD option to a buyer with a good reputation standing. Although the reputation rating is valuable to every user, it is vital to sellers, as it will directly affect their business and profit.

The reputation system and the 'snowball effect' of an increasing number of buyers and sellers using the auction systems for their needs have motivated many merchants who were selling their products via their own web service to integrate with an auction system and use it as their primary sales channel, resulting in such a large volume of trade as mentioned at the beginning of the article.

Auction-Related Fraud

The volume of transactions made via internet auctions make it a valuable target for criminals and abusers. According to [START_REF] Dong | Combating Online in-Auction Fraud: Clues, Techniques and Challenges[END_REF], auction frauds can be split into three major categories:

-Pre-auction fraud, which includes misrepresentation, the sale of illegal goods or triangulation. The former two are not specific to auctions or e-commerce in general, while the later (triangulation) is the sale of goods purchased with stolen credit card for cash -leaving the fraudster with cash and transferring the risk of seizure to the recipient [START_REF] Dong | Combating Online in-Auction Fraud: Clues, Techniques and Challenges[END_REF]. -In-auction fraud, which is used to disrupt competitors' sales (e.g. by placing a high bid via a fraudulent account with no intention of buying the item, or by inflating the price by bidding on one's own items. -Post-auction fraud, consisting mainly of non-delivery of the purchased item, the delivery of a broken or inferior item or stacking the buyer with additional fees.

More details about auction fraud can be found in [START_REF] Gavish | Reducing Internet Auction Fraud[END_REF] and [START_REF] Dong | Combating Online in-Auction Fraud: Clues, Techniques and Challenges[END_REF]. However, of all the possible options, the most profitable to a fraudster are the ones which include up-front payment and non-delivery of the item, or the delivery of an item inferior to the offered one. Unfortunately for a fraudster, the reputation system does not allow this scenario to be exploited for long, as negative feedback from the buyers will soon warn other users and effectively prevent the fraudster from using his/her account with the auction system for this purpose. On the other hand, having access to an account with a high reputation allows for a larger numbers of buyers to be attracted to the fraudster's offer, allowing him/her to gather more money before negative feedback starts pouring in. Developing the means to abuse or circumvent the reputation system is therefore vital to a fraudster. It is a broad subject discussed e.g. in [START_REF] Reichling | Effects of Reputation Mechanisms on Fraud Prevention in eBay Auctions[END_REF], but can be narrowed down to two most often used methods:

-Building up a fraudulent reputation, often utilizing a 'Sybil Attack' [START_REF] Beranek | Auditing Electronic Auctions Systems[END_REF] where positive feedback for a specific account is generated via dummy accounts controlled by the fraudster -Gaining access to a legitimate account, and exploiting it for own purposes (e.g. fraudulent offers/sales), leaving the original account owner with unhappy customers and, potentially, a legal struggle.

Of these two methods, the first one is more deterministic, although it requires a certain amount of effort and time to reach the stage when the fraudster can execute his/her schema, after which the account is basically unusable and a new one needs to be prepared. The second method is less reliable, as it depends on certain circumstances, often outside the fraudster's control (e.g. carelessness of a certain user or the auction system operator), but provides the fraudster with an account that can be utilized on the spot and with possible less risk as the original user will be the primary target of the claims.

Existing Fraud Prevention and Detection Techniques

It was not long after eBay launched that fraudsters noticed the new options it provided. An initial analysis of auction fraud and its prevention appeared as early as 2000 [START_REF] Boyd | Security Issues for Electronic Auctions[END_REF]. By 2006, online auction fraud was the most offen reported offence in Australia, according to a government report [START_REF]The risk of criminal exploitation of online auctions[END_REF]. So far, most of the research focus has been applied to identifying the fraudulent accounts that were used to build up a reputation score based on the distribution of accumulated feedback in time [START_REF] Chang | An Early Fraud Detection Mechanism for Online Auctions Based on Phased Modeling[END_REF], decision trees [START_REF] Chau | Fraud Detection in Electronic Auction[END_REF] or belief propagation and Markov random fields [START_REF] Zhang | Toward a Comprehensive Model in Internet Auction Fraud Detection[END_REF]. Also, there are proposals to utilize non-technical methods (i.e. social groups and their collective expertise) to combat some specific forms of auction fraud [START_REF] Chua | Fighting Internet Auction Fraud: An assessment and proposal[END_REF]. There is, however, substantially less interest in identifying hacked or stolen auction accounts. Although the issue (also named an 'identity theft') is very important to financial industry, as outlined in [START_REF]Putting an End to Account-Hijacking Identity Theft[END_REF], [START_REF] Wheeler | Multiple algorithms for fraud detection[END_REF], there is little specific research related to auction accounts, even though, as will be demonstrated in this article, this specific environment provides opportunities to utilize various techniques based on specifically available data.

An Overview of the Proposed Method

In this paper we propose a multi-model approach to detecting anomalies in the behaviour of sellers participating in the internet auctions. For each seller a different behaviour model is created, which is next constantly matched against the current profile (offers and transactions performed). The model consists of a number of features and procedures which are used to evaluate the users' behaviour.

The primary task of the model is to assign a probability value to the current behaviour of the seller. This probability value reflects the probability of the occurrence of the given feature value with regards to an established seller profile.

The assumption is that feature values with a sufficiently low probability indicate potentially abnormal behaviour, which in turn my be the result of an account hijacking by a malicious individual. Based on the model outputs, the user's behaviour may be reported as abnormal. This decision is reached by calculating a number of anomaly scores. The current user's behaviour is reported as anomalous if at least one of these anomaly scores is above the corresponding detection threshold. This approach shares some concepts with intrusion detection systems (IDS) [START_REF]Intrusion Detection Systems[END_REF], however, it operates on different types of data and behaviour models, as IDS operates on the network traffic level -detecting anomalies in network packets.

Similar multi-model approaches were successfully used for detecting potential attacks on web applications [START_REF] Zachara | Learning Web Application Firewall benefits and caveats[END_REF], [START_REF] Kruegel | A multi-model approach to the detection of web-based attacks[END_REF]. Sample models of the seller's behaviour are described in the following section.

The real data about users' activities presented in this article have been gathered by the authors by monitoring Polish largest auction service (allegro.pl). This service consistently hosts over 1 million active auctions at any given time, and has an important advantage over eBay from the research point of view, as it allows for the retrieval of users' history (past auctions).

EWMA of the User's Activity

The proposed model is based on measuring the total number of items offered for auction in all categories on any given day. To restrict the model sensitivity to temporary fluctuations in the number of items offered daily, the model utilizes an exponentially weighted moving average. This average (S(t)) is calculated according to a recursive formula:

S(t) = { α • y(t -1) + (1 -α) • S(t -1) if t > 2 y(1) if t = 2 (1)
Where:

t is discrete time (the number of the day), in which we calculate the average number of auctions; the mean is calculated from the initial time t = 2 y(t) is users' activity (e.g. the number of items offered by a seller) on the day t α is the smoothing constant (filter factor) Additionally, the variance is calculated recursively:

V (t) = α • (y(t) -S(t -1)) 2 + (1 -α) • V (t -1) (2)
Where:

-V (t) is the variance at the moment t Applying Chebyshev's inequality

P (|x -E(x)| > ε) < V (x) ε 2 (3)
and substituting E(x) = S and ε = |y(t) -S|, we obtain:

P (|y -S| > |y(t) -S|) < V (t) |y(t) -S| 2 ≡ P (y(t)) (4)
The Chebyshev's inequality imposes an upper bound on the probability, i.e. that the difference between the value of a random variable x and E(x) exceeds a certain threshold ε, for an arbitrary distribution with variance V (x) and mean E(x). The inequality is very useful because it can be applied to various arbitrary distributions with finite variance.

The formula (4) calculates the probability value P (y(t)) if the amount of user's activity (e.g. the number of items put up for auctions) at any given time y(t) exceeds the current value of S(t). If the number of items is smaller then or equal to S(t), it is assumed that P (y(t)) = 1. The value of P (y(t)) is the value returned by this model.

Figure 1 illustrates a typical scenario, with varying but consistent user's activity over time. Although the activity is changing substantially, the value of the dV (t)/dt function does not reach significant levels.

In another scenario, illustrated in Fig. 2 the user's activity includes a significant peak at a certain time (around 40th day). This is promptly signalled as a suspicious activity by the change in variation exceeding the value of 10. The proposed model proves also its usefulness in Fig. 3, when an activity of a specific user is illustrated. This user apparently puts up items for sale in weekly 'batches'. As can be seen in this figure, the model does not alert of a suspicious activity in this case, which is a desired outcome, as such behaviour is consistent and unsurprising.

'Thematic' Category Clusters

Although the proposed model of user's activity performs up to the expectations, it is usually better to have multiple detection systems (at least two) for the confirmation of a suspicious case. Another criterion of the suspicious seller's behaviour (which might indicate a takeover of an account) is a sudden change of the types of items provided by the seller. Since all auction services allow the sellers to assign the offered item with a category (from a provided list), a sudden change in the number of items offered (or transactions) per categories is a possible warning sign. For example, a user who so far has sold items mostly in the categories for children → toys and books → comics suddenly starts to sell in the category jewellery for men and jewellery for women.

In order to detect such changes in the profile of categories for a given seller, it is necessary to cluster all categories of an auction service into thematic groups. By 'thematic' we mean groups that are likely to share similar items across several categories. Such clusters are likely to group together the already mentioned jewellery for men and jewellery for women as well as e.g. books → guidebooks and car → manuals.

This clusterization allows to build and observe sellers' activity profiles within given thematic categories. Unfortunately, the hierarchy of categories offered by auction services often does not suit this purpose, as similar items can be offered in distant categories (according to the hierarchy tree).

In order to create useful clusters of categories, they were grouped on the basis of similarity of the names of items present. This is done as follows:

In given time intervals (one month in the existing implementation), the names of all objects offered in all categories are acquired. For each category pair the probability is calculated using the formula:

s(c a , c b ) = n ∑ i=1 max 1⩽j⩽m f (p ca (i), p cb (j)) n ( 5
)
where n the number of auctions in the category c a m the number of auctions in the category c b p ca (i) -the name of the object with the number and in the category c a p cb (j) -the name of the object with the number and in the category c b next, the similarity factor is calculated:

f (p ca (i), p cb (j)) = { 0 if f (p ca (i), p cb (j)) < 0.5 f (p ca (i), p cb (j)) if f (p ca (i), p cb (j)) ≥ 0.5 (6) f (p ca (i), p cb (j)) = 1 -L dist (p ca (i), p cb (j)) max(|p ca (i)|, |p cb (j)|) (7)
where

-L dist (p ca (i), p cb (j)) -the Levenshtein distance betwen name p ca (i) and p cb (j) -|p ca (i)| -size (number of characters) of name p ca (i) -|p cb (j)| -size (number of characters) of name p cb (j)
The similarity f shown in equation ( 6), represents the percentage distance between names (i.e. the minimum number of edits needed to transform one name into another divided by the length of the longest name multiplied by 100%). If it exceeds 50%, the value of similarity f is assigned the value of 0 to limit the influence on the similarity of the category s(c a , c b ) of the objects significantly differing in names (the suggested cut off threshold at 50% is arbitrary, but has proven to be a reasonable value).

Before calculating the Levenshtein distance [START_REF] Levenshtein | Binary codes capable of correcting deletions, insertions and reversals[END_REF] L dist between the names of the items, p ca and p cb are normalized: all 'marketing' marks used by sellers in order to attract buyers such as: '#', ' !', '*' are removed white spaces and the following signs ",;. -" are concatenated to a single space all letters are transformed to lower case. Such normalization of names is necessary to achieve a meaningful distance between the names, as sellers tend to utilize numerous ways of modifying the names in order to stand out with their offers. As can be observed, due to the way of defining the similarity S between categories, 0 ≤ s(c a , c b ) ≤ 1 as well as self-similarity of categories s(c a , c a ) = 1

On the basis of the similarity s between categories the symmetrical similarity measure is defined as:

s sym (c a , c b ) = s(c a , c b ) + s(c b , c a ) 2 (8)
On the basis of the symmetrical similarity measure s sym , an undirected graph is built which represents the similarity between categories. In this graph the vertices represent given edges, and edges represent the similarity between given categories. The weight of the edges connecting vertices c a and c b equals s sym (c a , c b ).

If s sym (c a , c b ) = 0, the edge is discarded.

During the next step, the graph constructed undergoes a clusterization in order to group thematically similar categories together. The clusterization algorithm used is a recursive spectral algorithm described in [START_REF] Kannan | On clusterings: good, bad and spectral[END_REF]. This algorithm was chosen because of its many advantages, including its speed and the fact that it can be successfully applied in a variety of contexts [START_REF] Alpert | Spectral partitioning: the more eigenvectors the better[END_REF], [START_REF] Dhillon | Co-clustering documents and words using bipartite spectral graph partitioning[END_REF], [START_REF] Shi | Normalized cuts and image segmentation[END_REF], [START_REF] Weiss | Segmentation using eigenvectors: a unifying view[END_REF], [START_REF] Fowlkes | Spectral Grouping Using the Nystrm Method[END_REF], [START_REF] Xiang | Spectral clustering with eigenvector selection[END_REF].

The specific algorithm used in the reference implementation was based on [START_REF] Cheng | On a recursive spectral algorithm for clusterin from pairwise similarities[END_REF] and is described in (Algorithm 1).

Algorithm 1 Clustering of the categories

Input: Matrix n x n containing weights of undirected weighted graph representing categories similarity Output: A tree whose leaves are the row indexes of A representing clusters

Initialize

• Let R 2 ∈ ℜ n×n be a diagonal matrix whose diagonal entries are the row sums of AA T 2. Compute Singular Vector

• Compute the second largest right singular vector v ′ of the matrix

A T R -1 • Let v = R -1 v ′ 3. Cut
• Sort v coordinates so that vi <= vi+1 • Find the value t that minimizes the conductance of the cut: (S, T ) = ({v1, ..., vt}, {vt+1, ..., vn}) • Let AS, AT be the submatrices of A whose rows are those in S, T 4. Normalize

• Adjust the selfsimilarities

A 2 ii := A 2 ii +      ∑ j∈T A (i) • A (j) if i ∈ S ∑ j∈S A (i) • A (j) if i ∈ T

Recurse

• Recurse steps 2-4 on the submatrices AS and AT

The conductance of a cut (S, V \ S) is calculated as follows:

cond(S, V \ S) = d(S, V \ S) min(d(S), d(V \ S)) (9)
where

-d(A, B) = ∑ i∈A,j∈B A (i) • A (j) -d(A) = d(A, V ) -A (i) is i-th row vector in matrix A
The results of the clusterization can be seen in Fig. 4, which illustrates how all activities of two users really belong to one primary specific cluster of categories, with some marginal activity in other category clusters.

Detecting Unusual Activities

After the clusterization into thematic category groups, the probability of a certain number of offers appearing in a given group on a given day is calculated. The probability is calculated in the same way as the EWMA model described above. The probability of correct (non anomalous) behaviour yielded by this model P (y(t)) is described as the minimum of probabilities in particular clusters: P (y(t)) = min(P c (y(t))) [START_REF] Fowlkes | Spectral Grouping Using the Nystrm Method[END_REF] where

-c ∈ C (set of all clusters)
After calculating the probability of non anomalous behaviour at a given time t using particular models expressed as P m (t), it is possible to calculate the following parameters:

anomaly score w = ∑ m∈M w m • (1 -P m ) anomaly score max = max(1 -P m ) (11)
The first one represents a weighted sum of anomalous behaviour calculated by each model, while (1 -P m) denotes the probability of anomalous behaviour according to the model m, and w m represents the weights associated with this model. The second parameter specifies a maximum probability of anomalous behaviour yielded by all models.

Finally, it is possible to select thresholds k w and k max respectively for calculated anomaly scores in such a way that after exceeding them, the system will report a possibility of unauthorized usage of the suspicious account. The thresholds needs to be be adjusted manually in order to minimize the number of false positive alerts while preserving the sensitivity of the system to anomalous behaviour.

Conclusion

The models proposed in this paper for the assessment of the user's activity behaviour have proven very effective against the provided set of data. The data used for validating the models were gathered by daily retrieval of all the auctions from their web site for a period of one month. There were several millions of auctions retrieved during that time. Unfortunately, due to legal and privacy concerns, we were not able to receive data on real accounts taken over by criminals, so the model was validated with the data manually reviewed which deemed to be suspicious (e.g. Fig. 2). The clusterization of the categories has also proved to yield extraordinary results, with significant portion of users having most of their transactions in just a few (or even one) primary category groups. Interestingly, with the total number of groups equal to approximately a quarter of all categories, some groups consisted of over 200 categories, while the others were single-membered.

The most computationally expensive part of the proposed process is the grouping of categories, which can fortunately be done quite rarely (e.g. once a month) and off-line. Other algorithms are lightweight and can easily be utilized for a real-time monitoring on any scale of users. Implementing such solutions will not eliminate the possibility of fraudulent use of a hijacked account, but will at least greatly limit the benefits, as an alert can be risen very quickly and the suspicious account suspended for evaluation. As has been mentioned before, auction fraud is a considerable aspect of public security, therefore, its mitigation is of interest to both auction service providers and security forces (e.g. police).

Although the proposed model proves to be effective, it can be further enhanced with other detection factors (e.g. the assessment of the value of items offered instead of their number). This may further improve its ability to distinguish anomalies in users' behaviour.

Fig. 1 .Fig. 2 .Fig. 3 .

 123 Fig. 1. Non suspicious activity of a selected user. The values of moving average, variance and variance's derivative are presented. The values calculated for (α = 0.02)

Fig. 4 .

 4 Fig. 4. Illustration of User's activity (the quantity of daily transactions) for two different accounts. The graphs on the right illustrate activity aggregated into 'thematic' clusters

This work is partially supported by NCBiR grant 0021/R/ID2


Andreas Holzinger
email: a.holzinger@hci4all.at

Peter Treitler
email: p.treitler@hci4all.at

Wolfgang Slany
email: wolfgang.slany@tugraz.at

Making Apps useable on multiple different mobile platforms: On interoperability for business application development on smartphones

Keywords: Mobile computing, user interfaces, smartphones, mobile platforms, app development, usability engineering, multi-platform, cross-platform

The relevance of enabling mobile access to business enterprise information systems for experts working in the field has grown significantly in the last years due to the increasing availability of smartphones; the shipment of smartphones exceeded that of personal computers in 2011. However, the screen sizes and display resolutions of different devices vary to a large degree, along with different aspect ratios and the complexity of mobile tasks. These obstacles are a major challenge for software developers, especially when they try to reach the largest possible audience and develop for multiple mobile platforms or device types. On the other side, the end users' expectations regarding the usability of the applications are increasing. Consequently, for a successful mobile application the user interface needs to be well-designed, thus justifying research to overcome these obstacles. In this paper, we report on experiences during an industrial project on building user interfaces for database access to a business enterprise information system for professionals in the field. We discuss our systematic analysis of standards and conventions for design of user interfaces for various mobile platforms, as well as scaling methods operational on different physical screen sizes. The interoperability of different systems, including HTML5, Java and .NET is also within the focus of this work.

Introduction and Motivation for Research

Mobile devices are gaining more and more importance and smartphones are nowadays a common sight in industrial countries. What started originally as a concept product by IBM in 1992, was a niche product for a long time. This changed rapidly with the release of the Apple iPhone in 2007, bringing smartphones to the mainstream. One year later, Google and the Open Handset Alliance released their Android platform, which gained a lot of popularity in the following years.

As of June 2012, there were a total of more than 300,000,000 Android devices shipped worldwide, with more than 900,000 new ones being activated every day. Similarly, the iPhone is very popular with more than 180,000,000 devices shipped in total. The iPad, released in 2010, has been sold more than 55,000,000 times.

Along with this new and big market, new challenges for software developers emerge. Different programming languages, IDEs and platform standards need to be learned rapidly in order to develop native apps for multiple platforms.

HTML5 promises easy multi-platform development, with browsers on most current mobile devices being able to render HTML5 content. Therefore, ideally only a single app would need to be created which then could be executed on multiple target platforms.

However, there are also some disadvantages of HTML5, when compared to native apps, such as limited access to the device hardware or to platform features, look and feel that users are not used to from other apps of the platform, as well as missing market presence. In this paper we try to pinpoint the advantages and disadvantages of HTML5 apps and native apps and try to offer some guidelines as to which to choose for app development.

Besides the number of different platforms, mobile devices come with screens in different sizes, resolutions, and aspect ratios. Additionally, tablets are typically used in landscape mode, whereas smartphones are used in portrait mode, though both can also be used in the other way. This proliferation of interface properties holds especially true for Android, which supports devices with a display diagonal reaching from 2 inches over tablets which typically measure 10 inches up to TV screens with a display diagonal greater than 40 inches.

Many problems arise during the development of mobile applications -especially in industrial, professional and safety-critical environments [START_REF] Holzinger | Typical Problems with developing mobile applications for health care: Some lessons learned from developing user-centered mobile applications in a hospital environment[END_REF], reaching from security aspects [START_REF] Weippl | Security aspects of ubiquitous computing in health care[END_REF] to issues of the user interface [START_REF] Alagoez | From cloud computing to mobile Internet, from user focus to culture and hedonism: The crucible of mobile health care and Wellness applications[END_REF]. In this paper we concentrate in on the latter and deal with questions including: Are different UI layouts required for different screen sizes? If so, where should designers draw the line between small and large devices? Are there tools which support designers in creating UIs for multiple screen sizes?

2 Background and Related Work

Business Case: Mobile Access to a business information system

During the research for this paper a project was carried out in cooperation with the Austrian business software development company Boom Software AG. The project was concerned with usability evaluation and consulting for the development of a mobile application. We will not discuss the details of the project here, but will illustrate some of the problems and challenges encountered in order to underline the relevance of mobile devices for business applications and the importance of usability of mobile apps. The information on the company and its technologies presented here is based on their marketing documents (January 2012) and personal communication:

Boom Software AG was founded in 1995 and has 50 employees (March 2012). The company primarily develops industrial software for maintenance, management and production control. Boom Software advertises total customization [START_REF] Schnedlitz | Total Customizing -Vom Überleben durch Anpassung: The Eagleheaded Chicken Project[END_REF] of its software in order to meet the specific needs and requirements of individual customers.

The underlying technology which enables the customization of their software is the Business Oriented Rapid Adaption (BORA) Framework. The BORA Framework was created to provide a unified design framework for the developers. According to company representatives, prior to the framework's introduction, their developers spent roughly 80% of their efforts on solving technical issues, whilst only 20% were used to customize the software to optimally meet the end users' needs. The framework provides the base technology for all software products and includes a number of tried and tested user interface elements and concepts, therefore drastically reducing the workload on technical tasks and allowing greater focus on customization. Boom Software's products manage large amounts of enterprise data. The users, however, are not interested in just having access to the data; they need effective ways to efficiently gain knowledge out of this data [START_REF] Holzinger | On Knowledge Discovery and interactive intelligent visualization of biomedical data: Challenges in Human-Computer Interaction[END_REF]. A well-designed, usable interface may help to achieve that goal.

While the main focus of Boom Software's products has historically been on desktop software for Microsoft Windows systems, a platform-independent HTMLbased UI layer for BORA applications has also been developed over the last few years. Recently, development on the first mobile app has started. Platforms targeted are Android and Windows 8 (for tablet PCs). Boom Software's goal is to make specific parts of software systems run on smartphones and tablets in order to increase the productivity of outdoor staff like maintenance workers.

Mobile work

Many companies today rely heavily on their software systems in their everyday work. At the same time, many jobs require employees to be mobile rather than working in their office. Maintenance workers, for instance, need to be on-site to perform maintenance while they may also need to be able to access information in the company's databases. This mobile work [START_REF] York | Human-computer interaction issues for mobile computing in a variable work context[END_REF] has often been done on laptop computers where appropriate display resolution supported the necessary visual performance [START_REF] Ziefle | Effects of display resolution on visual performance[END_REF]. In the last years, many of these laptop computers were replaced by tablet computers [START_REF] Holzinger | Design and Development of a Mobile Computer Application to Reengineer Workflows in the Hospital and the Methodology to evaluate its Effectiveness[END_REF]. Mobile work usually includes three dimensions: mobility, location (in-)dependency, and time criticality; and context-related mobile work support functions are: location tracking, navigation, notification, and online job dispatching. According to the task-technology fit (TTF) theory [START_REF] Zigurs | A theory of task/technology fit and group support systems effectiveness[END_REF], [START_REF] Gebauer | Applying the theory of task-technology fit to mobile technology: the role of user mobility[END_REF] and attitude/behavioral theory [START_REF] Kraft | Perceived difficulty in the theory of planned behaviour: Perceived behavioural control or affective attitude?[END_REF], it is crucial to find a fit between task characteristics and mobile work support functions; guidelines for development and use of mobile work support systems can be found in [START_REF] Yuan | Identifying the ideal fit between mobile work and mobile work support[END_REF].

Variety of mobile devices

One major challenge when developing mobile apps (for smartphones, tablets or both) is the wide range of different platforms and device types available.

As detailed in Table 1, there are currently six different mobile platforms, which had a significant market share in 2011: Android, iOS, Symbian, BlackBerry, Bada and Windows Phone.

Multi-platform development

Developing applications that can be used on all these platforms is often extremely difficult. All platforms have different Software Development Kits (SDKs) along with different libraries and different ways to design user interfaces. The programming languages of these platforms differ as well (see Table 2). Knowledge of the programming languages required for app development is, however, only a small part of the expertise needed. The SDKs, platform standards and best practices should be known to developers as well. On the legal side, the terms of use of the different markets can also vary to a large degree, e.g. both Apple and Microsoft ban software that contains parts licensed under any GNU license. Gaining all this knowledge for a large number of platforms is a very time-consuming task.

In addition to the platforms themselves, developers need to consider the devices available for these platforms. Android, for instance, has many different devices available, including small smartphones and large smartphones and tablets. IOS, likewise, runs on the iPhone and the iPad.

These devices have different screen sizes and sometimes different aspect ratios as well, which requires effort to make user interfaces well scalable -or sometimes the design of different user interfaces for different screen sizes altogether.

Chae and Kim (2004) [START_REF] Chae | Do size and structure matter to mobile users? An empirical study of the effects of screen size, information structure, and task complexity on user activities with standard web phones[END_REF] have found that the screen size of a device significantly impacts users' behaviors. They have also found different levels of breadth and depth of information structures to be more appealing to users for different screen sizes.

Web technologies, such as HTML5, CSS3 and JavaScript promise an easy solution to the platform segmentation on the mobile market today: Every platform includes a browser which can display web sites and web apps.

The HTML5 standard is still under development. This implies that the browsers used must be up-to-date in order to support all of the most recent features of HTML5.

Web apps have a number of advantages and disadvantages when compared to native apps. These will be addressed in the upcoming sections.

A third approach is the development of so-called hybrid apps. These are native apps which display a web user interface, which can thus be the same across platforms. The platform SDKs offer UI elements which can be used for this purpose.

Related Work

Work on solving the problem of rendering on multiple user interfaces began a while ago, however, to date very few work is available for mobile devices explicitly. Most of the work was created before the mobile platforms discussed became available and therefore don't consider these platforms and their capabilities specifically. In the following we determine general work versus explicit work on mobile user interfaces:

Farooq Ali et al (2001) [START_REF] Ali | Building Multi-Platform User Interfaces with UIML[END_REF] discuss the need for a unified language for describing user interfaces in order to facilitate multi-platform UIs. Their approach uses the User Interface Markup Language (UIML) to create a high-level logical model of the UI and then derive models for families of devices from it in a developer-guided process.

Stocq & Vanderdonckt (2004) [START_REF] Stocq | A domain model-driven approach for producing user interfaces to multi-platform information systems Advanced Visual Interfaces AVI[END_REF] describe a wizard tool which is able to create UIs for simple and complex tasks based on the domain model of the information system. Their approach also requires input and choices made by the developers. The wizard can create UIs for the Microsoft Windows and PocketPC platforms. The mobile UI needs to be built separately, but some of the information from the creation of the desktop UI can be reused to reduce the workload for the developer.

The work by [START_REF] Mori | Design and development of multidevice user interfaces through multiple logical descriptions[END_REF] [START_REF] Mori | Design and development of multidevice user interfaces through multiple logical descriptions[END_REF] focuses on nomadic applications which can be accessed by the user on a variety of different devices and platforms as well as the different contexts of use of the applications on these platforms. Their One Model, Many Interfaces approach attempts to avoid low-level details by the use of meaningful abstractions. One central task model is created for the nomadic application. System task models, abstract and concrete UIs are then derived incrementally. They also stress that developers need to be aware of the potential target platforms early in the design process in order to create suitable tasks for each one. [START_REF] Choi | Application framework for multi platform mobile application software development 11th International Conference on Advanced Communication Technology[END_REF] [START_REF] Choi | Application framework for multi platform mobile application software development 11th International Conference on Advanced Communication Technology[END_REF] describe an application framework based on the Model-View-Controller pattern to assist the agile development of multi-platform mobile applications. Their approach uses a set of rules for each target platform in order to transform the UI.

Methods and Materials

In our research we have closely examined the Android and iOS platforms, along with the tools they offer to design and scale user interfaces and the guidelines they offer on UI design. The issue of web apps versus native apps was also thoroughly surveyed.

Android

Android is currently available on a wide range of devices. Device manufactures must adhere to Google's Compatibility Definition Document (CDD). According to the current version of the CDD [19], the physical display diagonal of devices must be at least 2.5 inches. The minimum display resolution must be 320 x 240 pixels (QVGA). The aspect ratio must be between 4:3 and 16:9.

The Android framework defines four different classes of screen sizes. These are small, normal, large and extra-large. In addition, there are four density classes: Ldpi (120 dpi), mdpi (160 dpi), hdpi (240 dpi) and xhdpi (320 dpi). Devices should report the next lowest size and density standard, meaning sizes and densities can be anything between and above the standard values.

A detailed breakdown of device shares per size and density can be found in Table 3. This data shows that more than 80% of all Android devices fall into the normal size category.

iOS

Unlike Android, iOS only runs on a few devices manufactured by Apple. These include the iPhone, the iPod Touch and the iPad (all in different versions). Furthermore, iOS is the operating system for Apple TV, but this is outside the focus of this paper and will not be discussed in detail.

With regard to screen sizes, this means that developers must support two different sizes, as the iPhone and iPod Touch screens are identical in size. Figure 2 shows the size difference of the devices while Table 4 gives a detailed overview of the screen specifications of mobile iOS devices. As can be seen in Table 4, all iOS devices had their resolution doubled in a newer generation at some point. In order to make it easy to deal with these differences, Apple has introduced a measurement unit called points. Points, much like Android's density-independent pixels, server to define layouts and measurements independently from display density. One point, for instance, equals one physical pixel on the first iPhone generation while it equals two physical pixels on the iPhone 4S.

Image resources can (and should) also be provided in two different resolutions. The proper image will then be selected and displayed on the device the app is used on.

Beside these simple tools, iOS developers can be sure that the device market will remain manageable in the future with Apple being the only device manufacturer.

Multi-platform development

The question whether to develop a native app or a web-based HTML5 app is one which every app developer will inevitably ask herself or himself. The different platforms and environments of mobile devices (see Table 2) make porting an app from one platform to another one a difficult task.

HTML5 is a promising alternative -every one of these platforms has a browser and the capability to run web apps. While HTML5 apps can run on any mobile platform with little to no extra effort, native apps also have advantages (see Table 5). Access to the system's hardware or some hardware-related features such as the camera is often only possible in native apps. Native apps can also integrate themselves seamlessly into the system: They use the native look-and-feel, can offer widgets to be displayed on the home screen, interaction with other apps, running as services in the background, and the use of system notifications. Native apps also tend to have better performance than web apps, though current browsers are getting more and more performance optimizations while at the same time newer devices offer more computational power, making the difference diminish. It is also possible to develop hybrid applications. These are native applications which use views to display HTML5 content, which can be the same across all platforms.

Multi-platform frameworks

Since the development of apps for mobile platforms is getting more important with numerous platforms being available on the market, platforms have been developed which should facilitate easy app development on multiple platforms. These multiplatform frameworks come in many variations. Some of them only change the visual appearance of web apps while others offer whole software development kits on their own, which can build the developed apps to multiple target platforms as native apps.

For this paper, we have briefly examined three frameworks: JQuery Mobile, PhoneGap and Titanium Mobile. There are, of course, many more frameworks available. Criteria for the selection of the frameworks were that these were, at the time, some of the most feature-rich and most popular. The aim was also to have frameworks with different key features in order to be able to compare them. Furthermore, the frameworks are also available for free. There are several proprietary frameworks but they could not be tried out thoroughly and were therefore excluded from the selection.

JQuery Mobile

JQuery Mobile [START_REF] Jquerymobile | [END_REF] is a web app framework which was developed by the developers of the popular JavaScript library jQuery. The main focus of jQuery Mobile lies on the design and presentation of mobile apps.

The technologies used by jQuery mobile are HTML5, CSS3 and JavaScript, which enables it to run on most current mobile devices. JQuery Mobile can be used to both make web apps feel more like native apps and to apply a brand layout to them, giving them a more polished look than a default web app. The layout is scaled to the target device. Small adaptations can be made automatically. For instance, labels can be placed beside input fields on larger devices while being placed above them on smaller devices.

The jQuery mobile website offers a drag-and-drop tool for building simple UI layouts called Codiqa. Components such as buttons, text, images and lists can be dragged into the UI, allowing for rapid prototyping. The resulting source code can then be downloaded and further modified. This makes it much easier for new or inexperienced developers to get started, as the other platforms such as Android have a much steeper learning curve.

The jQuery Mobile framework is free and open source. It can be used under the terms of either the MIT License or the GNU General Public License. The basic version of the Codiqa, which allows the download of the source code created, is free. Advanced versions which offer additional features cost 10$ per month for single users and 30$ per month for teams.

JQuery Mobile offers some more features which are not strictly related to design, most notably the handling of events such as various forms of touch input (e.g., tap, swipe) and orientation change (i.e., the user turning the device from portrait to landscape mode or vice versa).

PhoneGap

PhoneGap [START_REF]Phonegap[END_REF] is an app platform which can build apps from a single code base for multiple target platforms as native apps. It is based on HTML5, CSS3 and JavaScript and abstracts the hardware of mobile platforms into a JavaScript API. The library provides interfaces for hardware access and certain native features. Hardware access includes the device's accelerometer, the camera and the compass. Some of the platform features are access to the contact list or to the file system, notifications and geolocation. All of these features are available for Android, iPhone (3GS and above) and Windows Phone 7. Other platforms such as Blackberry or Symbian have a subset of these features available. PhoneGap thus manages to combine many of the advantages of native apps and web apps.

Technically, the resulting apps generated by PhoneGap are not truly native apps but hybrid apps. The apps use web views which display the HTML5 content, but they can be built to the platform's native format and therefore also distributed over several app stores.

Developers need to set up the SDKs for all platforms they want to develop for. This implies some limitations: In order to deploy build PhoneGap apps for iOS the iOS SDK is required, which in turn requires a Mac OS computer. PhoneGap supports the default IDEs for various platform (e.g., Eclipse with the Android Development Tools for Android) and only requires the libraries to be imported.

PhoneGap is an open source project and is available for free. It uses the Apache License (version 2.0).

Titanium Mobile SDK

The Titanium Mobile SDK by Appcelerator Inc. also offers the possibility to create native apps from a single code base. It comes with a complete IDE called Titanium Studio, which is based on the Aptana Studio web development UI. The app logic is written using JavaScript.

Similar to PhoneGap, Titanium offers an extensive API with access to native hardware and software features. It allows the use of additional JavaScript libraries such as jQuery. It currently supports iOS, Android and BlackBerry and also allows the creation of mobile web apps (the latter still being in beta status).

Appcelerator also offers a marketplace for templates, designs and modules for applications.

In contrast to PhoneGap, Titanium Mobile UIs are using real native UI components rather than web views. Like PhoneGap, Titanium Mobile requires the SDKs of the target platforms to be installed and set up within the SDK. It uses the Apache License (version 2.0), but the software is proprietary. The basic version of Titanium Mobile is free. There is also a Professional Edition and an Enterprise Edition. These offer additional support, some additional modules and early access to new features.

The feature of creating native UIs for different platforms is very promising. The SDK was only briefly examined for this paper and further investigation is necessary in order to evaluate how well Titanium handles the rendering of complex native UIs.

While the building of native apps can be an advantage, it also means more overhead as a number of different apps needs to be built and tested with every new update.

Testing user interfaces

Testing mobile user interfaces for different screen resolutions in itself is already a major hassle, and testing multi-platform mobile user interfaces can be even much worse [START_REF] Holzinger | On some Aspects of Improving Mobile Applications for the Elderly[END_REF], [START_REF] Holzinger | Work Lists for the Transport of Patients: A case for mobile Applications[END_REF], [START_REF] Holzinger | The influence of AJAX on Web Usability ICE-B 2010 -ICETE The International Joint Conference on e-Business and Telecommunications[END_REF]. Manual testing is practically feasible only for the most simplistic applications because typical software is usually far too complex to be tested thoroughly, and is continuously developed as it is changed or extended with new functionality.

Automatic testing can be a solution but the test code needs to be continuously kept up-to-date, and the problems arising with different screen sizes and systems are much intensified as then all tests need to be constantly maintained for all systems and display resolutions.

Mesbah & Deursen (2009) [START_REF] Mesbah | Invariant-based automatic testing of AJAX user interfaces[END_REF] propose a method for testing AJAX applications automatically by introducing CRAWLJAX, a crawler for AJAX applications, which can dynamically make a full pass over an AJAX application.

However, the medium term benefits of testing, especially when using test driven development style automatic GUI tests, are huge, e.g., in terms of developer satisfaction due to trustable software documentation (tests can be run and checkedthey serve as minimalistic declarative specification/programmer documentation that can be consulted and really correspond to the actual code) and reduced risks associated with evolving code, in particular when refactoring the code of other developers in larger teams (see [START_REF] Beck | Test Driven Development. By Example[END_REF] for more details).

A further problem that is particular to the Android platform is that different hardware providers often add their own UI customization that can introduce subtle changes in the behavior of otherwise identical Android version. E.g., HTC Sense substantially changes the behavior of certain buttons, fields, and the keyboard, thus necessitating either to deal with these differences on an individual basis in automatic GUI tests, or to ignore such hardware dependent differences, in particular as these customizations (which can be quite popular as in the case of HTC or Samsung Android devices) are not available on, e.g., the official Google Android emulator. This of course entails either to write tests for all these differences and to test on actual hardware, which needs a rather complicated setup for automatic tests, or to not test for them, which of course is also far from ideal.

The problem is further complicated for all platforms by the different OS versions. For example, most Android phones currently run Android version 2.x. New models are delivered with Android version 4.x, and older models are increasingly updated to this newer version. However, fundamentally new GUI possibilities have been introduced in the newer versions, e.g., the possibility to have several resizable but non-overlapping "windows" on the screen at the same time (with some limitations), or to have resizable "gadgets" on the home-screen. Testing for different OS versions thus can further complicate the issues for developers, though being able to run automatic GUI tests on an emulator that is able to execute different OS versions can be very helpful. Note however that, e.g., Google's Android emulator does not support OpenGL 2.x and thus is of limited value for game developers. It unfortunately is also very slow.

Additional problems arise when one wants to test hardware features such as sensors (e.g., GPS or gyro-sensors where we would like to simulate sensor input for testing purposes -the OpenIntents sensor simulation framework solves this at least for Android), effectors (e.g., the flash light or the vibration feature), or connectivity like Bluetooth protocol stacks and internet access.

Nevertheless, there exist some very useful tools that allow automatic GUI testing of mobile apps for Android, iOS, Windows Phone devices as well as HTML5/Javascript based applications, including, e.g., Robotium and Roboelectric for Android, or Selenium 2 for mobile HTML5/Javascript (Android and iOS are particularly supported).

Our research has shown that different platforms allow different ranges of screen sizes, with the Android platform supporting the highest variability along with a wide collection of tools for designing UIs for multiple screens, such as density independent pixels and size standards.

The iOS platform supports a strictly limited number of screen types. It handles the different resolutions of older and newer devices very well by measuring the resolution in the abstract unit of points rather than physical pixels. The same UI layout can therefore be used for old and new iPhones and iPod Touch devices with little regard to the different physical screen resolutions.

The iPad, however, differs from the other iOS devices in size, resolution and aspect ratio. It is therefore recommended to design separate UIs for iPad and iPhone / iPod Touch.

We have also observed that the platform SDKs offer ways to separate the UI definition from the application logic, therefore supporting the use of the Model-View-Controller (MVC) pattern [START_REF] Holzinger | Applying Model-View-Controller (MVC) in Design and Development of Information Systems: An example of smart assistive script breakdown in an e-Business Application ICE-B[END_REF]. We encourage developers to clearly separate the UI definitions from the rest of a code base. This separation makes it much easier to create scalable user interfaces.

Following platform conventions is very important on mobile devices, especially when developing native apps. Standard usability engineering methods [START_REF] Holzinger | Usability engineering methods for software developers[END_REF] are important, but UI designers need to be aware of the platform-specific guidelines for all target platforms in order to successfully apply usability engineering principles to mobile applications [START_REF] Holzinger | Usability Engineering und Prototyping, Beispiel Mobile Computing[END_REF].

When comparing native apps to web apps in general, there is no clear recommendation to be given. The choice of whether to develop native apps, web apps, hybrid apps or to use a multi-platform framework depends on a number of things. The requirements of the app and the resources available as well as the target audience should be considered.

The skills of the developers are another important factor, as learning how to develop apps for one or more mobile platforms can be very time consuming. It can be a great asset for app development to have developers who are already skilled in one or more platforms' native programming languages and APIs, or in HTML5, CSS and JavaScript. This advantage should be leveraged.

It is also worth mentioning that multi-platform frameworks are growing very rapidly and both updates to existing frameworks and the introduction of new frameworks occur frequently. We recommend comparing the features of the most recent versions of various frameworks before deciding on one.

Another very important thing is to be aware of the limitations of the frameworks. First and foremost, these frameworks only offer tools for creating UIs for multiple platforms and screen sizes. It is the responsibility of the designers and the developers to ensure that the apps run properly on all the target platforms and devices. None of the frameworks can substitute thorough testing of the app.

There are a number of different tools and means to scale user interfaces on the mobile platforms examined. These are, however, only tools and it is up to the designers and the developers to ensure that their user interfaces look good and are well usable on all target devices. While the well thought-out definition of layouts is a good foundation for this, it must be stressed that there is no way around testing the interface. This can be done on actual devices or on various configurations of the emulators provided by the platform IDEs, but there are many hard challenges associated with automatic GUI testing.

With regard to multi-platform development and the choice between developing native apps or HTML5 web apps, no definitive recommendation can be given. The best choice always depends on a number of factors, such as the app's intended features, the target audience or the skills of the development team.

Multi-platform frameworks offer some interesting features, especially for rapid prototyping or the development of very simple apps. These frameworks are growing rapidly and new features are being added frequently, so we recommend inspecting several platforms' features before starting multi-platform development and carefully choosing a well-suited framework.

Figure 2 :

 2 Figure 2: A side-by-side comparison of the mobile iOS devices. Individual image sources:Technical device specifications as found on www.apple.com.

Table 1 :

 1 Smartphone shipments (in millions) and shares in the year 2011 by platform[START_REF]Canalys: Smart phones overtake client PCs in[END_REF]

Platform Full year 2011 shipments Share Growth Q4'11 / Q4'10 Total

		487.7	100.0%	62.7%
	Android	237.8	48.8%	244.1%
	iOS	93.1	19.1%	96.0%
	Symbian	80.1	16.4%	-29.1%
	BackBerry	51.4	10.5%	5.0%
	Bada	13.2	2.7%	183.1%
	Windows Phone	6.8	1.4%	-43.3%
	Others	5.4	1.1%	14.4%

Table 2 :

 2 Programming languages on mobile platforms

	Platform	Programming languages
	Android	Java
	iOS	Objective-C
	Symbian	C++
	BlackBerry	Java
	bada	C++
	Windows Phone	C#

Table 3 :

 3 Shares of Android devices per size and density[START_REF]Android-developers: Screen Sizes and Densities[END_REF]. Data collected by Google and based on devices which accessed the Google Play store in early March 2012

		ldpi	mdpi	hdpi	xhdpi
	small	1.7%		2.4%
	normal	0.7%	18.5%	66.3%	2.5%
	large	0.2%	2.8%
	xlarge		4.9%

Table 4 :

 4 Comparison of the displays of iOS devices. Source: Technical device specifications as found on www.apple.com.

	Device	Screen size	Resolution	Aspect ratio
	iPhone (up to 3G)	89mm	480 x 320	3:2
	iPhone (4 and 4S)	89mm	960 x 640	3:2
	iPod Touch	89mm	480 x 320	3:2
	(up to 3 rd gen.)
	iPod Touch	89mm	960 x 640	3:2
	(4 th gen.)
	iPad	250mm	1024 x 768	4:3
	(up to 2 nd gen.)
	iPad (3 rd gen.)	250mm	2048 x 1536	4:3

Table 5 :

 5 Advantages of native and HTML5 web apps. Sources: Meier and Mahemoff (2011) and own original research

	Native app advantages	Web app advantages
	 Broad access to device hardware	 Large target audience (mobile
	and platform features  Close integration with platform	platforms + desktop)  Easy multi-platform
	and other apps  Better performance  Visibility through app store(s)  On-device storage	development  Easy to update across all platforms  No certification required


Yutaka Matsuno

Shuichiro Yamamoto

Consensus Building and In-operation Assurance for Service Dependability

. We also describe how D-Case is used for in-operation assurance.

Introduction

Recent information systems have become large and complex by interacting each other via networks. This makes assuring dependability of systems much more difficult than ever before.

For assuring dependability of such systems, we observe that stakeholders should reach consensus on dependability requirements, and there should be a mechanism to ensure that dependability requirements are satisfied during in operation in such open environment where several interdependency may exist. We extend conventional assurance cases for ensuring that stakeholders' requirements are satisfied during operation. The extended assurance case is called D-Case [START_REF] Matsuno | Toward a language for communication among stakeholders[END_REF].

Based on above observation, this paper proposes a consensus building cycle which consists of the following three phases: 1) requirements elicitation and risk analysis, 2) stakeholders agreement on requirements, and 3) In-operation assurance using D-Case. In the course of consensus building, elicited requirements may possibly be revised. Requirements are also changing when stakeholder s agreements are updated(Fig. 1).

Fig. 1. Consensus Building and In-operation Assurance Cycle

Assume that a system is newly developed for some service objectives given by stakeholders. In the first phase, requirements are elicited from each of the stakeholders who have their needs described in an informal way, and then risks for their requirements are analyzed from various viewpoints. In the second phase, these elicited requirements are argued among the stakeholders using D-Case in order to reach agreement. In case the stakeholders cannot reach agreement on the requirements, some of the requirements will be returned to the first phase to revise. Once the agreement is made, programs are developed according to the D-Case description and other documents such as functional specifications. At the same time, D-Scripts, scripting codes for failure mitigation actions, are extracted from the D-Case description, which will be used to monitor the system, to collect logs, and to respond to failures quickly. When the system needs to be revised due to objectives/environment changes, this cycle is restarted with new requirements being elicited and old requirements being modified. This corresponds to the Change Accommodation Cycle.

The third phase provides the means to assure the agreement in the program execution by monitoring and instructing the system and managing requirements online for accountability achievement. A runtime environment called D-RE, monitors the system and collects logs of the system as designated by D-Scripts. If some logs show a deviation of some parameters from their in-operation ranges, the corresponding failure responsive actions designated as D-Script codes are activated. D-RE and D-Scripts have been developed in DEOS (Dependable Embedded Operating System) Project [START_REF] Tokoro | White paper: Dependable embedded operating system for practical use (DEOS) project[END_REF]. In case a need for a requirements change occurs as a result of the failure responsive actions, the above mentioned cycle is restarted with some requirements being modified. There may be a case that a failure responsive action fails to respond to the failure. Such a case may happen due to some unexpected environment changes, inadequate risk analysis, bugs of the D-Script itself, and so forth. In such a situation, the above mentioned cycle must also be restarted.

The structure of this paper is as follows. In Section 2, we introduce our requirement elicitation and risk analysis methods. Section 3 introduces D-Cases for making agreement among stakeholders and in-operation assurance. Requirements management is described in Section 4. In Section 5, we show current implementation status. Section 6 concludes this paper.

Requirements Elicitation and Risk Analysis

The requirements elicitation starts with the service objectives. Stakeholders can be defined according to their service objectives. Requirements are generated from each stakeholder s objectives and needs. Here, requirements include service requirements and dependability requirements. Regulations made by regulatory agencies can be considered as a kind of requirements. The activities for requirements elicitation must include identification of various levels of requirements in order for this task to be manageable.

In requirements engineering, various requirements elicitation methods have been proposed: Ethno-Methodology, Trolling, Business Modeling, Goal Oriented Analysis, Use Case Analysis, Misuse Case Analysis, Triage, etc. [START_REF] Mark | Just Enough Requiremtns Management-Where Software Development Meets Marketing[END_REF][START_REF] Zowghi | Requirements Elicitation: A survey of Techniques, Approaches, and Tools[END_REF][START_REF] Aurum | Engineering and Managing Software Require-mentsEngineering and Managing Software Requirements[END_REF][START_REF] Kotonya | Requirements Engineering-Process and Techniqeus[END_REF] We focuses on dependability in its requirements elicitation and requirements analysis. First, needs are extracted from stakeholders who describe them informally and verbally, and from these, dependability needs are obtained. Second, dependability requirements are identified through the analysis of dependability needs. Next, service continuity scenarios are created based on risk analysis and service requirements. More precisely, service continuity scenarios are developed by considering and determining countermeasures for each factor causing deviations. Finally, D-Case and D-Script are created through consensus building among stakeholders based on the service continuity scenarios.

Table 1 shows management techniques used to elicit requirements and analyze risks. Service consensus building card (SCBC) is used to define service requirements and to agree on the requirements among stakeholders. Dependability Control Board (DCB) manages consensus building process with SCBC. DCB members are representatives of stakeholders. Dependability Control Map (DCMap) describes relationships among dependability goals as well as roles of stakeholders. D-Cases are stored in D-Case DB and used to achieve dependability goals for dependability requirements of services. Service Risk Brake-down Structure (SRBS) hierarchically decomposes risks into categories. Service Fault Tree (SFT) describes the logical conditions for failures. Service Continuity Scenario (SCS) are designed to mitigate risks for dependability requirements. SCS are implemented by D-Scripts. Service Risk Management Table (SRMT) defines service risks based on probabilities and impacts of failures according to service event scenarios. Service Requirements State Management (SRSM) manages service requirements state not only during online but also offline. Fig. 2 shows relationships among techniques given in Table ??. Dependability requirements in DCMap are precisely defined and agreed on using SCBC. SRBS is then used to analyze risk category. SRMT is used to identify and mitigate risks of services elicited using SCBC. SFT is developed for each scenario in SRMT to show conditions of fault occurences. D-case is developed to confirm the dependability for services against risks based on the information of DCMap and SRMT. identify and mitigate risks of services elicited by SCBC. SFT is developed for each scenario in SRMT to show its occurrence condition. D-case is developed to confirm the dependability for services against risks based on the information of DCMap and SRMT.

An example of Dependability Control Map is shown in Fig. refDepControl. DCMap contains three columns that are stakeholder, roles, and dependability goals. Stakeholders and roles columns constitute RACI matrix [START_REF][END_REF]. In the role column, RACI identify roles of stakeholders such that Responsible, Accountable, Consulted, and Informed.

The dependability goals column describes goals of stakeholders and their relationships. DCMap can be used to analyze goals as follows. Users want to reach consensus on service dependability. This is accomplished by accountability achievement goal of system providers. The accountability achievement goal is supported by goals of developer and maintainer. Dependability goal of developer is also supported by hardware dependability and valid software authorization. Table 2 shows an example of service consensus building card. SCBC consists of requirements name, event, response, input, output, functional requirements steps, initiation condition, completion condition, and roles of stakeholders. This figure omits the identification of SCBC for simplicity. Fig. 4 shows an example of Service Risk Breakdown Structure. Service risks are broken down into internal, goal, external, organizational, and technical risks. A service has a goal that is the intention and result that an actor, who wants to use the service, expects to get from the system. By getting an event from actors, services will act on objects and generate a result to achieve the goal. Services will also make responses to actors. Services work on an environment including hardware and network. Deviations of these ordinal service constituents will cause service risks. Service continuity scenarios can be constructed to mitigate these risks by considering deviations of service constituents. This risk breakdown structure is based on those of PMBOK. Table 3 shows an example of Service Risk Management Table. SRMT describes initial events, dependability actions, scenarios, probabilities, severity of impacts, and risks. The structure of SRMT is decomposed into two parts. The left part of SRMT describes scenarios using a binary tree of success and failure. The right part of SRMT describes the risk of each scenario.

There are two types of dependability actions. D-Scripts are applied to responsive recovery for deviations by failures. In the change accommodation cycle of DEOS process [START_REF] Tokoro | White paper: Dependable embedded operating system for practical use (DEOS) project[END_REF], human operators manage deviations in cooperation with DCB. Logical structure of failure scenarios in SRMT can be described in the similar way of fault trees.

Leveson [START_REF] Nancyy | Safeware: System Safety and Computers[END_REF] and Ericson [START_REF] Ericson | Hazard Analysis Techniques for System Safety[END_REF] introduced methods for safety requirements analysis, such as FMEA, HAZOP, FTA, ETA. Kotonya and Sommerville showed a method for analyzing safety requirements using Hazard analysis and FTA [START_REF] Kotonya | Requirements Engineering-Process and Techniqeus[END_REF]. Troubitsyna proposed Component based FMEA (Failure Mode and Effects Analysis) to analyze how component failures affect behavior of systems [START_REF] Troubitsyna | Elicitation and specification of safety requirements[END_REF]. Sask. and Taniyama proposed Multiple Risk Communicator to the personal information leakage problem [START_REF] Sasaki | Development concept for and trial application of a multiplex risk communicator[END_REF][START_REF] Taniyama | Application of Multiple Risk Communicator to the Personal Information Leakage Problem[END_REF].

D-Case: Assurance Case for Stakeholders Agreement and In-Operation Assurance

It has become almost impossible to sustain dependability of the systems only by conventional methods such as formal methods and testing. We observe that the best way is stakeholders argue dependability of the system with evidences supported by experts, and try to reach agreement that the system is dependable through the whole system lifecycle. For the objectives, first, we need a method to describe and evaluate dependability requirements. Dependability requirements need to be understood by diverse stakeholders involved in the whole system lifecycle. Second, a mechanism should be in place that ensures traceability between dependability agreement and actual system behaviors. The mechanism not only keeps track of the development phases of a system, but also its run-time operations by constantly checking whether dependability requirements are being satisfied or not. In particular, we must update dependability agreement when changes occur. To achieve these two goals, we have started our study with system assurance. The notion of assurance is to convince a person (usually to a certification body) that something is definitely true. We aim to extend assurance to agreement among stakeholders. Risk communication is used in similar contexts, but risk is only a part of dependability. We decided to exploit assurance case [START_REF]Workshop on Assurance Cases: Best Practices,Possible Obstacles, and Future Opportunities[END_REF] to describe and evaluate dependability requirements. Assurance cases are structured documents for assuring dependability/safety/reliability/etc. of systems based on evidences. This simple framework has recently been widely used for safety critical domain. This is because as systems become large and complex, only following some safety checklists does not satisfy safety requirements, but assuring safety of systems becomes crucial. Assurance case is one of promising approach to dependability achievement. Current assurance cases, however, are mostly written in weakly-structured natural languages, and it is difficult to ensure traceability between assurance cases (and associated documents) and system s actual states during the whole lifecycle. Based on the above observations, we propose D-Case [START_REF] Matsuno | Toward a language for communication among stakeholders[END_REF] to achieve these two goals. The two goals are re-stated as follows:

-Develop a method to evaluate and describe dependability of the system, and reach agreement among stakeholders on the dependability. -Develop a mechanism to ensure traceability between the dependability description and the systems actual behaviors. We call this mechanism as In-Operation Assurance .

Due to space limit, in this paper we only show our initial ideas and implementation for "In-Operation Assurance."

D-Case

Background System assurance has become very important in many industrial sectors. Safety cases (assurance cases for safety of systems) are required to be submitted to certification bodies for developing and operating safety critical systems, e. g., automotive, railway, defense, nuclear plants and sea oils. There are several standards, e.g., EUROCONTROL [START_REF]Safety case development manual[END_REF] and MoD Defence Standard 00-56, which mandate the use of safety cases. There are several definitions for assurance cases. We give one such definition as follows [1].

a documented body of evidence that provides a convincing and valid argument that a system is adequately dependable for a given application in a given environment.

Assurance cases are often written in a graphical notation. Goal Structuring Notation (GSN) is one of such notations [START_REF] Kelly | The goal structuring notation -a safety argument notation[END_REF]. Writing assurance cases and reusing them in a cost effective way is a critical issue for organizations. Patterns and their supporting constructs are proposed in GSN to enable the reuse of existing assurance cases, which includes parameterized expressions. Another widely used notation is Claims, Arguments and Evidence (CAE), which was developed by Adelard and City University London [2]. We show D-Case nodes (Fig. 5) and an example (Fig. 6). Current D-Case syntax is based on GSN with extensions for our needs: monitoring node and external node.

We briefly explain constructs and their meanings in D-Case. Arguments in D-Case are structured as trees with a few kinds of nodes, including: Goal nodes for claims to be argued for, Strategy nodes for reasoning steps that decompose a goal into sub-goals, and Evidence nodes for references to direct evidences that respective goals hold. Undeveloped nodes are attached to goals if there are no supporting arguments for the goals at that time. In D-Case, monitoring nodes are a sub-class of evidence nodes. They are intended to represent evidences available at runtime, corresponding to the target values of in-operation ranges. An external node is a link to the D-Case of other system. External node will be used in cases where part of the dependability of a system is supported by another system. Previously it was called system component node [START_REF] Matsuno | Toward a language for communication among stakeholders[END_REF]. Fig. 6 is a simple example of D-Case. The root of the tree must be a goal node, called top goal, which is the claim to be argued (G1). A context node C1 is attached to complement G1. Context nodes are used to describe the context (environment) of the goal to which the context is attached. A goal node is decomposed through a strategy node S1 into sub goal nodes (G2, G3, and G4). The strategy node contains an explanation, or reason, for why the goal is achieved when the sub goals are achieved. S1 explains the way of arguing (argue over each possible fault: A and B). When successive decompositions reach a sub goal (G2) that has a direct evidence of success, an evidence node (E1) referring to the evidence is added. Here we use a result of fault tree analysis (FTA) as the evidence. The sub goal (G3) is supported by monitoring node M1. In this D-Case, G3 is supported by runtime log results. The sub goal (G4) is supported by external node (Ext1). This indicates that the dependability requirement 3 (security) in C1 would be supported by another system

In-operation Assurance

This section shows our initial idea of in-operation assurance by describing a reference implementation. A demo of our idea was presented in Embedded Tech- contains mappings between variables used in D-Case pattern and corresponding system modules. Using the table, D-Case pattern is translated to D-Script. The right-hand side of Fig. 7 is a simplified D-RE, in which the Monitoring Unit and Action Unit have monitoring and failure response action modules, respectively for system components. The key concept of the reference system is that only system behaviors, which are agreed upon and stored as D-Cases, can be executed. Operators of the system would choose appropriate action as a failure response action based on D-Case from agreed upon D-Cases. Fig. 7 shows an example of D-Case pattern, which is an argument for over usage of CPU resources. The D-Case pattern argues that if CPU usage rate becomes over 50% (this can be detected by monitoring), the failure recover control unit invokes CPU resource usage module to restrict CPU usage under 50%. In Fig. 8, a monitoring node is exploited. Task A , CPU resource usage rate , and under 50% in those monitoring nodes are value of parameters which operators and other stakeholders agreed. For example, we can specify the name of some other CPU task instead of A , Memory resource usage rate instead of CPU usage rate , etc. Setting the values of parameters automatically generates executable codes.

Requirements Management

In requirements management, as mentioned above, states of requirements are managed. There are four kinds of the states; elicited, agreed, ordinarily operated, and deviated (Fig. 9). First, requirements are elicited from stakeholders. These elicited requirements may conflict with each other. By consensus-building, requirements are agreed upon among the stakeholders. Agreed-upon requirements are then implemented in ordinary operations. When objectives and environments change, some ordinarily operated requirements may become obsolete and new requirements must be elicited again. This is referred to as the change accommodation cycle.

If a requirement is not fulfilled, i.e., there is deviation from the corresponding in-operation range, it moves to the deviated state. When a responsive action is possible, it moves back to the ordinarily operated state. This is referred to as the failure reaction cycle. If the service continuity scenarios cannot work for some requirements in the deviated state, these requirements should be modified and move to the elicited state. If deviations came from the implementation problems, the corresponding elicited requirements do not need any change. But it is necessary to agree on other requirements to revise the faulty implementation. This is done by consensus-building. The elicited and agreed states of requirements are managed at offline, whereas ordinarily operated and deviated states are managed online. The state of the system is represented by a set of these requirements states. Fig. 10 shows how this set of requirements are managed by requirements management table as the system evolves.

Traditional requirements management (TRM) methods only consider states of requirements at offline [START_REF] Kotonya | Requirements Engineering-Process and Techniqeus[END_REF][START_REF] Mark | Just Enough Requiremtns Management-Where Software Development Meets Marketing[END_REF][START_REF] Sommerville | Requirements Engineering: A Good Practice Guide[END_REF][START_REF] Leffingwel | Managing Software Requirements A Unified Approach[END_REF][START_REF] Wiegers | Software Requirements-Practical techniques for gathering and managing requirements through the product development cycle[END_REF][START_REF] Pohl | Requirements Enginerring Fundamentals, Principles, and Techniques[END_REF][START_REF] Berenbach | Software and Systems Requirements Engineering In Practice[END_REF]. These requirements engineering text books describes requirements management process by Change Control Board (CCB) with requirements change requests. TRM does not consider requirements deviations at runtime. Requirements management state model can take into account deviations of requirements at runtime. To detect and manage deviation, it is necessary to record the deviation situations on requirements with identifications, events, inputs, outputs, and responses. Otherwise, there is no evidence on deviations and it is impossible to analyze failures.

Implementation Status

Currently the requirement elicitation and risk analysis methods have been designed. Also, we have been developing "D-Case Editor" [3], which is a tool to support stakeholders agreements, and D-Case Viewer , which is a tool to monitor whether stakeholders agreements are satisfied or not. Current D-Case Editor is a graphical editor as an Eclipse plug-in. Fig. 8 is also a snapshot of D-Case Editor.

D-Case Editor has several basic functions and experimental functions including the followings.

1. Checks on the graph structure of D-Case (e.g. no-cycle, no-evidence directly below a strategy, etc.) 2. External documents via URL can be attached to a node. 3. Patterns with typed parameters can be registered and recalled with parameter instantiations. 4. Graphical diff to compare two D-Cases. 5. A "ticket" in Redmine, a project management web application, can be attached to a goal; the ticket's status can be reflected graphically in D-Case.

The main function of D-Case Viewer is monitoring: a URL to be polled by Viewer can be attached to a node; the answer is dynamically reflected in D-Case. Fig. 11 is a snapshot of web server system demo shown at ET2011, Yokohama, Japan (D-Case Viewer has been currently under development, and D-Case Editor is instead used for monitoring.) In D-Case Viewer, the monitoring node about access number of the web server and the goal are highlighted as red to indicate that access number of the web server system exceeded over 2500 times/minutes (this is an in-operation range). Nodes highlighted as yellow are about failure response actions invoked at just that time. Using D-Case Viewer, operators of the system can always see that all in-operation ranges are within as required or not, and which failure response actions are invoked, as agreed or not. This correspondence between D-Case description and systems actual behaviors is an important source for achieving accountability1 .

Concluding Remarks

This paper has reported our initial ideas and implementation for consensus building and in-operation assurance for service dependability. We have presented several methods for requirement elicitation and risk analysis. Also we have presented D-Case, which is an extension of assurance case for in-operation assurance. One clear challenge is to develop a method to describe D-Case from those requirement elicitation and risk analysis as inputs. Methods for developing assurance cases have been developed in some works such as [START_REF] Despotou | Managing the Evolution of Dependability Cases for Systems of Systems[END_REF]. We would like to report our progress, and compare with such works in near future.

Fig. 2 .

 2 Fig. 2. Relationship of RM Techniques

Fig. 3 .

 3 Fig. 3. An Example Dependability Control Map

Fig. 4 .

 4 Fig. 4. An Example of Service Risk Breakdown StructureTable 3. An Example of Service Risk Management Table

Fig. 5 .

 5 Fig. 5. D-Case Nodes

Fig. 6 .

 6 Fig. 6. D-Case Example nology 2011, one of the largest exhibitions for embedded systems in Japan. Fig.7 shows a reference system for In-Operation Assurance. D-Case DB contains D-Case patterns for failure response. D-Case Pattern ⇔ Module Mapping Table contains mappings between variables used in D-Case pattern and corresponding system modules. Using the table, D-Case pattern is translated to D-Script. The right-hand side of Fig.7 is a simplified D-RE, in which the Monitoring Unit and Action Unit have monitoring and failure response action modules, respectively for system components.The key concept of the reference system is that only system behaviors, which are agreed upon and stored as D-Cases, can be executed. Operators of the system would choose appropriate action as a failure response action based on D-Case from agreed upon D-Cases. Fig.7shows an example of D-Case pattern, which is an argument for over usage of CPU resources. The D-Case pattern argues that if CPU usage rate becomes over 50% (this can be detected by monitoring), the failure recover control unit invokes CPU resource usage module to restrict CPU usage under 50%. In Fig.8, a monitoring node is exploited. Task A , CPU resource usage rate , and under 50% in those monitoring nodes are value of parameters which operators and other stakeholders agreed. For example, we can specify the name of some other CPU task instead of A , Memory resource usage rate instead of CPU usage rate , etc. Setting the values of parameters automatically generates executable codes.

Fig. 7 .

 7 Fig. 7. A Reference System for In-Operation Assurance

Fig. 8 .

 8 Fig. 8. An Example of D-Case Pattern

Fig. 9 .Fig. 10 .

 910 Fig. 9. Requirements State Management Model

Fig. 11 .

 11 Fig. 11. A Snapshot of Web Server Demo

Table 1 .

 1 Requirement Management Table

Table 2 .

 2 An Example Service Consensus Building Card

Interested reader may check a demo video: http://dl.dropbox.com/u/13455869/demo.mp4