Informed decision-making in prioritising product variants

Introduction

In today’s software industry, variability models are used to compactly represent all product variants of a software product line (SPL) in terms of features (Benavides, Segura & Cortés, 2010). An SPL integrates similar software products with features in common, but not all of them. Feature models (FM) are a type of variability model that allows compacting of the variability representation of a family of products (Metzger & Pohl, 2014). The use of FMs is widespread and several studies and tools support their management and analysis (Horcas, Pinto & Fuentes, 2023; Varela-Vaca et al., 2019). One of the main functionalities of these tools is their capacity for automatic reasoning and the generation of a set of partial or complete configurations from a specified model.

A product variant can be represented by a product configuration, which includes the selection of features for an FM. The vast number of possible product configurations poses a significant challenge: how to efficiently identify and prioritise the configurations that best meet user requirements (Fernández-Amorós et al., 2024). While FMs provide a compact representation of these configurations, the sheer volume of potential options can overwhelm decision-makers. This complexity highlights the need for systematic methods that can assist in ranking configurations based on multiple criteria, ensuring that the most suitable product variants are selected. For example, a car manufacturer’s product line (Astesana, Cosserat & Fargier, 2010) can potentially include an exponential number of configurations, influenced by features such as colour, engine type, Bluetooth capability, and navigation technology. However, it should be noted that not all configurations are supported, for example, the inclusion of the navigation system but not that of Bluetooth. In addition, it may be unfair to present all possible configurations and analysing them would be pointless, time consuming and costly. It would be better to present a subset of configurations that meet the user’s needs, for example those that prioritise fuel economy over boot space. Consequently, the prioritisation of a subset of configurations based on user-defined criteria becomes imperative to facilitate streamlined decision-making processes.

Designing a specific product within a product line involves optimising the selection of features to identify the ‘best’ product. Product configuration prioritisation offers significant benefits, such as efficiency in decision-making by streamlining the selection process, optimisation of resources by focusing on high-potential options, and reduction of uncertainty by avoiding less promising configurations. It also enables strategic alignment with organisational goals, continuous improvement by identifying areas for improvement, and effective risk management by proactively addressing configurations with significant risks. Clear rankings also facilitate communication and collaboration, contributing to quality improvement in various areas such as software development, engineering, research, and design.

Determining the best set of features becomes a multi-objective optimisation problem (Henard et al., 2015). Multi-criteria decision-making (MCDM) (Ishizaka & Nemery, 2013) is a mature field that has been applied in several contexts and can be applied in this context of product configuration. In Saber, Bendechache & Ventresque (2021), the multi-objective problem was analysed by incorporating MDCM into SPL. However, different ordered lists can be obtained for the same feature model and criteria, depending on the MCDM applied. This variation gives rise to a critical challenge: the process of resolving discrepancies in the rankings produced by different MCDM methods and determining which configuration best suits the user’s preferences. There is currently no systematic framework that integrates multiple MCDM methods to prioritise configurations derived from feature models.

The need to merge the results obtained by MCDMs is a problem that does not only exist in the context of SPL (Egan, 2024). For example, in companies and organisations, it is often difficult to bring together the prioritisation criteria of all stakeholders in decision-making meetings, which can lead to low productivity or even failure to produce the best products. The main research questions to be addressed are What is the best decision if various MCDM methods obtain different rankings, and how do the specific features of the FM play a role in the decision?

To address these challenges, this article proposes a novel framework that systematically integrates multiple MCDM methods—analytic hierarchy process (AHP) (Saaty, 1990), technique for order of preference by similarity to ideal solution (TOPSIS) (Hwang & Yoon, 1981), and multicriteria optimization and compromise solution (VIKOR) (Opricovic & Tzeng, 2007)—for the prioritisation of configurations derived from feature models. The framework not only automates the prioritisation process but also provides a methodical approach to resolving discrepancies between the rankings generated by different MCDM techniques. By offering informed decision support, the framework enhances transparency, improves trust in the selection process, and facilitates reproducibility.

The integration of multiple MCDM methods into FM prioritisation addresses a critical gap in the field of SPLs. By systematically reconciling discrepancies between different ranking methods, this approach enhances decision-making transparency and reliability. Beyond SPLs, the proposed framework has the potential to be applied in various domains where complex configurations and multi-criteria decisions are required, such as cloud service selection, IoT system configuration, and embedded systems design. From a pragmatic standpoint, the automation of the prioritisation process has the potential to reduce the time and effort required from experts, streamline product development workflows, and ensure that configurations are aligned with user-defined priorities. This, in turn, leads to more efficient resource allocation, better product quality, and increased confidence in decision-making processes across diverse software and engineering environments.

The general idea of this article is represented in Fig. 1, and the main contributions are:

• A novel framework that automates the prioritisation of configurations obtained from feature models by integrating multiple MCDM methods.

• A systematic approach for analysing and resolving ranking discrepancies, providing informed decision support to guide users in selecting the most appropriate configuration.

• An evaluation of the framework through real-world case studies, with a view to demonstrating its applicability, robustness, and scalability in handling complex feature models.

This article is divided into the following sections. “Foundations” introduces the concept of Feature Model and presents some decision-making techniques. “Proposed methodology for applying MCDM methods” introduces the proposed methodology for the application of MCDM methods and presents the different phases of the process. “Detailed Application of AHP, TOPSIS, and VIKOR” provides a detailed explanation of the configuration and application phases for AHP, TOPSIS, and VIKOR. “Informed Decisions: In-Depth Examination of Ranking Discrepancies” details the phase focused on supporting informed decision-making when discrepancies are observed between the rankings obtained by the different techniques. The whole process is applied to a real example and is outlined in “Results”. “Discussion” discusses the implications, strengths, and limitations of the proposed approach, including its scalability, reliance on expert input, and potential enhancements through automated techniques or alternative decision-making frameworks. “Related Work” analyses related works in the literature. Finally, “Conclusions and Future Work” concludes the article and presents ideas for future work.

Foundations

This section briefly introduces FMs and their use to represent SPLs. Likewise, some MCDM methods are briefly presented.

Feature models

SPLs (Clements, 2001; Becker et al., 2001) represent a set of products that share common features, with the objective of facilitating the creation of products based on user requirements. They can be described using models, where one of the main notations for expressing these models is the Feature Model (FM) notation (Schobbens et al., 2007), which describes the set of properties in an SPL in terms of features and the relationships between them. A FM represents the features of a product and the configuration options for each of them in tree form. An example of how FMs are usually represented is shown in Fig. 2.

Features are related through dependencies; these can be mandatory, optional, group cardinality, inclusion, or exclusion. Each of these is explained below:

• Mandatory. When this relationship is established between two features (child and parent respectively) of a model, the child feature must be selected when the parent feature is selected in a configuration. In the example, it is used to relate the features Mobile Phone and Calls.

• Optional. This relationship is established between parent and child features and indicates that the occurrence of the parent feature in a configuration does not imply that the child feature must also occur. In the example feature model, it is used to relate the Mobile Phone and GPS features.

• Or-relationship. When this relationship is established between a parent feature and its set of child features, when the parent feature is selected in a configuration, one or more of its children must be selected. In the example feature model, it is used to relate feature Media and its configuration options Camera and MP3.

• Alternative. When this relationship is established between a parent feature and its set of child features, when the parent feature is selected in a configuration, one and only one of its children must be selected. In the example feature model, it is used to relate feature Screen and its configuration options Basic, Colour and High Resolution.

• Requires. If a feature X requires another feature Y, then when X is selected in a configuration, Y must also be selected. In the example feature model, it is used to restrict features Camera and High Resolution.

• Excludes. If a feature X excludes another feature Y, then when X is selected in a configuration, Y cannot be selected. In the example feature model, it is used to restrict features GPS and Basic.

A concrete product variant of the feature model is derived through a configuration process: binding the variation points and instantiating the different features of the model. For the feature mode above, some of the possible configurations of a mobile phone could be {Calls, Screen, Basic, GPS}, {Calls, Screen, Colour, Media, Camera}, and so on. As mentioned previously, these configurations could be sorted according to certain criteria.

Proposed methodology for applying MCDM methods

To formalise the configuration prioritisation process, we define a prioritisation problem and an informed decision-making problem. The former is the task of obtaining the configuration rankings by applying MCDM methods, while the latter is the task of interpreting the discrepancies in the rankings to help the expert make a comprehensible decision. For the application of MCDM methods in the context of FM, we propose the methodology described in Fig. 3. This process consists of the following four phases:

• (1)

  Phase 1: Inputs and model generation. From the feature model, (1) the expert determines the features to be considered as criteria and instances in the prioritisation process, and (2) all valid configurations are obtained (using an external tool). All these elements are inputs to our prioritisation process.

• (2)

  Phase 2: Preference setting. Based on the features identified as criteria in the previous phase, the expert introduces the pairwise information that will determine the most relevant features.

• (3)

  Phase 3: Application of MCDM methods. In this phase, MCDM methods are applied, in our case study these are AHP, TOPSIS and VIKOR.

• (4)

  Phase 4: Resolving discrepancies in the rankings. This phase is responsible for helping the user to interpret the possible differences between the ranks obtained.

To make the proposal clearer and more formal, the following subsections explain each phase in detail as applied to a particular FM.

Phase 1. Inputs and model generation

As mentioned above, the parameters needed to start the process are the FM, a selection of features to be used as criteria in the prioritisation process, and the set of valid configurations according to the FM.

FM

To facilitate the explanation of the proposal, we use an illustrative example related to the field of cybersecurity, taken from the contribution in Varela-Vaca et al. (2019). It is based on the security feature model of an Apache Tomcat server, which represents the attributes required to configure an HTTP connector with SSL support, as shown in Fig. 4. The model consists of 27 features, 10 mandatory relations, three optional relations, one or-alternative relations, three alternative relations, one require and one exclude constraints.

Features involved in the prioritisation

In the context of MCDM, the expert plays a crucial role in mapping the feature model to the specific configurations and criteria. Although a configuration may contain many features, not all of them need to be involved in the prioritisation process, only those identified by the expert. Thus, the mapping process starts with the expert’s selection of the features to be considered as prioritisation criteria. This step discriminates the features that influence whether a configuration is considered better or worse concerning the defined prioritisation objective. Similarly, it must be determined which features (leaves of the model) are possible values that each criterion can take, i.e., its instances.

• •

  Let C be the subset of internal FM nodes (features) considered as criteria for evaluating and comparing alternatives. (1) $$C\subset F$$

• For the Apache example, the criteria identified by the expert are ClientAuth, KeyStore, Trust, and Protocol features.

• •

  Let I be the subset of FM leaf nodes (features) that the expert considers to be instances of C, i.e., the values that the criteria can take. (2) $$I\subset F$$

• For the Apache example, the enabled instances of each criterion are:

  • –

    ClientAuth: true, want, or false.

  • –

    KeyStore: JKS, PKCS12, or PKCS11.

  • –

    Trust: JKS, PKCS12, or PKCS11.

  • –

    Protocol: v1, v1.1, v1.2, and/or v1.3.

Valid configurations

Several configurations can be obtained, but not all of them are valid. That is, some configurations do not satisfy the constraints and relationships imposed by the model. Therefore, only valid configurations need to be considered. A valid configuration is a selection of features that satisfy all constraints and conditions in the FM.

• •

  Let VC be all valid configurations for the given FM. Each configuration $vc\in VC$ is characterised by the selection of a set of features $f$, where $f\subset F$.

For the Apache example and using CyberSPL (Varela-Vaca et al., 2019), the possible configurations of the feature model are $576$. Among all of them, a subset of 10 configurations of VC is shown in Table 1¹ . These 10 are used as illustrative examples, but others could be chosen. However, as will be shown later in the application of decision-making techniques, the number of configurations to be prioritised does not significantly affect the performance of the prioritisation process.

Table 1:

Selected configurations for Apache.

Config. No.	Apache product configuration
1	Apache–Algorithm–Ciphers–ClientAuth–true–Port–KeyStore–K_Type–K_JKS–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_PKCS11–Protocol–TLSv1_1
2	Apache–Algorithm–ClientAuth–true–Port–KeyStore–K_Type–K_PKCS11–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_PKCS12–Protocol–TLSv1_3
3	Apache–Ciphers–ClientAuth–true–Port–KeyStore–K_Type–K_PKCS12–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_JKS–Protocol–TLSv1_2
4	Apache–Algorithm–Ciphers–ClientAuth–want–Port–KeyStore–K_Type–K_PKCS11–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_PKCS12–Protocol–TLSv1_2
5	Apache–Algorithm–ClientAuth–want–Port–KeyStore–K_Type–K_PKCS12–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_JKS–Protocol–TLSv1_1
6	Apache–Ciphers–ClientAuth–want–Port–KeyStore–K_Type–K_PKCS12–K_Pass–K_File–Trust–T_File–T_Pass–T_Type–T_PKCS11–Protocol–TLSv1_2–TLSv1_3
7	Apache–Algorithm–Ciphers–ClientAuth–false–Port–KeyStore–K_Type–K_JKS–K_Pass–K_File–Protocol–TLSv1_2
8	Apache–Algorithm–ClientAuth–false–Port–KeyStore–K_Type–K_PKCS12–K_Pass–K_File–Protocol–TLSv1_3
9	Apache–Ciphers–ClientAuth–false–Port–KeyStore–K_Type–K_PKCS11–K_Pass–K_File–Protocol–TLSv1_1
10	Apache–Algorithm–Ciphers–ClientAuth–want–Port–KeyStore–K_Type–K_PKCS12–K_Pass–K_File–Protocol–TLSv1_3

DOI: 10.7717/peerj-cs.2778/table-1

Detailed application of AHP, TOPSIS, and VIKOR

In this section, we provide a detailed analysis of the methods used in Phases 2 and 3 to prioritise the valid configurations. Phase 2 focuses on setting preferences through pairwise comparison matrices, while Phase 3 details the application of each method to compute the final rankings. Each method is examined in its own subsection, where we outline the process, inputs, and resulting rankings.

Informed decisions: in-depth examination of ranking discrepancies

When there are discrepancies between the rankings generated by different MCDM techniques, it becomes essential to provide the user with a systematic approach to selecting the most appropriate configuration. In this phase, our goal is to support informed decision-making by analysing configurations that occupy similar or identical positions in the rankings, identifying key differences and similarities between them, and presenting this information in a manner that assists the user in making a choice.

It is important to acknowledge that the attainment of disparate rankings may be attributable to the weighting assigned to the criteria in the various techniques (obtained in AHP from the comparisons and established for TOPSIS and VIKOR), which may differ and result in analogous yet non-identical solutions. For the Apache example, the weights obtained by AHP for ClientAuth, Trust, Protocol and KeyStore are 37.01%, 34.51%, 18.50% and 9.99% respectively. For VIKOR and TOPSIS the established weights are 35%, 30%, 20%, and 15%. Despite the utilisation of identical weights by VIKOR and TOPSIS, the attainment of disparate rankings remains a possibility, as articulated in the work by Shekhovtsov & Salabun (2020).

The process of analysing discrepancies is divided into three key steps:

1. Identifying configurations with ranking discrepancies

The initial step is to identify configurations that are similarly ranked by different MCDM methods, yet differ in specific criteria or instances. For example, Table 12 shows configurations ranked by AHP, TOPSIS, and VIKOR. In this example, the configurations ranked #4, #5, and #6 show notable discrepancies, making them candidates for deeper analysis.

2. Analysing criteria and instances

We then focus on the specific criteria that influence the discrepancies in these rankings. By examining the feature model and analysing the instances of criteria within each configuration, patterns or trade-offs can be identified. For example, while Apache Config. No. 1 may prioritise certain features (e.g., ClientAuth), Apache Config. No. 5 and 6 may prioritise others (e.g., Trust or Protocol). The disparities in feature prioritisation and their repercussions on the aggregate ranking are emphasised to assist the user in evaluating their options based on their particular preferences.

However, as shown in Fig. 5, the visual representation of features in configurations does not invariably facilitate straightforward decision-making, as mandatory features and specific feature constraints (e.g., XOR relations) can impede interpretation.

3. Generating an informed decision-making support table.

To provide a more systematic and comprehensible approach, we propose to represent the criteria and instances in a structured decision support table. This table organises the configurations based on the values assigned to each criterion and the deviations from optimal values (according to the user-defined preferences) as presented in Table 13. These deviations are calculated as percentages based on the numerical scales predefined by the expert for each criterion (within the preferences P in the global process). For example, the expert may assign a numerical value of 2 to true, 1 to want, and 0 to false for the criterion ClientAuth. These values reflect the expert’s priorities, and the percentage deviation indicates how far each configuration is from the optimal value (the one with the highest assigned number).

Each configuration is assigned a score based on a percentage scale and the overall deviation is calculated as the average of the individual deviations across all criteria. This overall metric provides a clear representation of how close or far each configuration is from meeting the expert’s objectives. A more detailed discussion of the robustness and justification of the overall deviation metric is provided in “Robustness and Justification of the Overall Deviation Metric”.

As demonstrated in the table, Apache Config. No. 1 optimises ClientAuth, yet assigns a lower priority to Trust and Protocol. In contrast, Apache Config. No. 5 and 6 offer a balanced trade-off. The percentage deviation for each criterion reflects the configuration’s deviation from the expert’s preferred option. For example, in the case of Protocol, Apache Config. No. 1 deviates by 66% (using version 1.1), whilst Apache Config. No. 6 deviates by a much smaller percentage of 16% (with versions 1.2 & 1.3).

In terms of Overall deviation, Apache Config. No. 1 has 54%, indicating a greater misalignment with the expert’s priorities compared to Apache Config. No. 5 and 6, which have lower overall deviations of 41.5%. However, the specific criteria deviations reveal additional trade-offs. Specifically, Apache Config. No. 1 excels in ClientAuth but performs poorly in Trust and Protocol. In contrast, Apache Config. No. 5 and 6 exhibit more balanced deviations across the criteria.

By presenting the information in this manner, the expert is able to effortlessly compare configurations and balance the trade-offs according to the specific criteria that are most significant in the given context.

In summary, this section provides a systematic approach to addressing discrepancies in rankings generated by different MCDM methods. The process is broken down into three steps, ensuring that the expert has a clear and actionable understanding of the trade-offs involved. The incorporation of percentage deviations and the overall deviation metric provides a quantitative framework for the comparison of configurations, thereby highlighting their alignment with the expert’s preferences. This structured approach facilitates a more informed and confident decision-making process, even in scenarios involving conflicting rankings.

Results

To demonstrate the application and evaluation of the decision-making techniques presented in this work, we have applied them to a more complex example. Specifically, the SSL/TLS feature model is used, which is related to the field of cybersecurity and is based on the contribution of Varela-Vaca et al. (2019). This model represents the attributes required to configure certificates, keystores, ciphers, and key sizes for different versions of the SSL/TLS protocol, as shown in Fig. 6. The model consists of 48 features, including eight mandatory relations, two or-alternative relations, eight alternative relations, and four require and eight exclude constraints.

The evaluation process follows the four phases described in the proposal: (1) inputs and model generation, (2) preferences setting, (3) application of MCDM methods, and (4) resolution of rankings discrepancies. The application of these phases to the SSL/TLS feature model is detailed below.

Discussion

To the best of our knowledge, this is the first approach that applies multiple MCDM techniques to prioritize configurations derived from feature models. The existing tools focus on either feature selection or configuration analysis, but do not offer systematic prioritisation or reconciliation of discrepancies between different decision-making methods. This positions the present framework as a novel contribution to the field of feature model-based decision support.

Beyond its novelty, the framework has practical implications for industries and domains that rely on complex system configurations. By enabling systematic prioritisation, the approach ensures that configurations meet user-defined criteria, ultimately improving product quality and development efficiency. This has direct implications in areas such as cloud computing, IoT systems, embedded software design and more, where feature-rich products require careful selection of optimal configurations.

The results obtained from the application of the proposed MCDM-based configuration prioritisation methodology highlight several important findings and considerations. The methodology is effective in generating comprehensive rankings using AHP, TOPSIS and VIKOR, each of which brought unique perspectives to the prioritisation process.

The MCDM methods employed in this study offer distinct advantages, depending on the decision-making context. AHP is particularly beneficial when hierarchical structuring of criteria and pairwise comparisons are required, making it well-suited for cases where experts can systematically evaluate preferences. However, AHP may be less practical when the number of criteria or alternatives is very large, due to the increasing complexity of the pairwise comparisons. In contrast, TOPSIS is advantageous in scenarios where a clear distinction between the best and worst alternatives is essential, as it directly evaluates each alternative’s closeness to the ideal solution. However, its reliance on normalisation techniques means that its results can be influenced by the range of values assigned to criteria. In contrast, VIKOR is particularly useful when trade-offs between multiple criteria need to be explicitly considered, as it introduces a compromise ranking based on regret and satisfaction measures, making it suitable for scenarios where a balance between the best and worst cases is required. Given these differences, our approach benefits from combining these methods.

An important implication of this study is that applying different MCDM methods to the same problem can yield different results due to differences in how each technique weights and processes the criteria. This highlights the need for informed decision support tools, such as those proposed in Phase 4, to help experts understand and resolve these differences.

A key strength of this approach is its adaptability to different decision scenarios, including complex systems with intricate feature models. By systematically structuring criteria and alternatives, experts are provided with a clear path to prioritise configurations according to defined preferences. The integration of automated tools within the AMADEUS framework further enhances this process by simplifying implementation and ensuring reproducibility.

Despite these strengths, there are limitations. The reliance on expert input to define the criteria weights and interpret the results introduces a subjective element that can affect the consistency of the rankings. Similarly, although the methodology is scalable, the main complexity lies in the amount of input required from the expert. As more features are selected as criteria or instances, the expert must make more pairwise comparisons to establish preferences. However, once these preferences are established, applying the results to different configurations has minimal computational impact. To mitigate these limitations, future work could explore partial weighting strategies, where the expert provides only a subset of preferences and the system extrapolates the remaining ones. Additionally, incorporating automated preference learning techniques, such as leveraging historical data or machine learning models, could reduce the dependency on manual input and enhance the objectivity and scalability of the framework.

Another practical implication is the reduction in time and resources spent on the configuration process. By automating prioritisation and providing clear, accountable results, the framework helps organisations streamline product development cycles and improve collaboration between stakeholders. This promotes better alignment with strategic goals and facilitates the delivery of high quality, customised products.

A comparative analysis of our approach with other prioritisation methods in the literature shows that the proposed integration of decision support mechanisms is distinctive in its ability to resolve discrepancies and facilitate informed decision-making. This feature is particularly relevant in scenarios where configuration options are closely ranked in priority and require detailed investigation to determine the optimal choice.

In addition to SPLs, the framework can be adapted to other decision-making environments where complex configurations are essential. This includes adaptive systems, personalised software environments, and even hardware-software co-design scenarios, underscoring the versatility of the approach.

This discussion highlights the potential and applicability of the proposed methodology in a range of domains where configuration prioritisation is a key consideration. It provides a structured yet flexible approach that can be adapted to different expert needs and decision contexts.

Related work

Configuration prioritisation is an open problem in the SPL community. However, the concept of prioritisation has already been discussed in the field of feature modelling, although, to the best of our knowledge, not for the same purposes as our work. Related work has been distributed according to the following topics:

• 1.

  Optimisation and prioritisation of the configurations of the feature models. Incorporating user preferences into feature selection in SPL is not a new problem. Saber, Bendechache & Ventresque (2021) presents a solution based on a genetic algorithm to find the optimal configuration according to a multi-objective function. However, the definition of the criteria for sorting the configurations is not supported.

  Contributions such as Bertsimas & Mišić (2019) facilitate the selection of product configuration to maximise profit based on preferences, which is known as the product line design (PLD) problem.

  The approach in Guo et al. (2019) proposes a hybrid multi-objective optimisation algorithm using the indicator-based evolutionary algorithm (IBEA) with satisfiability modulo theories (SMT) to solve.

  Furthermore, Nguyen et al. (2019) provide a prioritisation technique for configurable systems by ranking the configurations according to their total number of potential bugs.

  The contribution of Sánchez & Segura (2017) presents SmarTest, a test prioritisation tool to speed up the detection of bugs in the Drupal web content management framework. It allows the execution of tests based on the real data of the Drupal product undergoing evaluation and the selection of the tests to be executed in the established order.

  In the approach of Sánchez, Segura & Ruiz-Cortés (2014), the applicability of test case prioritisation techniques to the evaluation of Software Product Lines (SPL) is explored. The article proposes five different prioritisation criteria based on common feature model metrics and compares their effectiveness in increasing the early fault detection rate, which measures how quickly faults are detected.

  Recent studies in multi-objective optimisation for SPLs, such as Jamil et al. (2023), Marghny et al. (2022), Abbas, Siddiqui & Lee (2016), highlight the increasing use of sophisticated heuristics and hybrid techniques to improve configuration selection. However, these works primarily focus on optimising performance rather than incorporating structured multi-criteria decision-making approaches as proposed in our work.

• 2.

  Application of multi-criteria decision-making to software product line. MCDM is not new in the context of SPLs, the approach in Thurimella & Ramaswamy (2012) proposed a hybrid quantitative and qualitative method based on Issue-based Variability Management (IVM). However, the proposal does not sort every possible configuration obtained, it is focussed on assigning prioritisation in each variation point, but not sorting all the products obtained.

  Beyond the SPL domain, decision-making frameworks have been widely applied across numerous fields, reflecting their adaptability and continuous evolution. Recent studies highlight their use in diverse areas such as renewable energy systems (Mukelabai, Barbour & Blanchard, 2024), transportation planning (Kriswardhana et al., 2025), recommender systems (Anwar et al., 2025), and AI-based managerial decision support (Marocco, Barbieri & Talamo, 2024). These works illustrate how decision-making approaches, including MCDM techniques, help structure complex decisions, balance multiple criteria, and enhance strategic planning. Despite this broad applicability, no prior research has systematically integrated multiple MCDM methods to resolve ranking discrepancies in feature model configurations, making our contribution distinct within the SPL context.

  Previous works have explored the use of decision-making frameworks in SPLs (Cao et al., 2024; Farshidi et al., 2018; Zaidan et al., 2015), but they do not integrate multiple MCDM methods to resolve discrepancies among rankings.

• 3.

  Comparative analysis of the different rankings obtained through MCDM. In the contribution by Shekhovtsov & Sałabun (2020), the ranking similarity obtained by VIKOR and TOPSIS is analysed using three ranking similarity coefficients. The comparison results of the conducted simulations are represented as boxplots.

  Yadav, Goraya & Singh (2021) evaluates AHP, PROMETHEE II, TOPSIS, and VIKOR in cloud environments for service selection. The comparative analysis includes differences and similarities in rankings, application-specific analysis, sensitivity analysis, and ranking overhead.

  Although PROMETHEE and ELECTRE are well-known MCDM techniques (Azhar, Radzi & Ahmad, 2021; Behzadian et al., 2010), they have not been included in our study as they were not among the selected methods for this work. Nevertheless, future studies may explore their integration into feature model prioritisation.

• 4.

  Integration of fuzzy logic in MCDM methods. Fuzzy-based MCDM approaches have been gaining relevance in recent years to handle uncertainty in decision-making scenarios. In particular, extensions like hesitant fuzzy sets, bipolar fuzzy sets, and linear Diophantine fuzzy sets (Aslam et al., 2024; Mahmood et al., 2022; Panpho & Yiarayong, 2023 Kahraman, Cebeci & Ruan, 2004) have been applied to complex prioritisation problems. While our approach does not incorporate these methods, future extensions could explore their applicability in handling ambiguous or conflicting expert preferences.

Related to the solutions that support the automatic reasoning of configurations, there are several tools, such as Flama (https://flamapy.github.io/), FeatureIDE (https://www.featureide.de/), SPL-Conqueror (https://www.se.cs.uni-saarland.de/projects/splconqueror/), SPLOT (http://splot-research.org/) and FAMILIAR (https://familiar-project.github.io/). Unfortunately, none of them provide the possibility to define a prioritisation criterion to obtain the possible configurations based on it, let alone to decide between different ranking lists of configurations.

Conclusions and future work

This study has introduced a methodology for the prioritisation of configurations obtained from feature models (FMs) using MCDM techniques, specifically AHP, TOPSIS, and VIKOR. The increasing complexity of modern SPLs, where feature models can generate thousands of valid configurations, necessitates the selection of the most suitable configuration based on user preferences, which is a critical challenge.

The principal contribution of this work lies in the implementation of MCDM methodologies for configuration prioritisation, in addition to the introduction of a systematic approach for the management of discrepancies between rankings generated by disparate techniques. The proposed framework offers a structured decision-support mechanism that allows experts to analyse trade-offs between configurations and make informed selections. While MCDM methods have been individually applied in other decision-making contexts, the present study demonstrates the benefits of integrating multiple techniques to enhance decision reliability in feature-based configuration problems.

Furthermore, we have implemented this approach in an available framework, allowing practitioners to apply our methodology in real-world application domains. The methodology has been validated with two complex feature models published in the literature, demonstrating its practical feasibility and robustness. The results show that different MCDM methods, despite being based on the same expert-defined preferences, can lead to different rankings, reinforcing the importance of an informed decision-making phase to reconcile discrepancies.

Despite the achievements of this work, several directions could be explored in future research. For example: (1) expanding the methodology through the incorporation of additional MCDM techniques or hybrid approaches, to enhance ranking consistency and accuracy; (2) developing enhanced visualisation techniques to facilitate more effective communication of discrepancies between rankings, thereby enabling users to gain a more profound understanding of the prioritisation results; (3) testing the framework in broader application domains, such as IoT systems or cloud-based environments, to assess its scalability and adaptability to different contexts; (4) exploring advanced automation strategies, such as machine learning-based preference learning, to reduce the manual effort required in expert-driven weighting processes; (5) the incorporation of more advanced mathematical frameworks for handling uncertainty in decision-making, such as hesitant bipolar complex fuzzy sets (Aslam et al., 2024; Mahmood et al., 2022). These approaches have the potential to facilitate a more detailed representation of expert preferences, particularly in cases where decision-makers express reluctance or divergent priorities. The integration of such models with MCDM methods has the potential to yield further insights and enhance the robustness of prioritisation in complex feature models; and (6) conducting empirical evaluations with large-scale feature models and real-world datasets to assess the efficiency and usability of the framework in practical industrial scenarios. This would involve benchmarking the framework against other prioritisation tools and decision-making approaches to provide a quantitative assessment of its advantages and limitations.

By addressing these challenges, future work can further enhance the applicability and impact of the proposed methodology, ensuring that prioritisation in feature-based configuration remains both rigorous and user-friendly.