Merge branch 'feedback' into 'master'

Feedback See merge request horlingsw/master-assignment-report!12
5 yıl önce · 969b6843a5
--- a/content/analysis.tex
+++ b/content/analysis.tex
@@ -43,7 +43,11 @@ The steps that are introduced by \ridm are covered in more detail.
        In the initial design step, the "what has to be solved", is expanded with a solution on "how it is solved".
        To find the best solution it is important to explore the different solutions and design space.
        Often, there are many possible alternatives but they must be narrowed down to the solutions that fit within the schedule and available resources.
        This step results in one initial design that is used in the next phase of the design.
        The best alternative is materialized in a design document together with the system requirements.
        To verify that the system works in line with the system requirements, a test protocol is written for the system.
        This protocol explains how the tests are preformed and what the pass conditions are.
        This design document is used in the next phase of the design.


 \section{Rapid Iterative Design Method}
    From this point, the design plan is based on the \ridm and not anymore on the waterfall model.
@@ -63,13 +67,18 @@ The steps that are introduced by \ridm are covered in more detail.
 \subsection{Feature Definition}
    \label{sec:featuredefinition}
    During the feature definition, the system is split into features as preparation for the rapid development cycle and the variable-detail approach.
    The aim of the \ridm is to have short implementation cycles to have early testing feedback.
    To achieve this, the features are as small as possible, but can still be implemented and tested individually.
    The goal of the \ridm is to get feedback of the design as early as possible by performing short implementation cycles.
    To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
    However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
    Together with the definition of the features, the requirements are divided along the features as well.
    During the initial design, a test protocol is made to evaluate the system-wide specifications.
    For the feature requirements, tests are added to the test protocol as well.
    These tests only require the corresponding feature to be implemented and must all pass to finish the implementation of the feature.
    The optimal strategy on splitting features and specifications is strongly dependent on the type of system.
    Therefore, the best engineering judgement of the developer the best tool available.

    Sometimes features are dependent on each other, the implementation of one feature influences another.
    In some cases it is not possible to define a feature that can be implemented and tested independently.
    This occurs when the feature is dependent on the implementation of other features.
    This dependency can occur in specifications, where strength of one feature dictates the maximum mass of another feature.
    Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature.
    Another type of dependency is when the implementation influences other features.
@@ -77,8 +86,16 @@ The steps that are introduced by \ridm are covered in more detail.
    An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
    When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.

    There are two important responsibilities for the developer when the design encounters feature dependency.
    The first one is during the definition, where the developer has to decide on how to split the system and how the dependency is stacked.
    For the specification and the implementation dependency the developer must evaluate the optimal order of dependency.
    The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
    In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
    The second responsibility is organizing the feature requirements.
    Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
    This is not directly a problem, but a good administration of the requirements makes an update of the requirements easier.
    This is not directly a problem, but a good administration of the requirements makes an update of these requirements easier. 



 \subsection{Feature Selection}
    \label{sec:feature_selection}
@@ -111,8 +128,9 @@ The steps that are introduced by \ridm are covered in more detail.

    To determine the order of implementation of features, a dependency graph and a comparison table is made.
    The dependency graph and the comparison table for a theoretic system is shown in \autoref{fig:feature_dependency} and \autoref{tab:feature_selection} respectively.
    The comparison table has dependees column, that describe the number of features that are depending on that specific feature, and are derived from the dependency graph.
    The comparison table has dependees column, that describes the number of features that are depending on that specific feature, and are derived from the dependency graph.
    The tests column describes the number of tests that are covered by implementing this feature.
    These tests are defined during the initial design and the feature definition, the number represents the amount of tests that pass after implementation of the feature.
    The risk per time score for third rule is calculated by dividing the risk score with the time score.
    The goal of this score is to eliminate as much risk as possible in the least amount of time.
    It seems logic to always implement the highest risk feature first, but it is possible to finish multiple features with a lower risk in the same time period.
@@ -163,10 +181,10 @@ For this design choice, a design document is made that illustrates the rough sha
 The basic model and the detail elements are based on an initial design of the feature.
 The basic model consists of only the most basic elements of the design.
 As the basic elements that make the basic model differ strongly per system, there is not a specific approach.
 A good starting point is to identify the interesting energy states of the system.
 In general, the basic elements should only represent dominant and essential behavior of the system.
 A good starting point for the dominant behavior is to identify the interesting energy states of the system.
 The energy states of interest can include the energy states that are dominant, but also the states that are chosen by the developer.
 These last states could represent the output states or status that have to be measured.
 %However, the basic model should at least represent the dominant energy states of the feature.
 In the end, the developer decides if states are required and implement them in the basic model.
 All the elements that are part of the initial design but are not part of the basic model are the detail elements.

@@ -176,7 +194,7 @@ The electrical motors have also internal states, but store significantly less en
 An basic model would in this case only consists of the arms, possibly even without any dynamic behavior.
 The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements that can be added to increase the detail.

 To finish this step all that is left is to describe a list of tests.
 Now with initial design and the basic model, all that is left is to describe a list of tests.
 The goal of these tests is to verify if the design meets the specifications of the feature.
 The tests have a short description on how to perform the tests and what should be achieved.
 It is important that all the specifications are covered by at least one test.
@@ -194,7 +212,7 @@ The newly added detail is evaluated by performing the tests that were defined du
 \begin{figure}
    \centering
    \includegraphics[width=8.5cm]{graphics/test_flow_graph.pdf}
    \caption{Decision flowchart for failed test results.}
    \caption{Decision flowchart to follow for failed tests on each detail level.}
    \label{fig:test_flow_graph}
 \end{figure}
 Not all tests are expected to succeed from the start, as not all details are implemented.
@@ -214,3 +232,27 @@ The developer must evaluate if there are feasible alternatives left for this ele

 When all detail elements are implemented and the basic model has evolved into a refined model of the feature, the design cycle moves back to the feature selection.
 In the case that this is the last feature to implement, this concludes the development.

 \section{Summation}
 \begin{marginfigure}
    \centering
    \includegraphics[width=6cm]{graphics/design_flow_analysis.pdf}
    \caption{Combined design plan, based on the \ridm and the Waterfall model.}
    \label{fig:design_plan_analysis}
 \end{marginfigure}
 The waterfall model from \ac{se} and the \ridm \autocite{broenink_rapid_2019} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
 The first four steps of the design process form the preparation phase: problem description, specifications, initial design, and feature definition.
 The initial design step creates a holistic design based on the prior problem description and specifications step.
 The last step of the preparation is the feature definition, where the initial design is split into different features.
 The resulting initial design and its features together form the design proposal for the development steps.
 The development step consists of the feature selection, rapid development, and variable detail steps.
 These three steps are applied to each feature in the initial design individually.

 With each iteration of the development cycle a new feature is added to the complete system.
 All the tests of the individual features are performed in the complete system as well.
 This ensures that the one feature does not break a another feature.
 The design is finished when all the features are implemented, tested and combined.

 In the optimal situation the preparation phase is only performed once at the start of the design, and the development cycle is performed for each feature.
 However, if features prove to be infeasible, some steps have to be revised.

--- a/content/background.tex
+++ b/content/background.tex
@@ -1,10 +1,16 @@
 %&tex
 \chapter{Background}
 \label{chap:background}
 The \ridm by \textcite{broenink_rapid_2019} only describes a partial design method.
 To create a complete design plan, a waterfall model is used as a basis for the design plan.
 The techniques of the \ridm are incorporated on top of the waterfall model.
 This chapter will analyse the basics of a waterfall model, and analyse what the \ridm provides.
 Engineers have many different types of design methods available in their fields.
 Examples of these are Agile, Spiral, V model, and Waterfall.
 Each of these design methods start with a need and develop a product to satisfy that need.
 From an extremely basic point of view, these methods start with a preliminary design where the need is translated into an initial design, requirements, and specifications.
 This initial design is implemented into a product and the product is tested.
 The preliminary design is often similar between the different design methods, but the methods differentiate on their implementation and testing phase. 
 \textcite{broenink_rapid_2019} do not provide a complete design method and focus on their implementation and testing method.
 To create a complete design plan that can be used in the case study, I used the waterfall model in the \ac{se} approach as a basis for the design plan.
 The techniques of the \ridm replace the implementation and testing phase of the waterfall model.
 This chapter will introduce the basics of \ac{se} and the waterfall model, and analyse what the \ridm provides.

 \section{Systems Engineering}
 \begin{marginfigure}
@@ -14,12 +20,10 @@ This chapter will analyse the basics of a waterfall model, and analyse what the
    \label{fig:waterfall}
 \end{marginfigure}
 \textcite{blanchard_systems_2014} describe \ac{se} in their book as: "an interdisciplinary approach and means to enable the realization of successful systems."
 Their book extensively covers different design methods and design steps in detail.
 As these design methods are presented in complete detail, they are used as a basis for the design plan in this thesis.
 Multiple design methods are presented and one of the simplest design methods is the waterfall model.
 There are more elaborate methods available like the V-model or the spiral model, but are more interconnected due to build in feedback cycles.
 The waterfall model is usefull because it is a list of steps that are executed one by one as shown in \autoref{fig:waterfall}
 Because the steps are independent of each other, it is possible to insert or switch steps in the design method.
 Their book extensively covers multiple design methods and design steps in detail.
 The simplest of these design method is the waterfall model.
 This waterfall model consists of number of steps that are all successively executed as shown in \autoref{fig:waterfall}.
 The successive steps make it possible to insert or replace the steps in the design method.

 \section{Rapid Iterative Design Method}
 The \ridm by \textcite{broenink_rapid_2019} describes a methodology using two core components for the implementation: the rapid development cycle and the variable detail approach.
@@ -28,11 +32,11 @@ In short, the preparation prepares a list of features.
 These features are implemented one by one with in the rapid development cycle using the variable detail approach.
 This section discusses each of these three parts and how they fit in the waterfall model.

 \subsection{Rapid Development} 
 \subsection{Rapid Development Cycle} 
 The rapid development cycle consists of multiple iterations, where each iteration implements and tests one feature, that was defined during the preparation.
 Each iteration of the rapid development incorporates the following steps:
 \begin{enumerate}
    \item Design new feature and the corresponding tests.
    \item Create an initial design and corresponding tests for the next feature.
    \item Implement and test that feature.
 \end{enumerate}
 The first step is to create an initial design and tests that are used to verify the requirements of the current feature.
@@ -54,14 +58,16 @@ The variable detail approach is finished when all the tests are passed and all t
 Although the \ridm does not specify the complete steps for the preparation, it does state some requirements.
 The rapid development cycle requires a list of features that can be implemented one by one.
 These features are gained by splitting the system into individual subsystems, where each subsystem can be implemented and tested individually.
 For each feature it is required to specify the feature requirements and the corresponding test protocol.
 The feature requirements are based on the system requirements and the tests are used to validate that the feature meets its requirements.
 About the order of implementation, the \ridm states that critical features should be implemented first, as these features have an increased chance of invalidating the complete design.
 Would such a feature fail, the investment loss is limited, because the development is still in an early stage.

 \subsection{Combination}
 \section{Combination}
 \begin{marginfigure}
    \centering
    \includegraphics[width=6cm]{graphics/design_flow.pdf}
    \caption{Combined design plan, based on the \ridm and the Waterfall model.}
    \caption{Combined design plan, where the first three steps are based on the waterfall model and the other four steps are taken from the \ac{ridm} \autocite{broenink_rapid_2019}}
    \label{fig:design_flow}
 \end{marginfigure}
 As the \ridm integrates the implementation and testing steps together, it replaces these steps in the waterfall model.
--- a/content/introduction.tex
+++ b/content/introduction.tex
@@ -6,79 +6,114 @@
    This physical system is often a system of mechanical components which are deeply intertwined with the software components.
    Automobiles, robots, medical devices and even the smart grid are examples of \ac{cps}.
    The complexity of \ac{cps} has gone from an embedded system that improved the fuel consumption of a car engine to a fully self-driving vehicle.
    Although the complexity opens up more design possibilities, improved efficiency, and beter safety, it has downsides.
    The problem with the increasing complexity is the resulting increased developing cost and the decreasing reliability.
    Within the research topics that focus on \ac{cps}, lies the development of new design methods that deal with this complexity problem.
    The \emph{design method} by \textcite{broenink_rapid_2019} is one of these new design methods and focusses on the rapid development of embedded control software.
    The rapid development is a design technique that splits the development into small individual steps, which are implemented and tested separately.
    Testing each individual step creates feedback on a short interval, with the goal to detect errors made during the development as early as possible.
    Although the complexity opens up more design possibilities, improved efficiency, and beter safety, it has downsides as well.
    A major downside with the increasing complexity is the resulting increased developing cost and the decreasing reliability.
    \textcite{broenink_rapid_2019} introduce a new design method for \ac{cps} that aims to deal with the downsides of the complexity.
    Throughout this thesis, the term '\acl{ridm}' or abbreviated to \acs{ridm}, is used to refer to the design method by \textcite{broenink_rapid_2019}. \acused{ridm} %Set acronym to used. From here only small is set.
    The \ac{ridm} adopts a design technique called rapid development that splits the development process into small individual steps
    Where each of these steps are implemented and tested separately.
    Testing each individual step creates feedback on a short interval, finding errors in the design as early as possible.
    In the worst case scenario, the time and resources spent on development from the error being made till the error being detected are lost.
    The sooner an error is found, the less time and resources are wasted.

    As part of the research, Broenink and Broenink performed a small case study.
    In this case study, they have designed a controller, and implemented the controller in software for a physical off-the-shelf system.
    However, developing \ac{cps} incorporates both the computational software side, as well as the development of the physical dynamic side, although the latter is not covered by Broenink and Broenink.
    For this design method to be suitable for a complete design of \ac{cps} it has to be applicable to the physical part as well.
    Developing \ac{cps} incorporates the computational software side and the physical dynamic side.
    However, the case study by Broenink and Broenink only covers the software side of a \ac{cps}.
    For this design method to be suitable for a complete design of \ac{cps} it must apply to the physical part of the system as well.
    
    %%In this thesis, the proposed design method is applied and evaluated in the context of the physical part of a \ac{cps}.
    %%This is done in a case study, where a \ac{cps} is designed from scratch.
 \section{Research Objective}
    \textcite{broenink_rapid_2019} present a case study for software in their paper and state that "this [case study] does not mean that the same techniques cannot be applied to the physical part of the system."
    In this thesis, I will research whether this design method applies to the physical part of a \ac{cps}, to come to a design method that can be applied on both the physical and cyber (software) part of a \ac{cps}.
    From the start of this research, it was clear that a direct copy of the design method is not possible.
    It is therefore necessary to analyse which design techniques cannot be used and thus how to replace or improve them.
    The research is summarized in the following two research questions:
    \textcite{broenink_rapid_2019} present a case study in their paper, developing a software based control system following the \ac{ridm}.
    About the result of that case study they state that "this [case study] does not mean that the same techniques cannot be applied to the physical part of the system."
    In this thesis, I will research whether the \ac{ridm} applies to the physical part of a \ac{cps}, to come to a design method that can be applied on both the physical and cyber (software) part of a \ac{cps}.
    However, the paper makes no attempt to offer a comprehensive design method to be used out of the box.
    The \ac{ridm} does not provide information about bringing a system into being, it does not address problem definition, specifications or initial design steps.
    Another weakness is that the \ac{ridm} gives no explanation of how the design steps are executed, only specifying that they are used.
    The design method would have been more useful if the authors had made a complete design method available to accompany their paper.
    To ensure that the \ac{ridm} can be assessed as a design method for \ac{cps}, I have the following research objectives:
    \begin{itemize}
        \item Extend the \ac{ridm} with a preliminary design phase.
            This makes it possible develop a system for a given problem or idea, using this design method.
        \item Refine the \ac{ridm} to make the execution of the different design steps explicit and unambiguous.
        \item Develop and perform a case study that tests and evaluates the \ac{ridm}.
    \end{itemize}
    Based on the results of the case study I will answer the following research questions:
    \begin{itemize}
        \item Which design techniques of the design method by \textcite{broenink_rapid_2019} can be applied developing the physical part of \ac{cps}?
        \item Which adaptations are required to make the design method by \textcite{broenink_rapid_2019} suitable for developing the computation and physical part of \ac{cps}?
    \end{itemize}

 \section{Approach}
    Within this thesis, the design method by \textcite{broenink_rapid_2019} is evaluated in a case study.
    The case study performs a development process according to the design method and evaluates the result.
    However, there are a couple of steps required prior to the start of the case study (see \autoref{fig:approach}).
    The goal of this thesis is to evaluate the \ac{ridm}, a design method by \textcite{broenink_rapid_2019}.
    Their design method is evaluated in the form of a case study.
    The case study consists of a \emph{design process}, developing a \ac{cps} according to the \ac{ridm}.
    Based on the results of the design process, the \ac{ridm} is evaluated.
    However, there are a couple of steps required prior to the start of the case study.
    %To perform the case study reproducible, it requires a design plan, a subject of design and a evaluation protocol.
    %The \emph{design plan} is a refined version of the design method by \textcite{broenink_rapid_2019}, extended with a design method from \ac{se}.
    The first step is to produce a concrete \emph{design plan} based on the design method.
    The concrete design plan improves the evaluation of the design techniques.
    The design method is presented in an abstract form which leaves room for interpretation.
    This hampers the evaluation process, because it is impossible to point out flaws in something that was not specific in the first place.
    Therefore, I will assess the design method and add detail to get a concrete design plan.
    This abstract form hampers the evaluation process, as the ambiguity of the design method makes it difficult to point out flaws in the design method.
    Therefore, I will assess the design method and add detail to make a more concrete design plan.
    Because the design method focusses on the rapid development principles and modelling techniques, it does not cover the design steps outside of that focus.
    These steps, like problem definition and system specifications, are a crucial part of the design process and are added to create the concrete design plan.
    The added steps are based on the steps in a \ac{se} approach.
    The added steps are based on the steps from the \emph{\ac{se}} approach.
    \begin{figure}
        \centering
        \includegraphics[width=9cm]{graphics/approach.pdf}
        \caption{A graph that shows the interconnection of the different steps that are required to prior to the start of the case study.}
        \caption{The case study is consists of something to be designed (subject of design), how to design that something (design plan), and how to evaluate the design process.
            The design plan itself is a combination of the \ac{ridm} and \ac{se}.}
        \label{fig:approach}
    \end{figure}

    With a design plan to use in the case study there are two steps of preparation left.
    The first step is to develop an evaluation plan to ensure complete and consistent feedback during the case study.
    The evaluation plan consists of a list of questions that have to be evaluated for each design step.
    There are specific questions that evaluate the definition, or the execution of the design step.
    The other step is to provide the \emph{subject of design} to develop in the case study.
    The first step is to develop an \emph{evaluation protocol} to ensure complete and consistent feedback during the case study.
    The evaluation protocol consists of a list of questions that are evaluated for each design step.
    The protocols contains questions about the design method itself, thus evaluating the instruction of each design step.
    Other questions are about the design process, covering the execution of the instructions.
    %There are questions that evaluate the design plan and there are questions that evaluate the design process.
    The other step is to provide the \emph{subject of design} to develop in the case study, essentially defining a problem that has to be solved.
    How all these components combine into the case study is shown in \autoref{fig:approach}.

    Normally, the design process focusses on delivering the end product in the most effective manner.
    However, the goal of this research is to use the design process to evaluate the design method, not to develop a product.
    A possible pitfall is that during the design process a simple solution is found, such that the design techniques to deal with the increased complexity are left untouched.
    Choosing to develop a very complex subject ensures that the case study covers all the design techniques.
    Unfortunately, the limited time budget of a master's thesis makes it impossible to perform a case study for a complex subject.
    One of the requirements for the possible subjects is therefore a minimum level of complexity, forcing the developer to not go with the simplest solution.
    Some other requirements, based on practical decisions like budget, tools, and time were defined as well.
    Based on these requirements, the subject of choice is "Writing a tweet on a whiteboard".
    
    With something to develop, a method to develop, and a method to evaluate, the case study is executed.
    Even though the case study was terminated due to the limited amount of time available, it resulted in a partial prototype of a whiteboard writer and a significant amount of evaluation.
    The results made it possible to propose improvements to the design method, not only for the physical part of \ac{cps} but also the cyber part.
    A possible pitfall is that during the design process the developer finds a simple solution, such that the design techniques to deal with the increased complexity are left untouched.
    Therefore, it is important to guarantee a minimum level of complexity.
    Instead of setting a problem that is very complex, I decided to require a minimum complexity to the solution.
    This makes the design process complex enough, without requiring an excessive amount of development time or compromising the quality of the evaluation.
    Together with some other practical requirements, the best subject of design found is "Writing a tweet on a whiteboard".
    The subject of design is interesting because it has multiple design solutions that are complex but not unpractical.
    Furthermore, it has some interesting dynamics, requires a control law, and can easily be constructed in to a prototype.

    With a subject of design that requires a solution in the form of an object incorporating both physical and cyber parts to develop;
    a design plan which describes how to develop this solution;
    and a protocol to evaluate the design plan and the development of the solution;
    the case study is executed.
    From the results of the case study I propose multiple improvements to the design method, not only for the physical part of \ac{cps} but also the cyber part.

 \section{Notes on Terminology}
    Design method is a commonly-used notion throughout the different papers and research used in this thesis.
    \textcite{broenink_rapid_2019} refer to their design method as 'the methodology', which is to generic for this thesis.
    To ensure distinct terminology throughout this thesis, their methodology is named \acl{ridm} and is abbreviated as \acs{ridm}.
    The more concrete version of the design method that is tested in the case study, is referred to as the 'design plan'.
    The object or system that is going to be designed during the case study is referred as 'subject of design'.
 %\section{Notes on Terminology}
 %    Design method is a commonly-used notion throughout the different papers and research used in this thesis.
 %    \textcite{broenink_rapid_2019} refer to their design method as 'the methodology', which is to generic for this thesis.
 %    To ensure distinct terminology throughout this thesis, their methodology is named \acl{ridm} and is abbreviated as \acs{ridm}.
 %    The more concrete version of the design method that is tested in the case study, is referred to as the 'design plan'.
 %    The object or system that is going to be designed during the case study is referred as 'subject of design'.

 \section{Structure}
    The refinement of the design method and adding design steps is done in \autoref{analysis} to define a concrete design plan.
    The evaluation plan and subject of design is defined in \autoref{case_method}.
    The case study is executed in \autoref{case_experiment}, based on the design plan, evaluation plan and subject of design.
    The execution of the case study is evaluated in \autoref{case_evaluation}.
    In \autoref{reflection} the evaluation of the case study and the results are reflected back on the design plan.
    Based on the reflection and the evaluation, an improved design method is proposed in \autoref{improved_design}.
    And finally, the research is concluded in \autoref{conclusion}.
    The overall structure of the study takes form of 8 chapters.
    The first two chapters introduce the used design methods.
    \autoref{chap:background} gives a background of the \ac{ridm} and \ac{se} approach and how this is combined into the design plan.
    The design plan is presented in full detail in \autoref{chap:analysis}, where each step is explained.

    \rrot{De rest van deze sectie is nog niet af!}
    The next three chapters cover the method, execution, and evaluation of the case study.
    \autoref{chap:case_method} is concerned with the methodology of the case study, introducing the subject of design and the evaluation protocol.
    \autoref{chap:case_experiment} documents the execution of the case study, showing the development during the design process.
    All the questions and observations that were administered by following the evaluation protocol during the case study are analysed in \autoref{chap:case_evaluation}.
    
    The last three chapters will reflect on the design plan that is evaluated in this research.
    \autoref{chap:reflection} uses the evaluation results of the case study to reflect on the design plan in this thesis.
    Based on these reflections, a number of improvements on the design is presented in \autoref{chap:improved_design}.
    And finally, the research is concluded in \autoref{chap:conclusion}.
--- a/graphics/approach.tex
+++ b/graphics/approach.tex
@@ -10,11 +10,11 @@ draw=black!20, thick, fill=white, font=\footnotesize},
 \begin{document}

 \begin{tikzpicture}[on grid,y=1.2cm,x=1.6cm]
    \node (dm) {Design Method};
    \node (dm) {RIDM};
    \node (a1)[right = 1 of dm, draw=none, fill=none] {};
    \node (se)[right = 2 of dm] {Systems Engineering};
    \node (dp)[below = 1 of a1] {Design Plan};
    \node (ep)[left  = 2 of dp] {Evaluation Plan};
    \node (ep)[left  = 2 of dp] {Evaluation Protocol};
    \node (sd)[right = 2 of dp] {Subject of Design};
    \node (cs)[below = 1 of dp] {Case Study};
    \path[->] (dm) edge (dp)
--- a/graphics/design_flow_analysis.tex
+++ b/graphics/design_flow_analysis.tex
@@ -0,0 +1,31 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
 \usetikzlibrary {arrows.meta,positioning}
 \tikzset{nodes={text height=.7em, text width=2.8cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}

 \begin{document}
 \begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm]
    \draw[fill=lightgray] (-1.7cm, 1.5cm) rectangle (1.7cm, -4.1cm);
    \draw[fill=lightgray] (-1.7cm,-4.3cm) rectangle (5cm, -8.2cm);
    \node (pd) {Problem Description};
    \node (sp)[below=1 of pd]  {Specifications};
    \node (id)[below=1 of sp]  {Initial Design};
    \node (fs)[below=1 of id]  {Feature Definition};
    \node (ss)[below=1 of fs]  {Feature Selection};
    \node (a1)[below=0.8 of ss,draw=none, fill=none] {};
    \node (rd)[below=0.8 of a1]  {Rapid Development};
    \node (va)[right=1 of a1]  {Variable Approach};
    \node (pp)[above=0.8 of pd,draw=none,fill=none] {Preparation Phase};
    \node (dc)[below=1.6 of va,draw=none,fill=none] {Development Cycle};
    \path[->] (pd) edge (sp)
              (sp) edge (id)
              (id) edge (fs)
              (fs) edge (ss)
              (ss) edge (rd)
              (rd.east) edge[bend right] (va)
              (va) edge[bend right] (ss.east);
 \end{tikzpicture}
 \end{document}