Product Line Stakeholder Preference Elicitation via Decision Processes

Product Line Stakeholder Preference Elicitation via Decision Processes

Mahdi Bashari (University of New Brunswick, Fredericton, Canada), Mahdi Noorian (University of New Brunswick, Fredericton, Canada) and Ebrahim Bagheri (Department of Electrical and Computer Engineering, Ryerson University, Toronto, Canada)
Copyright: © 2014 |Pages: 17
DOI: 10.4018/ijkss.2014100103
OnDemand PDF Download:


In the software product line configuration process, certain features are selected based on the stakeholders' needs and preferences regarding the available functional and quality properties. This book chapter presents how a product configuration can be modeled as a decision process and how an optimal strategy representing the stakeholders' desirable configuration can be found. In the decision process model of product configuration, the product is configured by making decisions at a number of decision points. The decisions at each of these decision points contribute to functional and quality attributes of the final product. In order to find an optimal strategy for the decision process, a utility-based approach can be adopted, through which, the strategy with the highest utility is selected as the optimal strategy. In order to define utility for each strategy, a multi-attribute utility function is defined over functional and quality properties of a configured product and a utility elicitation process is then introduced for finding this utility function. The utility elicitation process works based on asking gamble queries over functional and quality requirement from the stakeholder. Using this utility function, the optimal strategy and therefore optimal product configuration is determined.
Article Preview


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.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 8: 4 Issues (2017): 3 Released, 1 Forthcoming
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing