Urban air pollution is a major public health and sustainability concern, yet there is a limited understanding of how air-quality monitoring is incorporated into users’ everyday routines. Drawing on social practice theory, we examine monitoring as a configuration of materials, competences, and meanings, and report results from an exploratory survey of end users ( = 91). We identify two monitoring configurations: situational monitors, who report infrequent monitoring and lower indicator familiarity, and tech-engaged monitors, who report more regular monitoring and greater engagement with monitoring tools. Building on these patterns, we extrapolate design implications for wearable air-quality monitors (WAQMs), including support for different monitoring rhythms, design for interpretation and situated action, and bodily and domestic integration. We position this work as exploratory and call for qualitative and longitudinal research on monitoring-as-practice.

A software product line is a set of products that share a set of software features and assets, which satisfy the specific needs of one or more target markets. One common artefact of software product line engineering is a feature model, usually represented as a directed acyclic graph, which shows the product line as a set of structural feature relationships. We argue that there are benefits to considering a feature model as a directed graph and an undirected graph, respectively. One element of managing the impact of a change to these models, as they increase in complexity, is to evaluate the relative importance of the features. This paper explores the application of centrality metrics from social network analysis for the identification of the relative importance of features in feature models. The metrics considered are degree centrality, closeness centrality, eccentricity centrality, eigenvector centrality and between-ness centrality. To illustrate, a product feature model is constructed from a real-world GSMA AI-mobile phone product line requirements specification.

As a software product line evolves a significant management challenge is comparing existing products to each other or planned products. The approach to product comparison will vary according to its purposes. One solution includes the representation of a configured product as a weighted binary string where 1 represents a feature’s presence, 0 represents its absence, and the weight represents the different levels of relative importance to the product that a feature is perceived to have. Relative importance values influence similarity matching so that the features considered important are the ones that primarily influence what is judged to be similar. A binary string similarity metric supports product comparison (a product similarity metric). For a product line that contains thousands of features the allocation of relative importance values is only practical when done automatically. This paper proposes a novel algorithm for automatically determining the relative importance of each feature. A feature tree can represent a product line in which a feature is a node in the tree and a relationship between features is an edge. A feature’s relative importance is calculated as a function of local and global tree structural measures. The local measures are the number of input and output nodes to which a feature is connected and the variability property of each of these nodes. The global measure is the distance of the feature from the root node. A mobile phone worked example illustrates the feasibility of the algorithm.

The volume, variety and velocity of products in software-intensive systems product lines is increasing. One challenge is to understand the range of similarity between products. Reasons for product comparison include (i) to decide whether to build a new product or not (ii) to evaluate how products of the same type differ for strategic positioning or branding reasons (iii) to gauge if a product line needs to be reorganized (iv) to assess if a product falls within the national legislative and regulatory boundaries. We will discuss two different approaches to address this challenge. One is grounded in feature modelling, the other in case-based reasoning. We will also describe a specific product comparison process in which a product configured from a product line feature model is represented as a weighted binary string, the overall similarity between products is compared using a binary string metric, and the significance of individual feature combinations for product similarity can be explored by modifying the weights. We will illustrate our ideas with a mobile phone example, and discuss some of the benefits and limitations of this approach.

Surface cracks are a common sight on public infrastructure nowadays. Recent work has been addressing this problem by supporting structural maintenance measures using machine learning methods. Those methods are used to segment surface cracks from their background, making them easier to localize. However, a common issue is that to create a well-functioning algorithm, the training data needs to have detailed annotations of pixels that belong to cracks. Our work proposes a weakly supervised approach that leverages a CNN classifier in a novel way to create surface crack pseudo labels. First, we use the classifier to create a rough crack localization map by using its class activation maps and a patch based classification approach and fuse this with a thresholding based approach to segment the mostly darker crack pixels. The classifier assists in suppressing noise from the background regions, which commonly are incorrectly highlighted as cracks by standard thresholding methods. Then, the pseudo labels can be used in an end-to-end approach when training a standard CNN for surface crack segmentation. Our method is shown to yield sufficiently accurate pseudo labels. Those labels, incorporated into segmentation CNN training using multiple recent crack segmentation architectures, achieve comparable performance to fully supervised methods on four popular crack segmentation datasets.

This tutorial presents and compares two different approaches to requirements reuse. The first approach deals with requirements reuse and reusability using feature modelling. The second approach deals with requirements reuse and reusability in the context of case-based reasoning. Both approaches have different key properties and trade-offs between the costs of making software artefacts reusable and the benefits of reusing them. To aid large-scale development, we have proposed a Feature-Similarity Model, which draws on both approaches to facilitate discovering requirements relationships using similarity metrics. A FeatureSimilarity Model also helps with exploring stakeholder needs, since new requirements can be introduced first into a case base and then gradually included into a product line representation.

Conventional surface crack segmentation requires images manually labelled by a trained expert. It is a challenging task as cracks can vary in orientation and size, with some parts of cracks only being one pixel wide. Further, available training data for crack segmentation is sparse. In this work we propose to automate this annotation task, by introducing a fully convolutional U-Net based architecture for semantic segmentation of surface cracks which allows for the use of small datasets through a patch based training process. Our proposed configuration makes use of residual connections inside the convolutional blocks as well as including an attention based gating mechanism between the encoder and decoder section of this architecture, which only propagates relevant activations further. Using our proposed architecture we achieve new state of the art results in two different crack datasets, outperforming the previous best results in two metrics each.

Software reuse and reusability range from operational, ad-hoc and short-term to strategic, planned and long-term. Often the focus of attention is just on code or low-level design. This tutorial presents and compares two different requirements-led approaches. The first approach deals with requirements reuse and reusability using feature modelling. The second approach deals with requirements reuse and reusability in the context of case-based reasoning. Both approaches have different key properties and trade-offs between the costs of making software artefacts reusable and the benefits of reusing them. To aid large-scale development, we have proposed a Feature-Similarity Model, which draws on both approaches to facilitate discovering requirements relationships using similarity metrics. A Feature-Similarity Model also helps with the evolution of a product line, since new requirements can be introduced first into a case base and then gradually included into a product line representation.

Several socioeconomic trends are increasing personalised customer demands. Suppliers are responding with mass customisation but the management of large-scale cost-effective software reuse remains a difficult challenge. Software reuse and reusability range from operational, ad-hoc and short-term to strategic, planned and long-term. Often the focus of attention is just on code or low-level design. This tutorial presents and compares two different requirements-led approaches. The first approach deals with requirements reuse and reusability in the context of product line engineering. The second approach deals with requirements reuse and reusability in the context of case-based reasoning. Both approaches have different key properties and trade-offs between the costs of making software artefacts reusable and the benefits of reusing them. To aid large-scale development we have proposed a Feature-Similarity Model, which draws on both approaches to facilitate discovering requirements relationships using similarity metrics. A Feature-Similarity Model also helps with the evolution of a product line, since new requirements can be introduced first into a case base and then gradually included into a product line representation.

Several socio-economic trends are driving customer demands towards individualisation. Many suppliers are responding by offering supplier-led software product design customization choices ("mass customization"). Some are also offering customer-led software product design choices ("mass personalization"). This tutorial introduces these concepts and explores the implications for software product line development. One particular technical challenge is being able to respond to and manage at scale the increasing variety of common, supplier-led and customer-led features. We discuss two different approaches to address this challenge. One is grounded in feature modelling; the other in case-based reasoning. Both approaches aim to support the identification and selection of similar products. However they each place different emphases on these activities, use different product descriptions, and deploy different product derivation methods. Accordingly, each approach has different key properties, benefits and limitations.

Building energy management systems (BEMSs) monitor and control the heating ventilation and air conditioning (HVAC) of buildings in addition to many other building systems and utilities. Wireless sensor networks (WSNs) have become the integral part of BEMS at the initial implementation phase or latter when retro fitting is required to upgrade older buildings. WSN enabled BEMS, however, have several challenges which are managing data, controllers, actuators, intelligence, and power usage of wireless components (which might be battery powered). The wireless sensor nodes have limited processing power and memory for embedding intelligence in the sensor nodes. In this paper, we present a random neural network (RNN)-based smart controller on a Internet of Things (IoT) platform integrated with cloud processing for training the RNN which has been implemented and tested in an environment chamber. The IoT platform is modular and not limited to but has several sensors for measuring temperature, humidity, inlet air coming from the HVAC duct and PIR. The smart RNN controller has three main components: 1) base station; 2) sensor nodes; and 3) the cloud with embedded intelligence on each component for different tasks. This IoT platform is integrated with cloud processing for training the RNN. The RNN-based occupancy estimator is embedded in sensor node which estimates the number of occupants inside the room and sends this information to the base station. The base station is embedded with RNN models to control the HVAC on the basis of setpoints for heating and cooling. The HVAC of the environment chamber consumes 27.12% less energy with smart controller as compared to simple rule-based controllers. The occupancy estimation time is reduced by our proposed hybrid algorithm for occupancy estimation that combines RNN-based occupancy estimator with door sensor node (equipped with PIR and magnetic reed switch). The results show that accuracy of hybrid RNN occupancy estimator is 88%.

In this paper we present our work on the indoor positioning of users (shoppers), using a network of Bluetooth Low Energy (BLE) beacons deployed in a large wholesale shopping store. Our objective is to accurately determine which product sections a user is adjacent to while traversing the store, using RSSI readings from multiple beacons, measured asynchronously on a standard commercial mobile device. We further wish to leverage the store layout (which imposes natural constraints on the movement of users) and the physical configuration of the beacon network, to produce a robust and efficient solution. We introduce our node-graph model of user location, which is designed to represent the location layout. We also present our experimental work which includes an investigation of signal characteristics along and across aisles. We propose three methods of localization, using a “nearest-beacon” approach as a base-line; exponentially averaged weighted range estimates; and a particle-filter method based on the RSSI attenuation model and Gaussian-noise. Our results demonstrate that the particle filter method significantly out-performs the others. Scalability also makes this method ideal for applications run on mobile devices with more limited computational capabilities.

This tutorial compares two requirements-led approaches to strengthen product line engineering and case-based reasoning, and introduces the notion of a feature-similarity Model for combining these approaches.

For many organisations, choosing a reusable software strategy such as whether to be developing products, platforms or components, or some combination of these is not straightforward. The appropriateness of the choice can also change as an organisation's internal and external business environment context changes. In this paper we provide a management tool to help guide that decision making. We set out four broad types of business strategy and map these against four different types of reusable software development strategy. The four types of business strategy correspond to different business environments which are in turn characterised by different combinations of market predictability (low to high) and an organisation's ability to influence it (low to high). To demonstrate the framework as an analytical tool we have mapped examples of different organisations reusable software strategies and explained some circumstances in which that organisation's strategy may change.

In software product lines, feature development options can be categorized as make or buy or, a variation on buy, called reuse. In transaction economic cost theory a group of features is an asset and there is an increasing correlation between an asset's relative importance to a supplier and the decision to make rather than buy. In this paper we argue that the make or buy decision should also consider an asset's relative importance to the set of customers who buy the products containing the asset and we present a decision-making feature development framework that factors in feature relative importance to supplier and customer. To evaluate our framework we compared its recommendations with actual decisions made on three different industrial product lines. Our results showed broad consistency between framework guidance and actual practice, but revealed some instances not adequately explained by the framework.

This tutorial explores how the prudent use of a set of requirements variability management techniques can ensure the alignment of a product line business strategy and the corresponding product platform development strategy.

Requirements are traditionally viewed as being free of the details of an envisioned solution and specified using purely problem domain entities. Preventing premature design in the requirements permits the available design space not to be restricted too early which might inhibit innovative designs. In practice, on many industrial projects, separating the problem and solution domain entities can be difficult, and arguably there are benefits for not doing so. Many customers feel more confident describing their requirements, often as the difference between the existing products and their needs, some customers have such intimate knowledge of their products that their requirements tend to be very specific, and if the customer knows the exact solution needed thatnaturally will reduce the cost of the requirements elicitation as well as design activities. Practitioners are challenged to understand when having solution information in requirements is sensible and when it should be avoided. In this research challenge paper, we advocate that researchers should identify differentcontexts and corresponding criteria that practitioners can use to evaluate when requirements specifications may include design information. To understand the research challenge we present experiences from real projects and suggest possible factors that affect when design information may be viable in requirements specifications.

In the consumer product market space a commercial challenge is to offer personalization of products and services for individual customers at a mass production price. One solution is the development of a software product line platform comprising a set of products that have similar functions, behaviours and properties but with sufficient variability to capture customer differences. However as a product line evolves, customer requirements change and new products are added to the product line, software producers realize the platform cannot be "stretched" indefinitely. The central problem is striking a balance between development efficiency through increasing platform commonality and customer dissatisfaction with products that have unwanted features/properties. The introduction of multiple product lines may be a better alternative. In practice, achieving the balance is a compromise between satisfying customers' requirements, minimising the costs of changes to the product line platform, and a vendor's mission, capability and capacity. This tutorial will explore the broader challenges of product line evolution but focus on platform management through describing techniques for mapping changing variability between product line requirements and a product line platform architecture, and describe the contexts for deploying multiple product lines as an alternative.

In the consumer product market space a commercial challenge is to offer personalization of products and services for individual customers at a mass production price. Product line evolution is a compromise between a vendor's commercial objectives, the existing product line design, the vendor's structure and culture, and customers' requirements. Within this context, this tutorial will describe the alignment of business and technical strategies and present a range of techniques for managing this alignment. After this tutorial the participant will be able to:

Many approaches to software product line engineering have been founded on the development of a single product line platform. However as customer requirements change and new products are added to the product line, software producers recognize that the platform cannot be "stretched" indefinitely and a significant problem is striking a balance between development efficiency by increasing platform commonality and customer dissatisfaction from products with additional undesirable features and properties.

To leverage the explicit and extensive use of shared software artifacts, many companies use a product line approach to build different variants of their products for use within a variety of systems. Product lines can be large and could easily incorporate thousands of elements together with relationships between those elements. This makes product line management and systematic product derivation extremely difficult.

Call routing is a vital technique required to achieve a functioning virtual call centre (VCC). Several algorithms have been proposed to support call routing for VCCs over the past few years. When proposing a new call routing algorithm, it is critical to determine its precise scope and evaluate it with accurate modelling of the underlying protocols and communication mechanisms. However, there has been comparatively little activity in the area of performance comparison of call routing algorithms for VCCs. This paper addresses this issue by developing a working virtual call centre model to act as a test bed for each routing algorithm. Three well-known call routing algorithms, namely JSQ, MED and GRR, have been considered in this study. Our simulation results show that the MED routing algorithm outperforms other call routing algorithms. Moreover, we identify a direct relationship between the different performances metrics used in the comparison.

A software product line is a set of software-intensive systems sharing a common set of managed requirements. A technique for requirements analysis of single systems, but rarely applied to product lines, is problem frames. Problem frame theory omits support for the management and exploitation of product line requirements variability. This paper presents some notation to support requirements and machine variability in problem frames. It also describes some transitioning rules between requirements and machines that can help to manage product line evolution. We illustrate our ideas using a mobile phone worked example.

Software product line development is a compromise between customer requirements, existing product line architectural constraints and commercial needs. Managing variability is the key to a successful product line development. Product line models of requirements and features can be constructed that contain variation points. New products can be driven by making requirement selections from a product line model of requirements but as the product line evolves selections are constrained by the design of the existing product line architecture and the cost of making these changes. We present a set of rules that map the selection constraint values of requirements to the selection constraint values of features which in turn map on to the selection constraint values of architectural assets. We illustrate the application of the rules using a worked example.

Reuse and requirements are very important for efficient and successful systems development. This tutorial presents the experiences of requirements reuse using a Method for Requirements Authoring and Management (MRAM). MRAM is a method for establishing and selecting from product line requirements. A product line is a group of products within the same market segment e.g. mobile phones. TRAM (Tool for Requirements Authoring and Management) is a software tool to support MRAM that utilises current proven office technology (MS-Word, MS-Access). The tutorial presents the results of MRAM/TRAM as it has been applied to product line engineering of a real-world application.

Reuse and requirements engineering are very important for efficient and successful systems development. However there are many open issues for performing them well in practice, especially raise of requirements. We present a new approach to reusing requirements based on application families i.e. several systems in a given problem domain. In contrast to precious approaches, an application family model in our approach consists of a pool of requirements (linked in a lattice structure), a domain model and a set of discriminants (a special kind of requirement that differentiate one system from another). We focus on how to make an efficient and clean selection of the requirements for a new system from an application family model. We have developed a method for solving this problem and a prototypical tool for supporting it. The method and the prototype were successfully developed under a study contract for ESA (European Space Agency). We present a case study, where we generated commanding requirements for an individual mission from an application family model of commanding requirements for spacecraft control operating systems. As a consequence, we propose this approach for reusing requirements based an application families.