Article Preview
TopIntroduction
In software development like any other industry, the economic value of a product and the efficiency of the production process are important. The idea of product line engineering in software development comes from a similar approach that has been used in other industries. Software product lines can be used for industrialization of the software development process by conducting mass production and mass customization at the same time (Pohl, Bockle, & Van Der Linden, 2005). The main idea behind software product line engineering is to develop reusable assets for a family of products and reuse them to build products of that family instead of developing them from scratch. The economic consideration is one of the main reasons that companies are interested to embark on the software product line approach. Due to the large scale reuse during the development process supported by software product line engineering, this approach allows improvements in software quality, time to market, and cost reduction (Pohl et al., 2005).
The software product line approach consists of two main development lifecycles, namely domain engineering and application engineering (Kang et al., 1998; Pohl et al., 2005). Domain engineering involves analyzing and modeling the target domain as a whole and producing a set of reusable core assets. On the other hand, application engineering involves developing a domain-specific software product by selecting and customizing a number of artefacts that are developed in the domain engineering phase based on the stakeholders’ needs. In application engineering, the process of selecting the right set of assets from a software product line and developing a target software product is referred to as product configuration (van der Linden, Frank J, Schmid, & Rommes, 2007).
One of the important concerns in product configuration is business concerns (e.g. customer satisfaction) and quality attributes (e.g. performance) (Soltani, Asadi, Gašević, Hatala, & Bagheri, 2012) which are referred to as non-functional properties (NFPs). In product configuration, stakeholders’ non-functional as well as functional requirements should be considered in order to configure a customized product. A number of product configuration methods have been proposed which work on stakeholders’ functional and non-functional requirement (Czarnecki, Helsen, & Eisenecker, 2004; Guo, White, Wang, Li, & Wang, 2011; Mendonca, Wasowski, Czarnecki, & Cowan, 2008; Siegmund et al., 2012; White, Dougherty, Schmidt, & Benavides, 2009; White, Dougherty, & Schmidt, 2009). These methods mostly receive these requirements as input constraints and develop a configuration that satisfies those constraints. These approaches assume that these requirements are known and available. This is not always the case because the stakeholder may have conflicting functional and non-functional needs and most of the time finding the best trade-off for those requirement might not be very easy (Bagheri, Asadi, Gasevic, & Soltani, 2010; Bass, Clements, & Kazman, 2003).
Utility theory (Marshall, 1920; Neumann & Morgenstern, 1947) has been widely used to model decision makers’ preferences. The model of utility is used for supporting decision making. The preference model is identified by interacting with the user in a process named utility elicitation (Chajewska, Koller, & Parr, 2000). The decision makers’ utility model is usually modeled as a utility function over attributes of importance for decision making. The utility function is then used to find relative preference to rank different alternatives in a decision making problem.