## 3 Research Plan  
The research follows a case study methodology, including two cases. Nevertheless, these cases were carefully crafted as generalized cases, based on extensive process modeling in both academia and industry; and the cases designs avoid over-simplification. Our research is therefore representative of DPD modeling.  
In the next section (Section 4) we demonstrate how GPM (OPM) can be cumbersome to use and how it can be enhanced using DSM (PROVE). This will lead to conclude that DSM can be used in conjunction with GPM to address the issues of usability discussed in the introduction. This demonstration describes the modeling of a partial process description extracted as a generalized case from real-life development plans. We present the case as an exercise in process description modeling. This is done in order to give readers a sense of the effort that is required in order to perform MBSE in industry; and establish that modeling complexity incorporates not only the complexity of the language but also manifestations of the modeling concepts and the modeling process. Eventually, such understandings should convince the reader not only of the value proposition of using DSMs, but--more importantly--that a careful, ontology-based approach is required for facilitating rigorous and meaningful use of MBSE for domain applications [30].  
To simplify our demonstration, the challenge here is to model an existing process design, and not to design a process. This neutralizes aspects of process design, allowing us to focus exclusively on modeling aspects. Some \"shortcuts\" are made with respect to the process description and its modeling, in order to maintain a manageable scope that can be clear even to readers who are not domain experts. These \"shortcuts\", however, do not result in any loss of generality; nor do they over-simplify practical aspects. Following the first case, we take an existing DSM process model and translate it to a rigorous GPM model. This serves to provide added evidence about the differences in model complexity between the approaches.  
The first case study includes the following steps (Sections 4.2-4.4):  
1. Model a process with GPM (e.g., OPM): we show the difficulty and cognitive load of using the GPM to model the process.
2. Model the process with GPM using insight from DSM (e.g., PROVE): we show how insight related to DSM ontology allows using selected GPM patterns to simplify modeling.  
Model the process with DSM: we show how using a well-designed DSM methodology can simplify modeling considerably.  
The second case study includes a single step (Section 4.5):  
1. Take a model created with DSM and translate it to a GPM.  
We define two quantitative metrics to establish our observations throughout the case studies: (1) the number of available modeling tactics during the modeling process, which is an indication of the cognitive load of the modeling process (e.g., selecting a modeling tactic that is semantically valid to the situation and model intent); (2) the number of representational elements of the final model, which is an indication of the cognitive load required to interpret and communicate the model, as well as an indication of the modeling effort itself (as each of these representational elements are typically created manually by the modeler; see, for example, [29], in which the complexity of modeling simple system characteristics is explicitly identified as a barrier for MBSE adoption). The latter metric is also an indication of model parsimony, which is a preferred model property [44]. Two hypotheses related to these metrics were articulated in the introduction.