## 3 Related Work  
Several secondary studies have been published on managing variability in SPL [17; 28; 29; 30]. However, no secondary studies have been reported for variability management in DSPL for self-adaptive systems, obtaining only one systematic mapping study related to DSPL [9] that will be discussed below. Next, we present a summary of five proposals related to managing variability in SPLs or DSPLs [9; 13; 31; 32; 33]. Table 3 shows the overlapping RQs for related work (\(\checkmark\): fully answered, \(\sim\): partially answered). For details on these related works (goals, RQs, and results), see the Appendix A. [PERSON] et al. [9] present an SMS on variability management in DSPLs, specifically on runtime variability modeling and configuration in DSPLs. The study was conducted between 2006 and 2015. The authors conclude that feature model are the primary approach to model variability in DSPLs, and most proposals do not refer to process configuration. Also, the authors declare that reconfiguration is triggered based on context, non-functional requirements, or user requirements through utility function or Constraint Satisfaction Problems (CSP). \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt}} \hline \hline
**Variability in SPL** & **Runtime Variability in DSPL** \\ \hline Activation/deactivation of system features prior to deployment. & Activation/deactivation of system features after deployment. \\ Adding and removing features in SPL design engineering. & Adding and removing features at runtime. \\ To make a change to the system variability, the product must be instantiated from the design engineering phase in SPL. & Provide optimal reconfiguration of the possible points of variation of the system. \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Differences between runtime variability for SPLs and DSPLs. \begin{table}
\begin{tabular}{p{142.3 pt} p{142.3 pt} p{142.3 pt} p{142.3 pt}} \hline \hline
**Ref.** & **RQ1** & **RQ2** & **RQ3** \\ \hline
[9] & \(\sim\) & & \\
[31] & & \(\sim\) & \\
[32] & & \(\checkmark\) & \\
[13] & & \(\sim\) & \\
[33] & & & \(\checkmark\) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Overlapping RQs for related work. [PERSON] et al. [31] present an SMS for SPLs interacting with IoT technologies, seeking to identify approaches that manage the variability required by cyber-physical systems as their requirements evolve. This study analyzes the architectures used for IoT systems in which SPL manages variability between 2006 and 2018. The authors argued that several proposals seek to manage the variability of these systems in both runtime and SPL design, evolving towards a DSPL environment to manage variability through software reconfigurations. [PERSON] et al. [32] expose through a systematic literature review of the literature the most used practices in the product derivation stage in the DSPL approach. They identified several proposals, which base their reconfigurations on the system's architecture to be developed, from the software system's behavior, architecture, and components, which were mapped based on the MAPE-K control loop. [PERSON] and [PERSON] [13] present a systematic literature review in which they analyze various proposals to manage variability in SPL, obtaining that the feature models are the primary approach to manage variability in SPL, where in second place is the use of UML and its extensibility. Although this proposal does not focus on DSPL, it establishes an evolution of DSPL between the years 1990 to 2010, showing that the DSPL was not yet at the peak it is today. [PERSON] et al. [33] present an SMS, looking for the main application areas of SPLs. This work is based on a service orientation from 2001 to 2011, describing that many of the software services created from SPLs are adaptive systems and, to a lesser extent, the DSPL approach.