Introduction

Feature Usage Explorer was developed to support feature reduction initiative [1], which aims to automatically identify features with a low value (i.e. very rarely used) and systematically remove them from the system. The reduction initiative is of commercial interest as between 30 to 50 per cent of most software products consist of unnecessary features [2], known as Software Bloat [3]. This causes computer applications to become slower and require higher hardware capacities, both of which increase the costs of system maintenance.

To address the problem of Software Bloat Feature Usage Explorer, automatically detects features in web applications, monitors their usage, and creates a figure which enables users to visualize the collected information. In this context a feature is: “a realized functional requirement of a system (i.e. is an observable unit of behaviour of a system triggered by the user)”[4], where the user can be human, other system, web-service, etc.

The efficacy of the Feature Usage Explorer was assessed for recall and precision measurements [5]. The results from this case study demonstrated the ability of the tool to determine complete feature sets with high accuracy. Note that at present this tool works only on HTML5 technology and features using flash technology are not presented in the feature set.

Objective methods, which could help to estimate the value of a feature, were explored in a separate case study [6]. Estimating the value of a feature currently involves detailed questionnaires that are not only costly but are also limited in their value due to non-compliance of key stakeholders.

Finally, the introduction of a modelling notation, Feature Usage Diagram, which enables users to visualize feature usage information, was evaluated in [7]. Validation of the elements of the Feature Usage Diagram was determined in a separate case study. The results showed that users find the notation easy to learn and understand, and that the tool support would make it practical to use. Therefore, a Feature Usage Diagram was added to Feature Usage Explorer. The decision makers could use this notation during the feature reduction process.

There are several existing techniques that allow users to collect usage related information in a software system [8, 9, 10]. The advantage of the Feature Usage Explorer is that it helps to analyse the system strictly on a feature level, while the existing approaches were not created for this purpose: [8] and [9] collect too much irrelevant data; [10] analyses the system on too abstract level. For example, they collect all random clicks and button strokes, or monitor the website usage on a page level.

Implementation/architecture

Feature Usage Explorer was developed using JavaScript programming language, fabric and jquery frameworks. The functionality of the tool can be used only after Document Object Model (DOM) of the targeted website is downloaded, because the tool monitors the DOM in order to identify features and detect their usage.

The Feature Usage Explorer can be used in three different ways:

1. Determine a complete feature set of the website of interest. In order to verify if the tool is able to identify the features of interest it is recommended to check this functionality first. The detailed description on how to identify all features of the system is provided in the user manual (see explorer.getFeatures(Events)). Determine a complete feature set of the website of interest. In order to verify if the tool is able to identify the features of interest it is recommended to check this functionality first. The detailed description on how to identify all features of the system is provided in the user manual (see explorer.getFeatures(Events)).
2. Collect the usage information about the features of the website of interest. If the user is satisfied with the features identified by the Feature Usage Explorer in the first step, then monitoring the usage of features can be carried out following the user manual (see explorer.monitorFeatures(Event)). Currently, the usage information is outputted to the console of the browser. However, the user is expected to substitute this part with an ajax call, which sends the collected information to the selected data storage.
3. Visualize the collected information in a Feature Usage Diagram. Visualising the collected information in Feature Usage Diagram (see Fig. 1) can be carried out using the input json file. The detailed description on how to visualize the usage information is provided in the user manual (see explorer.initDiagram(url)). Currently, the user of the library has to design a tool, which generates the json file from the collected usage information. As this step is reliant on the means of data storage the design of the tool is left for the user. A demo json file generator, written in Java programming language, is available on the repository of the Feature Usage Explorer.

Currently, Feature Usage Explorer allows the user to obtain the following information about the features:

1. Feature name
2. A full path in DOM to the feature
3. A HTML5 element, which represent a feature
4. A timestamp when the feature was used

Since the input json file has to be provided by the user of Feature Usage Explorer, more detail concerning how it has to be designed is provided. The json file must have the following structure:

	[{
	  "id": 1,
	  "name": "Feature name string",
	  "usage": "Number of times feature was used string",
	  "type": "Feature",
	  "siblings": [],
	  "linksOut": [{
		"id": the id of a feature to which this link is pointing to, 
		"cardinality": "Number of times a feature was accessed using this path"
	},
	{...}],
	  "linksIn": []
	},
	{...}]
				

A more detailed description of the aforementioned fields is provided below:

• id. This field represents a unique identifier of a feature, or a feature group. It can have any integer value.
• name. This field represents the name of a feature, or a feature group. It can have any string value.
• usage. This field shows how many times a feature was used. It can have any string value.
• type. This field can have only two values “feature”, or “feature group”. If a type is “feature group” then “siblings”:[] attribute must be present, which represents features that are in the feature group. The siblings’ field must have the same attributes as feature: id, name, usage, type, linksOut, linksIn.
• linksOut. This field represents outgoing links from a feature, or a feature group. It can have a multiple links outgoing links.
• linksIn. This field represents incoming links to a feature, or a feature group. It can have a multiple incoming links.

The example of the input json file is available in the code repository: https://raw.github.com/smarciuska/feature-usage-explorer/master/json-examples/json.txt

A demo json file generator, written in Java programming language, is available in the code repository: https://github.com/smarciuska/feature-usage-explorer/tree/master/simple-json-generator. More details on how to configure Feature Usage Explorer library are provided in the user manual: https://github.com/smarciuska/feature-usage-explorer/blob/master/UserManual.pdf.

The example with Feature Usage Explorer functionalities is provided in demo.html file: https://github.com/smarciuska/feature-usage-explorer/blob/master/demo.html.

Quality Control

User-acceptance tests were performed during the case studies. The GUI has been tested on Mozilla Firefox, Google Chrome and Apple Safari. We provided several different input json files to test the automatic Feature Usage Diagram generation.

Operating system

Any operating system, which has one of the following web-browsers: Firefox 2+; Safari 3+; Chrome 1+.

Programming Language

JavaScript, HTML, CSS.

Additional system requirements

Feature Usage Explorer can be integrated only on web based applications.

Dependencies

jquery 1.6:https://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.js

fabric 0.9.35:https://github.com/kangax/fabric.js/tree/v0.9.35

List of contributors

1. Sarunas Marciuska (marciuska.sarunas@gmail.com)
2. Pekka Abrahamsson (pekka.abrahamsson@unibz.it)

Archive

Code repository

(3) Reuse potential

Feature Usage Explorer has a great potential to be reused in any situation where companies, or researchers need to understand how users interact with the system: user experience, usability studies, human computer interaction, feature reduction, and requirement engineering fields.

For example, in feature reduction field, Feature Usage Explorer can help to identify a complete feature set. The tool can then monitor the usage of features and send the collected information to a selected data storage. Finally, the usage data can be visualized in Feature Usage Diagram. The Feature Usage Diagram might reveal rarely used features, which are the primary target for the feature reduction. Moreover, the library can be easily extended to enrich the existing functionality in order to satisfy more specific needs. For example, a company might be interested to understand not only which features are used, but also who the users are. Therefore, the code could be extended to send the ip address or user name to the server if it is stored in a session/cookie variable.

Moreover, the software could be particularly useful in requirement engineering field. Currently, the requirements are prioritized and their value is estimated through questionnaires and surveys of the key stakeholders. The usage information collected by the tool can be used as an automatic feature value indicator. For example, the most frequently used features might indicate high value, while the rare used features might mean that they are not that valuable for the users [6]. Of course, company should take into consideration that some features are intended to be used rarely (i.e. settings).

Finally, the Feature Usage Explorer can be used in user experience studies in order to improve the quality of a system. The tool already provides sufficient information for the analysis of feature patterns, including feature usage data and feature usage visualization. The decision makers can use this information to redesign the system in such a way that it is more attractive for the users. For example, the usage patterns might show that users use login functionality many times in comparison to the other features. In this case company might redesign the system in such a way that it remembers user credentials and uses them to automatically login to the system.

Most of the aforementioned extensions can be easily implemented by sending extra information to a selected server using ajax calls:

	$.ajax({
	  dataype: "json",
	  url: url-to-server + ”?parameter-name=” + EXTRA-INFORMATION,
	  data: data,
	  success: success
	});
				

To modify or to extend the Feature Usage Diagram would require modification of the code of the library. The complexity of the task is directly related to the modification which is required but it likely to prove challenging. For example, it is relatively easy to add additional attributes to a feature or a feature group, but it is more complicated to extend the code that user can manually select the list of features and then group them into a feature group.