# Finding the Right Way Towards a CPS – A Methodology for Individually Selecting Development Processes for Cyber-Physical Systems

Günther Schuh, Violett Zeller, Max-Ferdinand Stroh, Philipp Harder

► To cite this version:

Günther Schuh, Violett Zeller, Max-Ferdinand Stroh, Philipp Harder. Finding the Right Way Towards a CPS – A Methodology for Individually Selecting Development Processes for Cyber-Physical Systems. 20th Working Conference on Virtual Enterprises (PRO-VE), Sep 2019, Turin, Italy. pp.81-90, 10.1007/978-3-030-28464-0_8 . hal-02478795

HAL Id: hal-02478795

https://inria.hal.science/hal-02478795

Submitted on 14 Feb 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Finding the Right Way Towards a CPS – A Methodology for Individually Selecting Development Processes for Cyber-Physical Systems

Günther Schuh, Violett Zeller, Max-Ferdinand Stroh and Philipp Harder

Institute for Industrial Management, FIR at RWTH Aachen University, Campus-Boulevard 55, 52064 Aachen, Germany

{Guenther.Schuh; Violett.Zeller; Max-Ferdinand.Stroh; Philipp.Harder}@fir.rwth-aachen.de

**Abstract.** Numerous traditional, agile and hybrid development approaches have been proposed for the development of CPS. As the choice of development process is crucial to the success of development projects, it has become a major challenge to identify the best-suited process.

This paper introduces a methodology for identifying the best-suited CPS development process, based on the individual boundary conditions for a certain development project within a company. The authors used a set of eight indicators to assess a CPS-development project. The results of the assessment were matched with CPS-development approaches. Based on the matching results a best-suited development process was selected. The application is shown for a use case in the German manufacturing industry. The developed method aims to reduce the risk of project failure due to the wrong choice of development process.

**Keywords:** CPS, Development Process, Agile Development.

## 1 Introduction

Industry 4.0 and digitalization are transforming our companies. In order to keep pace with this development, companies are forced to transform their products and systems from mecha(tro)nical into Cyber-Physical Systems (CPS) [1]. CPS connect the (real) physical world with the (virtual) cyber world. They are connected and consist of actuators and sensors, as well as a human machine interface to interact between the physical and the cyber world. They are empowered to assist humans in their decision making process and may even act autonomously. Therefore a CPS may span from a single machine to a whole (connected) production site. [2]

Different development processes from *conventional, hybrid* to *agile* have been proposed in the past. However, there is no best suited process for the development for all types of CPS [3, 4]. It is more likely that for every development project one individual process will solve the trilemma of providing a solution with the best *quality* at the lowest *cost* with the shortest *time to market* [5].

CPS are the backbone of Collaborative Networks as well as the drivers for Digital Transformation. Thus, the choice of development process is a crucial aspect within the
realization of Collaborative Networks and Digital Transformation. As the right choice of development processes is also crucial to the success of a development project, it is very important for a company to select a process that will fit to their individual boundary conditions [4]. Currently there is no methodology to select a development process for CPS based on the boundary conditions of the company. For this reason, the aim of this paper is to present a methodology to select the best-suited development process based on the individual boundary conditions in order to close the identified research gap.

To do so, a short introduction into the different development processes is given and a set of relevant CPS development processes is identified. Afterwards a set of indicators to define the level of agility for a project is selected. The set of indicators is used as a means of assessment for a development project in order to identify the best-suited development process. The application is demonstrated for a CPS-development use-case in the German manufacturing industry.

The overall goal of the paper is reflected in the research question: "How can the best-suited development process for a CPS development, based on the structured assessment of the individual boundary conditions, be selected".

For the overall research, case-study research by EISENHARDT [6] will be applied. The case-studies help selecting the relevant models for the development of CPS as well as determining the indicators for identifying the level of agility for the different models. Furthermore, they will be used to validate the results of the assessments. For this paper the focus was set on building a first prototype of the methodology in order to prove its relevance. Therefore the content of the methodology is based on literature research and own constructs. The methodology is applied to one case-study. Future research will then evaluate and enhance the indicators, the development processes and matching in detail, based on several case studies.

## 2 Background

Manufacturing companies generally use development processes in order to support their product development. The development processes describe the processes and activities within the development step by step. There is a variety of development processes, which are suitable for different purposes and boundary conditions. [7]

In general, development processes can be divided into three groups: *conventional*, *agile* and *hybrid*. **Fig. 1** shows the direction of progress within the three approaches.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Direction of progress in conventional, hybrid and agile projects [8]</figcaption></figure>
In conventional development approaches, the product development process is split into different phases that strictly follow each other. Once a previous phase is completed, a subsequent phase begins. Hence, in conventional developments, the progress follows the four phases *plan*, *conceptualize*, *design* and *develop* sequentially, as shown in **Fig. 1**. [9]

However, using the strictly sequential approach of conventional development processes in flexible development environments with volatile requirements can be quite challenging. In order to control flexible processes, *agile* concepts were introduced in the field of software development and have partially been transferred to physical product developments by now [10]. Compared to conventional development processes, agile development processes are less structured and aim to respond flexibly to new requirements, insights and customer feedback that may arise in the course of the development [11]. Thus the development progress in agile projects runs parallel in the four development phases (**Fig. 1**) [8].

Besides conventional and agile approaches there is a third category called *hybrid*, which has evolved from combining these two [12]. By combining the concepts, advances from both approaches, such as stability and flexibility, can be used simultaneously, leading to promising development processes especially for highly complex products, e.g. for the development of *Cyber-Physical Systems* [13]. Combinations to form a hybrid development process are not limited, a wide variety of patterns can be created by combining any conventional with any agile process [14]. Several procedures can be varied within a project structure according to the situation in order to implement the project-specific requirements in the most suitable way [15]. The direction of progress in hybrid projects is neither strictly sequential as in conventional projects, nor entirely parallel in all four phases as in agile concepts (**Fig. 1**).

## 3 Description of the Methodology

The developed methodology for individually selecting development processes for *Cyber-Physical Systems* is shown in **Fig. 2**. It is divided into four phases, which are executed in the displayed order.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** The four steps of the developed methodology</figcaption></figure>

In phase one the given project is subdivided into several subprojects. The division into subprojects is done in order to reduce the complexity of the overall CPS development. The number of subprojects is not fixed but should be chosen appropriate to the project's size.

Phase two is the assessment of the project which is conducted during a workshop with the participants of the project. In detail, each of the subprojects defined in the first
step is assessed by using a profile as means of assessment. The profile consists of different indicators, which indicate agility or conventionality depending on the assessment. The set of indicators is presented in the following chapter (Table 1).

In phase three the developed matching algorithm is applied to the assessed subprojects. The algorithm counts the number of matches of each subproject with each of the development processes in the system.

In phase four, the matching results are presented. The most suited model for the overall project is selected by comparing the matching results of the different subprojects. Besides selecting a single model, it is also possible to combine different development processes into a comprehensive one. Thus, universal hybrid concepts can be designed which are well suited for the given boundary conditions of the project.

## 3.1 Indicators for the Choice of Development Process

There are already several approaches presenting indicators to identify the level of agility for development projects. Some of them offer a quantitative analysis but are derived from experience (e.g. [9]). Other indicators are of a qualitative form and do not fit the use as an assessment methodology (e.g. [16]). The set of indicators selected for this paper from DIELS were derived from a literature research, follow a quantifiable scale and cover internal and external indicators [17].

DIELS developed a set of eight indicators for determining agile product scopes. The identified project-relevant indicators stand either for or against the use of agile methods in the product development, depending on their characteristics (see Table 1). The indicators are divided into (five) internal and (three) external ones, depending on whether they can be controlled by the company or not. All of the indicators of DIELS have four different characteristics, graded in three-steps from plan-driven (value 0) to agile development (value 9), which are shown in Table 1. [17]

<table><caption>Table 1. Indicators for determining agile product scopes by Diels [18]</caption><thead><tr><th></th><th>Indicators / Rating</th><th>0 (plan-driven)</th><th>3</th><th>6</th><th>9 (agile)</th></tr></thead><tbody><tr><td rowspan="5">Internal</td><td>(a) Solution space</td><td>Parallel<br>development</td><td>Focused<br>development</td><td>Highly<br>convergent dev.</td><td>Alternative<br>oriented dev.</td></tr><tr><td>(b) Prototype<br>manufacturability</td><td>Technical<br>model</td><td>Functional<br>model</td><td>Design<br>model</td><td>Concept<br>model</td></tr><tr><td>(c) Resources</td><td>Very low</td><td>Low</td><td>High</td><td>Very high</td></tr><tr><td>(d) Technology<br>ability</td><td>No knowledge<br>about technology</td><td>Proof of<br>functionality</td><td>Prototypical<br>application</td><td>Technology in<br>use</td></tr><tr><td>(e) Corporate<br>culture</td><td>Hierarchical</td><td>Disciplined</td><td>Clan</td><td>Democratic</td></tr><tr><td rowspan="3">External</td><td>(f) Market relevance</td><td>Minor<br>features</td><td>Basic<br>features</td><td>Performance<br>features</td><td>Enthusiasm<br>features</td></tr><tr><td>(g) Market accuracy</td><td>Incremental<br>change</td><td>Derivative<br>change</td><td>Platform<br>change</td><td>Breakthrough<br>change</td></tr><tr><td>(h) Market volatility</td><td>None</td><td>Low</td><td>Medium</td><td>High</td></tr></tbody></table>
For the development of the methodology for individually selecting development processes for *Cyber-Physical Systems* the approach of DIELS was chosen as a basis. DIELS'S indicators were identified during a comprehensive literature research and a following systematic consolidation, thus they fully meet the demand for project-specific boundary conditions. In addition, this approach distinguishes between plan-driven, agile (and hybrid) approaches and allows a quantifiable evaluation. Furthermore, DIELS'S approach presents a set of indicators specifically designed for determining which product scopes can be developed using agile concepts. Transferring the agility indicators to characterize both development processes and subprojects can be accomplished without further modification.

## 3.2 Selected CPS-development Processes

For developing the methodology a total of nine conventional, hybrid and agile development processes were selected, which are listed and categorized in **Table 2**. The selection was carried out on the basis of statistics on distribution of the models [19, 20]. The statistics on hybrid development processes were less clear, since in principle any combination of a conventional and an agile process would be possible. Hence, for the development of the methodology, hybrid models that have been described in literature or applied in practice were selected. Generally, further development processes can be added to the methodology independent of their nature (*agile*, *hybrid*, *conventional*).

For each development process the value of the characteristic, which describes it most accurately, was assigned according to the agility indicators of DIELS in **Table 2**. Low values represent plan-driven development (value 0), whereas high values represent agile development (value 9). The classification of the models was based on a literature research. As it is a first approach, the classification will be detailed and validated in future research. The sources used for classification are mentioned in brackets next to the respective process in **Table 2**.

<table><caption>**Table 2.** Categorized conventional, hybrid and agile development processes using the agility indicators of DIELS [17]</caption><thead><tr><th colspan="2">Dev. Processes / Indicators</th><th>(a)</th><th>(b)</th><th>(c)</th><th>(d)</th><th>(e)</th><th>(f)</th><th>(g)</th><th>(h)</th></tr></thead><tbody><tr><td rowspan="3">Conv.</td><td>Waterfall Model [21]</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3</td><td>0</td><td>0</td></tr><tr><td>Systems Engineering [22]</td><td>6</td><td>0</td><td>3</td><td>0</td><td>0</td><td>3</td><td>9</td><td>3</td></tr><tr><td>V-Model (VDI 2206) [23]</td><td>6</td><td>0</td><td>0</td><td>0</td><td>3</td><td>3</td><td>3</td><td>0</td></tr><tr><td rowspan="3">Hybrid</td><td>Agile-Stage-Gate [24]</td><td>6</td><td>9</td><td>6</td><td>6</td><td>6</td><td>9</td><td>3</td><td>3</td></tr><tr><td>Water-Scrum-Fall [25]</td><td>6</td><td>9</td><td>6</td><td>3</td><td>6</td><td>6</td><td>3</td><td>3</td></tr><tr><td>Scrum-V-Model [26]</td><td>6</td><td>9</td><td>3</td><td>3</td><td>6</td><td>6</td><td>3</td><td>3</td></tr><tr><td rowspan="3">Agile</td><td>Scrum [27]</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td></tr><tr><td>Extreme Programming [28]</td><td>6</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td><td>9</td></tr><tr><td>Kanban [29]</td><td>9</td><td>9</td><td>6</td><td>9</td><td>6</td><td>6</td><td>9</td><td>9</td></tr></tbody></table>
## 3.3 Description of the Matching Process

During the matching process, the characteristics of the defined subprojects are matched with the characteristics of all development processes one after the other, as shown in the example in **Table 3**. The number of matches with each development process is counted and can be used as an indicator for the suitability for the subproject. In the displayed example the given development process would have a total of four out of eight possible matches with the subproject, leading to a suitability value of 50 %.

<table><caption>**Table 3.** Example of the matching process of a subproject with a development process</caption><thead><tr><th></th><th>Indicators / Rating</th><th>0</th><th>3</th><th>6</th><th>9</th></tr></thead><tbody><tr><td rowspan="5">Internal</td><td>Solution space</td><td>⊗</td><td></td><td></td><td></td></tr><tr><td>Prototype manuf.</td><td>×</td><td>○</td><td></td><td></td></tr><tr><td>Resources</td><td></td><td>×</td><td>○</td><td></td></tr><tr><td>Technology ability</td><td></td><td>⊗</td><td></td><td></td></tr><tr><td>Corporate culture</td><td></td><td></td><td>×</td><td>○</td></tr></tbody></table>

<table><thead><tr><th></th><th>Indicators / Rating</th><th>0</th><th>3</th><th>6</th><th>9</th></tr></thead><tbody><tr><td rowspan="3">Extern</td><td>Market relevance</td><td>⊗</td><td></td><td></td><td></td></tr><tr><td>Market accuracy</td><td></td><td>○</td><td>×</td><td></td></tr><tr><td>Market volatility</td><td></td><td></td><td>⊗</td><td></td></tr></tbody></table>

○ = characteristic of the dev. process

X = characteristic of the subproject

## 4 Discussion of the Results for a Use-Case

The methodology was applied to a medium-sized technology company located in Germany. The overall goal of their development was to design and build an IoT factory. In this case, IoT Factory refers to a factory with connected assets, such as machines and transportation systems allowing data based production control and autonomous actions. This is in alignment with the definition of CPS given in chapter 1 of this paper. Thus the “IoT Factory” can be considered a CPS (consisting of several sub-CPSs) in its entirety. The main benefits of this factory are to reduce lead times and realize batch size one. This will be reached by a high level of automation and connectivity for the different steps within the production line. The new factory will be implemented into a supply-chain of conventional “non-IoT” factories.

Due to a large number of undefined requirements and the future orientation of the project, the choice of development process was not obvious. At this point, the methodology presented in chapter 3 was applied in order to individually select a development process for the project.

The first step was to divide the project into four subprojects: *Production Machine Design*, *IT Systems*, *Intralogistics*, and *Construction*. *IT Systems* refers to the relevant IT-Systems for controlling the production environment (e.g. ERP, MES). Usually the subprojects require competencies from different disciplines, such as IT, mechanical and electrical engineering for the *Production Machine Design*.

Every subproject was then assessed with the set of indicators presented earlier. **Table 4** gives an overview of the assessment results.
<table><caption>Table 4. Assessment results of the four subprojects</caption><thead><tr><th>Subprojects / Indicators</th><th>(a)</th><th>(b)</th><th>(c)</th><th>(d)</th><th>(e)</th><th>(f)</th><th>(g)</th><th>(h)</th><th>Ø</th></tr></thead><tbody><tr><td>01: Production Machine Design</td><td>6</td><td>3</td><td>3</td><td>6</td><td>6</td><td>6</td><td>3</td><td>3</td><td><strong>4.5</strong></td></tr><tr><td>02: IT-Systems</td><td>3</td><td>3</td><td>3</td><td>6</td><td>3</td><td>6</td><td>3</td><td>3</td><td><strong>3.75</strong></td></tr><tr><td>03: Intralogistics</td><td>3</td><td>6</td><td>3</td><td>9</td><td>6</td><td>6</td><td>3</td><td>3</td><td><strong>4.88</strong></td></tr><tr><td>04: Construction</td><td>3</td><td>6</td><td>0</td><td>9</td><td>0</td><td>9</td><td>0</td><td>3</td><td><strong>3.75</strong></td></tr></tbody></table>

On average, subproject 03 had the highest ranking on a scale from conventional to agile development. However, none of the projects were rated strongly towards agile approaches. Most of the ratings were within the range of the hybrid development processes. An interesting result in the assessment was that the subproject *IT-Systems* was rated less agile than the *Production Machine Design*. Hence showing that not only the development goal is relevant for the choice of the development process but also other boundary conditions such as corporate culture. As different departments may be involved in the subprojects, indicators may also differ between the different subprojects.

In General, CPS projects require interdisciplinary teams. That is why it is very important to have an assessment of every subproject, as the team composition may differ by discipline (Engineerg, IT, etc.) as well as the department involved (R&D, Prodcuton Management, etc.). If the selected model does not support the team composition the project is likely to fail.

Fig. 3 shows the matching results for the development processes for the assessed use-case. For all development processes selected in section 3.2, the suitability value was calculated and all development processes were listed in descending order of suitability.

For subproject one to three, the hybrid *Scrum-V-Model* shows the highest rate of suitability. Generally, the processes leaning towards strong agile or conventional development have a lower number of matches. Based on the average assessment results which were all between 3.75 and 4.88, which is mostly in the hybrid range, the result was expected and plausible.

For subproject four, the *Waterfall Model* has the highest number of matches. However, this subproject was not grasped by the methodology very well, as there were only three matches, resulting in an overlap of just 38 percent.

<table><caption>Fig. 3. Matching results of the four subprojects with the development processes</caption><thead><tr><th colspan="3">Subproject 01</th><th colspan="3">Subproject 02</th><th colspan="3">Subproject 03</th><th colspan="3">Subproject 04</th></tr><tr><th>Dev. Proc.</th><th>Σ</th><th>%</th><th>Dev. Proc.</th><th>Σ</th><th>%</th><th>Dev. Proc.</th><th>Σ</th><th>%</th><th>Dev. Proc.</th><th>Σ</th><th>%</th></tr></thead><tbody><tr><td>Scrum-V-M</td><td>6</td><td>75</td><td>Scrum-V-M</td><td>4</td><td>50</td><td>Scrum-V-M</td><td>5</td><td>63</td><td>Waterfall</td><td>3</td><td>38</td></tr><tr><td>Agile-St-G</td><td>5</td><td>63</td><td>Agile-St-G</td><td>3</td><td>38</td><td>Wa-Scr-Fall</td><td>4</td><td>50</td><td>Agile-St-G</td><td>2</td><td>25</td></tr><tr><td>Wa-Scr-Fall</td><td>5</td><td>63</td><td>SE</td><td>3</td><td>38</td><td>Agile-St-G</td><td>3</td><td>38</td><td>XP</td><td>2</td><td>25</td></tr><tr><td>SE</td><td>4</td><td>50</td><td>Wa-Scr-Fall</td><td>3</td><td>38</td><td>Kanban</td><td>3</td><td>38</td><td>Scrum</td><td>2</td><td>25</td></tr><tr><td>Kanban</td><td>2</td><td>25</td><td>V-Model</td><td>2</td><td>25</td><td>SE</td><td>2</td><td>25</td><td>SE</td><td>2</td><td>25</td></tr><tr><td>V-Model</td><td>2</td><td>25</td><td>Kanban</td><td>1</td><td>13</td><td>XP</td><td>1</td><td>13</td><td>Kanban</td><td>1</td><td>13</td></tr><tr><td>XP</td><td>1</td><td>13</td><td>XP</td><td>0</td><td>0</td><td>Scrum</td><td>1</td><td>13</td><td>Scrum-V-M</td><td>1</td><td>13</td></tr><tr><td>Scrum</td><td>0</td><td>0</td><td>Scrum</td><td>0</td><td>0</td><td>V-Model</td><td>1</td><td>13</td><td>V-Model</td><td>1</td><td>13</td></tr><tr><td>Waterfall</td><td>0</td><td>0</td><td>Waterfall</td><td>0</td><td>0</td><td>Waterfall</td><td>0</td><td>0</td><td>Wa-Scr-Fall</td><td>1</td><td>13</td></tr></tbody></table>
Based on the matching results for the individual subprojects a coherent development
process for the overall project had to be defined (phase 4). Subproject one to three all
showed the highest suitability for the hybrid *Scrum-V-Model*, combining an agile
project phase in the beginning with a conventional project phase for final deployment
of the results. The selected processes suit the use case quite well, as the development
goal is an IoT Factory, which requires both, a high level of innovation (Scrum), as well
as a high level of accuracy and stability in the deployment phase (V-Model).

For subproject four, which refers to the construction of the factory as well as the
physical placement of the assets within the factory, a plan-driven process is also very
well suited. Especially building projects require a high level of planning and accuracy
as most of the steps taken in the processes may be irreversible in the end. Due to its
strong focus on planning, a waterfall process can easily be integrated into the *V-Model*
phases of subprojects one to three. The selected development processes were
implemented in the project as proposed by the presented methodology.

In summary, a very well-suited development process for the presented use case could
be identified with the presented methodology. This shows that the proposed
methodology can be used in order to identify the best-suited development processes.

Future research will consider further case studies in order to enhance the proposed
methodology. Based on that, the indicators, choice of development processes as well as
the matching algorithm, can be further refined. As the selection of the development
process currently requires a lot of detailed knowledge, future work will also focus on
automatically finding and composing a development process along the different
subprojects.

5 Conclusion

This paper introduces a methodology for selecting the best-suited CPS development
process based on the individual boundary conditions at a company. In beginning
conventional, hybrid and agile development processes are introduced. Afterwards a set
of indicators for the choice of the development process on a scale from conventional
over hybrid to agile are selected. A selection of CPS-development processes is then
classified within the identified set of indicators. The same set of indicators is then used
as a means of assessment for the boundary conditions of CPS development projects.
Therefore the development processes, which were typed with the set of indicators, are
matched with the results of the assessment of the development project. In order to
reduce complexity, the assessed project is divided into subprojects that are assessed on
their own. Based on the matching results an individual development process is selected
for every subproject. The results are combined to an overall development process for
the assessed development project. For this paper, the presented methodology was
applied to a case-study from a German manufacturing company.

References

1. Schuh, G., Anderl, R., Gausemeier, J., Hompel, M. ten, Wahlster, W.: Industrie 4.0
Maturity Index. Managing the Digital Transformation of Companies. Munich (2017)
2. Jordan, F., Bernardy, A., Stroh, M., Horeis, J., Stich, V.: Requirements-Based Matching Approach to Configurate Cyber-Physical Systems for SMEs. In: Kocaoglu, D.F. (ed.) Technology management for the interconnected world, pp. 1–7. IEEE, [Piscataway, NJ] (2017)

3. Eigner, M., Koch, W., Muggeo, C.: Modellbasierter Entwicklungsprozess cybertronischer Systeme. Springer, Berlin (2017)

4. Reinhart, G. (ed.): Handbuch Industrie 4.0. Geschäftsmodelle, Prozesse, Technik. Hanser, München (2017)

5. Feldhusen, J., Grote, K.-H. (eds.): Pahl/Beitz Konstruktionslehre. Springer-Verlag, Berlin/Heidelberg (2013)

6. Eisenhardt, K.: Building Theories from Case Study Research. The Academy of Management Review 14, 532–550 (1989)

7. Lindemann, U. (ed.): Handbuch Produktentwicklung. Hanser, München (2016)

8. Feldhusen, J., Löwer, M., Bungert, F. (eds.): Agile methods for design to customer (2009)

9. Boehm, B.W., Turner, R.: Balancing agility and discipline. A guide for the perplexed. Addison-Wesley, Boston, MA (2004)

10. Gloger, B.: Scrum in der Hardwareentwicklung (2014)

11. Engstler, M., Hanser, E., Mikusz, M., Herzwurm, G. (eds.): Projektmanagement und Vorgehensmodelle 2014. Gesellschaft für Informatik e.V. (GI), Bonn (2014)

12. Kuhrmann, M., Diebold, P., Münch, J., Tell, P., Trektere, K., Mccaffery, F., Garousi, V., Felderer, M., Linssen, O., Hanser, E., et al.: Hybrid Software Development Approaches in Practice: A European Perspective. IEEE Software PP (2018)

13. Sandhaus, G., Knott, P., Berg, B. (eds.): Hybride Softwareentwicklung. Das Beste aus klassischen und agilen Methoden in einem Modell vereint. Springer Vieweg, Berlin (2014)

14. Kuhrmann, M., Diebold, P., Münch, J., Tell, P., Garousi, V., Felderer, M., Trektere, K., Mccaffery, F., Linssen, O., Hanser, E., et al.: Software and system development in practice: Waterfall, Scrum, and beyond

15. Engstler, M., Mikusz, M., Fazal-Baqaie, M., Gesellschaft für Informatik e.V. Bonn, G.f.I.e.V., Hanser, E., Volland, A. (eds.): Projektmanagement und Vorgehensmodelle 2015. Bonn (2015)

16. Welge, M., Friedrich, C., Shair, A.: Integration von agilen Methoden in der Systementwicklung. In: Maurer, M., Schulze, S.-O. (eds.) Tag des Systems Engineering. Zusammenhänge erkennen und gestalten, pp. 341–350. Carl Hanser Fachbuchverlag, s.l. (2013)

17. Schuh, G., Dölle, C., Diels, F., Kuhn, M.: Methodology for Determining Agile Product Scopes in Development Projects. In: Kocaoglu, D.F., Anderson, T.R. (eds.) Managing technological entrepreneurship: the engine for economic growth. PICMET'18, pp. 1–9. IEEE, Piscataway, NJ (2018)

18. Diels, F.: Indikatoren für die Ermittlung agil zu entwickelnder Produktumfänge. Aachen (2018)

19. Komus, A., Kuberg, M.: Status Quo Agile. Studie zu Verbreitung und Nutzen agiler Methoden Eine empirische Untersuchung (2017)

20. Theocharis, G., Kuhrmann, M., Münch, J., Diebold, P.: Is Water-Scrum-Fall Reality? On the Use of Agile and Traditional Development Practices. In: Abrahamsson, P., Corral, L.,
Oivo, M., Russo, B. (eds.) Product-focused software process improvement. PROFES,
9459, pp. 149–166. Springer, Cham, Heidelberg, New York, Dordrecht, London (2015)

21. Royce, W. (ed.): Managing the development of large software systems. Concepts and techniques. IEEE Computer Society Press (1987)

22. Haberfellner, R., Weck, O. de, Fricke, E., Vössner, S.: Systems Engineering. Grundlagen und Anwendung. Orell Füssli, Zürich (2012)

23. VDI 2206: Entwicklungsmethodik für mechatronische Systeme. Beuth, Berlin (2004)

24. Cooper, R.G., Sommer, A.F.: Agile-Stage-Gate for Manufacturers. Research-Technology Management 61, 17–26 (2018)

25. West, D.: Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today (2011)

26. Timinger, H., Seel, C.: Ein Ordnungsrahmen für adaptives hybrides Projektmanagement. Projekt Management aktuell, 55–61 (2016)

27. Schwaber, K.: Agile project management with Scrum. Microsoft Press, Redmond, Wash. (2004)

28. Beck, K.: Embracing change with extreme programming. Computer 32, 70–77 (1999)

29. Anderson, D.J.: Kanban. Successful evolutionary change for your technology business. Blue Hole Press, Sequim, Washington (2010)