Process feedback Design plan

content/analysis.tex

@@ -1,25 +1,30 @@
 %&tex
-\chapter{Analysis}
+\chapter{Design Plan}
 \label{chap:analysis}
-The previous chapter introduced how two design methods are combined to form the bases for one complete design method.
-In this chapter, a design plan is created from this combined design method.
-The goal is to have a concrete design plan that is used in the case study.
+The goal of this chapter is to define a concrete design plan that is used in the case study.
 All of the steps in the design plan must be specific such that each of these steps can be evaluated after the case study is finished.
-The first three steps of the design phase are based on the \ac{se} approach and are already described with great extend by \textcite{blanchard_systems_2014}.
-As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}.
-The steps that are introduced by \ac{ridm} are covered in more detail.
+The previous chapter introduced how two design methods are combined to form the basis of the design plan.
 
-\section{Systems Engineering}
-    The goal of the preliminary design is to setup system requirements and an initial design according to the problem definition.
+The design plan consists of two parts:
+The first part is the Preliminary System Design and contains the linear set of steps from problem description to feature definition.
+The second part is the Development Cycle, which contains the features selection, variable-detail approach and rapid development cycle.
+
+\section{Preliminary Phase}
+    The goal of the preliminary design phase is to create a set of features for the design solution.
     Although these design steps in \ac{se} play a crucial roll in the success of the development, they are, however, very exhaustive.
     A major part of this complete design process is the required documentation to ensure agreement about the design between the different stakeholders.
     Resulting in a process that can take months or even years, which is not feasible for this thesis.
+
     In this thesis, this design plan is only used for evaluation and has only one stakeholder, the author.
     This allows for a simple implementation of the \ac{se} approach, as it not possible to create a false start due to misunderstanding, saving valuable time.
-    For each of these \ac{se} steps is explained what is involved with a full implementation, and what part of the step is used in the design plan.
 
-    \subsection{Problem Definition}
-        Before any design process can start, the "problem" has to be defined.
+    The first three steps of the preliminary phase are based on the \ac{se} approach by \textcite{blanchard_systems_2014}.
+    As the evaluation of \ac{se} is not in the scope of this thesis, this chapter only covers the minimal description of the design steps in \ac{se}.
+    These three steps deliver requirements and an initial design. 
+    The last two steps define the set of features and tests based on these deliverables.
+
+    \subsection{Problem Description}
+        Before any design process can start, the "problem" has to be described.
         In other words, why is the function of the system needed?
         This is described in a \emph{statement of the problem}.
         In this statement of the problem it is important to describe "what" has to be solved, not directly "how".
@@ -34,7 +39,7 @@ The steps that are introduced by \ac{ridm} are covered in more detail.
         As these characteristics form the foundation of the system, the requirements must be defined without any ambiguity, vagueness or complexity.
         The requirements are written according to the \ac{ears} \autocite{mavin_easy_2009}.
         \ac{ears} was chosen for this design method due to its simplicity, which fits the scope of this thesis.
-        Later in the design, these requirements are divided over the subsystems.
+        Later in the design, these requirements are distributed over the subsystems.
         Any issues, like ambiguity, in the requirements, propagate through these subsystems.
         This might lead to a redesign of multiple sub-systems when these requirements have to be updated.
 
@@ -46,45 +51,34 @@ The steps that are introduced by \ac{ridm} are covered in more detail.
         The best alternative is materialized in a design document together with the system requirements.
         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 \ac{ridm} and not anymore on the waterfall model.
-    The first step is the feature definition, which prepares the required features based on the initial design.
-    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
-    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
-    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.
-
-    Based on the requirements of \ac{ridm} as explained in \autoref{chap:background}, the next step is the feature selection.
-    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
-    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the specifications.
-    Following the \ac{ridm}, these tests are specified at the start of the rapid development cycle.
-    This makes it impossible to use the tests during the feature selections.
-    Therefore, a test protocol step is added after the feature definition and before the feature selection step.
-
-    The third step is the feature selection, where one of the features is selected. 
-    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
-    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
-    In the last step, the variable detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
-    The tests are used to determine if the added detail does not introduce any unexpected behavior.
-    This cycle of adding detail and testing is repeated till the feature is fully implemented.
-    From this point, the \ac{ridm} is repeated from the third step until all features are implemented.
-
-\subsection{Define features of the design}
-    \label{sec:featuredefinition}
-    During the feature definition step, the system is split into features as preparation for the rapid development cycle and the variable-detail approach.
+%\section{Rapid Iterative Design Method}
+%    From this point, the design plan is based on the \ac{ridm} and not anymore on the waterfall model.
+%    The first step is the feature definition, which prepares the required features based on the initial design.
+%    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
+%    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
+%    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.
 %
-%    \subsubsection{Functions and Components}
-%        \textcite{broenink_rapid_2019} define the features of their system by dividing the functionality of the system.
-%        However, the design method in this thesis also includes the development of the hardware.
-%        This creates an extra dimension to the features in the design.
-%        In addition of splitting the functionality, the hardware has to be split as well.
-%        Therefore, the design is described with two types of features.
-%        The functionality is split into functions and the hardware is split in to components.
+%    Based on the requirements of \ac{ridm} as explained in \autoref{chap:background}, the next step is the feature selection.
+%    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
+%    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the requirements.
+%    Following the \ac{ridm}, these tests are specified at the start of the rapid development cycle.
+%    This makes it impossible to use the tests during the feature selections.
+%    Therefore, a test protocol step is added after the feature definition and before the feature selection step.
 %
-%    \subsubsection{Making the Cut}
+%    The third step is the feature selection, where one of the features is selected. 
+%    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
+%    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
+%    In the last step, the variable-detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
+%    The tests are used to determine if the added detail does not introduce any unexpected behavior.
+%    This cycle of adding detail and testing is repeated till the feature is fully implemented.
+%    From this point, the \ac{ridm} is repeated from the third step until all features are implemented.
+
+\subsection{Feature Definition}
+    \label{sec:featuredefinition}
+        During the feature definition step, the initial design is split into features as preparation for the rapid development cycle and the variable-detail approach.
         The \ac{ridm} does not provide a particular approach to define the features of the design.
         But, the goal is to have features that can be implemented and tested individually.
-        Resulting in short development cycles and earlier feedback about the design.
-        The approach in this design plan aims to provide more guided and structured way to split the features.
+        The approach in this design plan aims to provide a more guided and structured way to split the features.
         \begin{marginfigure}
             \centering
             \includegraphics[width=21mm]{graphics/robmosys_levels.pdf}
@@ -94,26 +88,27 @@ The steps that are introduced by \ac{ridm} are covered in more detail.
         
         The approach to define features in this design plan is based on the separation of levels principle \autocite{noauthor_robmosys_2017}.
         This principle defines different levels of abstraction.
-        This starts from the top with the \emph{mission}, serving coffee for example.
-        Followed by less abstract levels such as: a \emph{task} to fill the coffee mug; a \emph{skill} to hold the coffee mug; and a \emph{service} that opens or closes the hand.
+        This starts from the top with the \emph{mission}, for example, serving coffee.
+        Followed by less abstract levels such as: a \emph{task} to fill the coffee mug; a \emph{skill} to hold that mug; and a \emph{service} allows the hand to open or close.
 
         The different levels allow the features to be split multiple times in a structured way.
-        Take the coffee serve example, to fill the coffee mug, it is not sufficient to only hold the mug.
+        Take the coffee serving example, to fill the coffee mug, it is not sufficient to only hold the mug.
         The system also has to pour coffee into the mug, and maybe add sugar or milk.
         This results in a hierarchical tree of functions as shown in \autoref{fig:robmosys_levels}.
 
         With this approach, features are defined top-down and are implemented bottom-up.
         Thus a \emph{skill} is defined as one or more \emph{services}.
         When all the \emph{services} are implemented, they are combined into a \emph{skill}.
-        The advantage of this is that the \emph{skill} defines a kind of milestone, at the moment that relevant \emph{services} are combined.
+        The advantage of this is that the \emph{skill} defines a milestone to combine the relevant \emph{services}.
         Or looking at the example: the system must at least be able to grab, stir, and pour before it can fill a mug with coffee, milk and sugar.
-        Another advantages is that two or more \emph{skills} can have a \emph{service} in common.
-        This would be the case if our system also needs to serve tea. The system can already hold a mug, but still needs to add a teabag.
+
+        Another advantages is that multiple \emph{skills} can have a \emph{service} in common.
+        This would be the case if our system also needs to serve tea. The system can already hold a mug and only needs the ability to add a teabag.
         Even though there is no exact level of abstraction required for each of the features, it does create a structure for the developer.
         In the end, the developer must rely on its engineering judgement to chose the optimal division between features.
 
-        The bottom level of the hierarchy is a special case as it describes the hardware instead of functionality.
-        The components are used to perform the functionality of the system with.
+        The bottom level of the hierarchy is a special case as it describes hardware instead of functions.
+        The components are used to execute the functionality of the system with.
         For example, having a mobile robot arm near a coffee machine does meet the hardware requirements, it does not have any functionality if that is not yet implemented.
         This also creates a clear division for the developer as the functions cannot be mixed with the hardware.
 
@@ -193,19 +188,33 @@ The steps that are introduced by \ac{ridm} are covered in more detail.
 
 \subsection{Test protocol}
     \label{sec:systemtesting}
-    During the rapid development cycle and the variable detail approach, the system is tested constantly.
+    During the rapid development cycle and the variable-detail approach, the system is tested constantly.
     This is to make sure that the design still performs as expected.
-    The tests are based on the specifications.
-    Each specification must be covered with at least one test.
+    The tests are based on the requirements.
+    Each requirements must be covered with at least one test.
     The tests consist of a description which specifies how to perform the test and what the result of the test must of must not be.
-    Together with the description, there is a list of required features to perform the test and a list of specifications that are met if the test passes.
+    Together with the description, there is a list of required features to perform the test and a list of requirements that are met if the test passes.
+
+\section{Development Cycle}
+    The development cycle consists of three steps, which are repeated for each individual feature.
+    These three steps form the core of the \ac{ridm}.
+    This starts with selecting the feature that is to be implemented, which then is implemented with the rapid development and variable-detail approach.
 
 \subsection{Feature Selection}
     \label{sec:feature_selection}
-    The rapid development cycle does not specify which feature is implemented first, even though the order of implementation does change the feasibility of the complete development.
+    The goal of this section is to improve the features selection criteria of the \ac{ridm}
+    The \ac{ridm} states that critical features, those with a high \emph{\ac{cof}}, must be implemented first.
+    If a critical feature fails, it is at the start of the design process, thereby invalidating only a portion of the design process.
+    Features that are (time) expensive to implement, must be implemented as late as possible.
+    These expensive features have a high \emph{Cost of Change} and placing them at the end of the development avoids making changes to the features.
+    
+    The \emph{\acl{cof}} and \emph{Cost of Change} are a good starting point for selection criteria.
+    However, this creates an interesting situation for features with both a high change of failure and a high cost of change.
+    The rest of this section provides a structured approach for feature selection.
+    
     An example that shows the importance of the order of features is the development of a car.
     To have a critical damped suspension in a car, the weight distribution of the car must be known.
-    If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to specifications.
+    If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to requirements.
     Resulting in a redesign of the suspension feature and thus increasing the overall development cost.
     This example is caused by the dependency between different features.
     \begin{marginfigure}
@@ -214,60 +223,68 @@ The steps that are introduced by \ac{ridm} are covered in more detail.
         \caption{Dependency graph for features.}
         \label{fig:feature_dependency}
     \end{marginfigure}
-    \begin{table}[]
-    \caption{Comparison of features with their corresponding risk and time. 
-        The last column is the risk value divided by the number of days.}
+    \begin{table*}[]
+        \caption{Comparison of features with their corresponding \ac{cof} and time. 
+        The last column is the \ac{cof} value divided by the number of days.}
     \label{tab:feature_selection}
     \begin{tabular}{l|r|r|r|r|r|}
     \cline{2-6}
-                                  & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{l|}{Risk} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{l|}{Risk per time} \\ \hline
-    \multicolumn{1}{|l|}{Feat. A} & 2 (2, 3)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
+                          & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{p{0.13\paperwidth}|}{\acl{cof} (\acs{cof})} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{p{0.13\paperwidth}|}{Change of Failure over time} \\ \hline
+    \multicolumn{1}{|l|}{Feat. A} & 2 (B, C)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
     \multicolumn{1}{|l|}{Feat. B} & 0                              & 3                          & 40 \%                     & 5  days                   & 8                                  \\ \hline
-    \multicolumn{1}{|l|}{Feat. C} & 1 (5)                          & 5                          & 25 \%                     & 2  days                   & 12.5                               \\ \hline
+    \multicolumn{1}{|l|}{Feat. C} & 1 (E)                          & 5                          & 25 \%                     & 2  days                   & 12.5                               \\ \hline
     \multicolumn{1}{|l|}{Feat. D} & 0                              & 4                          & 15 \%                     & 1  day                    & 15                                 \\ \hline
     \multicolumn{1}{|l|}{Feat. E} & 0                              & 4                          & 45 \%                     & 6  days                   & 7.5                                \\ \hline
     \end{tabular}
-    \end{table}
+    \end{table*}
 
     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 describes the number of features that are depending on that specific feature, and are derived from the dependency graph.
+    In general the dependency of the features is inherited from the hierarchical structure that is made in the feature definition step.
+
+    The comparison table has a 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.
-    This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D.
-    The risk that is cleared by E is 45 \% which is significantly less than the combined 65 \% of A, C and D.
-    Due to the limited scope of this thesis, it is not possible to give a good metric for determining risk and time.
+
+    The \ac{cof} per time score is calculated by dividing the \ac{cof} score with the time score.
+    The \ac{cof} score indicates the likeliness of unforeseen difficulties during the implementation of the feature.
+    The time score is an estimation about the required time for implementation.
+    This time score is strongly connected with the \emph{Cost of change}, but for readability I chose to refer to time instead.
+    Due to the limited scope of this thesis, it is not possible to give a good metric for determining \ac{cof} and time.
     Nevertheless, it is strongly advised that the developer defines some metric that fits his project best.
 
-    With a completed table, the order of implementation of features is determined by the following rules:
+    It seems logic to always implement the feature with the highest \ac{cof}, but it is possible that the combined \ac{cof} of multiple features is higher for the similar time investment.
+    This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D.
+    The \ac{cof} for E is 45 \% which is significantly less than the combined 65 \%\footnote{This is not a valid approach to calculate the combined chance, but suffices for the goal of this example.} of A, C and D.
+
+    With a completed comparison table, the order of implementation for the features is determined by the following rules:
     \begin{enumerate}
         \item Features that are dependencies of others must be implemented first.
         \item Features that complete more system test than other features when implemented have priority.
-        \item Features with the higher \emph{risk per time} score than other features have priority.
+        \item Features with the higher \emph{\ac{cof} per time} score than other features have priority.
     \end{enumerate}
-    The rules are applied in order, if one rule reduces the set to a single feature to implement the rest of the rules are skipped.
+    The rules are applied in order. 
+    If one rule reduces the set to a single feature, the rest of the rules are skipped.
     The third rule is a sorting rule, and the feature that fits best is implemented.
     In case of a draw or in special cases the developer decides what feature to implement next.
 
     Looking at an example of 5 features:
-    As seen in \autoref{fig:feature_dependency}, Features B and C are dependent on feature A.
-    Feature D does not have any dependency connections, and feature E is dependent on C.
+    As shown in \autoref{fig:feature_dependency}, features B and C depend on feature A;
+    feature D does not have any dependency connections;
+    and feature E is dependent on C.
     Together with the information in \autoref{tab:feature_selection}, the order of implementation is:
     \begin{description}
         \item[Feature A:] has two features that are dependent on this feature, more than any other.
-        \item[Feature C:] has one feature that is dependent on this feature, most dependencies after A is implemented.
-        \item[Feature D:] has the same number of tests as E, but D has a significant higher risk per time score than E
+        \item[Feature C:] has one feature that is dependent on this feature, most dependees after A is implemented.
+        \item[Feature D:] has the same number of tests as E, but D has a significant higher \ac{cof} per time score than E
         \item[Feature E:] has the most number of tests.
         \item[Feature B:] only one left to be implemented.
     \end{description}
     Note that this example assumes that nothing changes.
     In case of a feature not being feasible during the implementation, the design has to be reviewed.
-    This also means that the dependency graph and comparison table change, resulting in a different order of implementation.
+    This also means that the dependency graph and comparison table change, possibly resulting in a different order of implementation.
 
-\subsection{Rapid Development Cycle}
+\subsection{Rapid Development}
 Each iteration of this rapid development cycle implements one complete feature.
 The feature that is implemented is selected in the prior feature selection step.
 The goal of this step is to lay the foundation for the development of the feature.
@@ -276,7 +293,7 @@ The set of detail elements is a collection of design aspects that are added to i
 These detail elements can represent behavior, parasitic elements, or components.
 How these detail elements are implemented and what the basic model consists of is based on the initial design of the selected feature.
 
-The initial design of the feature is similar to the system wide approach in \autoref{sec:se_initial_design}.
+The initial design of the feature is similar to the system-wide approach in \autoref{sec:se_initial_design}.
 It consists of a design space exploration, but with more detail, which is possible as the feature is significantly smaller than the complete system.
 From the design space exploration, the developer selects the optimal design choice for the current feature.
 For this design choice, a design document is made that illustrates the rough shape and dynamics of the implementation.
@@ -288,60 +305,61 @@ In general, the basic elements should only represent dominant and essential beha
 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.
-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.
+In the end, the developer decides which states are required and implements them in the basic model.
+All the elements that are part of the initial design but are not part of the basic model are classified as the detail elements.
 
 Lets take a motorized double inverted pendulum for example, which consists of two arms with motorized joints.
 Both pendulum arms are dominant energy states.
 The electrical motors have also internal states, but store significantly less energy than the pendulum arms.
 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.
+The dynamic behavior, motor characteristics, resistance, or gravitational force are examples of detail elements to be added to increase the detail.
 
-\subsection{Variable Detail Approach}
-With the variable detail approach the basic model is developed into a refined model of the feature.
-This is done by implementing the detail elements over the course of multiple iterations.
-To determine the order of implementation of these elements the approach for the order of features from \autoref{sec:feature_selection}.
+\subsection{Variable-Detail Approach}
+With the variable-detail approach the basic model is developed into a refined model of the feature.
+This is done by adding the detail elements over the course of multiple iterations.
 Each iteration produces a new model with more detail than the previous.
 The newly added detail is evaluated by performing the tests that were defined during the rapid development cycle.
 \begin{figure}
     \centering
     \includegraphics[width=8.5cm]{graphics/test_flow_graph.pdf}
-    \caption{Decision flowchart to follow for failed tests on each detail level.}
+    \caption{Decision flowchart to follow for failed tests on each detail level.
+    Decision tree starts at the top left rectangle.
+    Depending on the questions, the next step of action is to continue with the design or review the design.}
     \label{fig:test_flow_graph}
 \end{figure}
 Not all tests are expected to succeed from the start, as not all details are implemented.
-For example, if the internal resistance of a electric motor is not yet implemented in the model, the motor can draw an unlimited current, and this would exceed the current draw specifications of the motor.
-The decision flowchart in \autoref{fig:test_flow_graph} in determines whether the design must be reviewed or can continue on a failed test.
+For example, if the internal resistance of a electric motor is not yet implemented in the model, the motor can draw unlimited current, and this would exceed the maximum current draw of the system.
+The decision flowchart in \autoref{fig:test_flow_graph} determines whether the design must be reviewed or can continue on a failed test.
 The decisions are made with the following questions:
-\begin{itemize}
-    \item Passed Before? The current test of the current design failed, but was there a previous detail level where it passed?
-    \item Expected to fail? Does the test fail as a direct result from the added detail and was that intentional?
-    \item Expected to pass? Should the added detail to the model result in a pass of the test?
-    \item Will pass in future? Is there an element that will be implemented that results in a pass of the test?
-\end{itemize}
+\begin{description}
+    \item[Passed Before?] The current test of the current design failed, but was there a previous detail level where it passed?
+    \item[Expected to fail?] Does the test fail as a direct result from the added detail and was that intentional?
+    \item[Expected to pass?] Should the added detail to the model result in a pass of the test?
+    \item[Will pass in future?] Is there an element to be implemented that results in a pass of the test?
+\end{description}
 In the case that the implementation of a detail element fails multiple times, the developer has to investigate if implementing the feature is still feasible.
 This could result in a redesign of the feature or system.
 When and how this decision has to be made differs per situation and is outside the scope of this thesis.
-The developer must evaluate if there are feasible alternatives left for this element, feature or system, and apply these alternative if possible.
+The developer must evaluate if there are feasible alternatives left for this element, feature or system, and apply these alternatives if possible.
 
-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.
+When all detail elements are implemented; all tests pass; 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{Summary of Design Plan}
 \begin{marginfigure}
     \centering
     \includegraphics[width=6cm]{graphics/design_flow_analysis.pdf}
-    \caption{Combined design plan, based on the \ac{ridm} and the Waterfall model.}
+    \caption{Combined design plan, based on the \ac{se} and \ac{ridm} approach.}
     \label{fig:design_plan_analysis}
 \end{marginfigure}
-The waterfall model from \ac{se} and the \ac{ridm} \autocite{broenink_rapid_2019} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
-The first five steps of the design process form the preparation phase: problem description, specifications, initial design, feature definition, and test protocol.
-The initial design step creates a holistic design based on the prior problem description and specifications step.
+The steps from \ac{se} and the \ac{ridm} are combined to create the design plan as shown in \autoref{fig:design_plan_analysis}.
+The first five steps of the design process form the preparation phase: problem description, requirements, initial design, feature definition, and test protocol.
+The initial design step creates a holistic design based on the prior problem description and requirements 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 last step of the preparation phase is the test protocol step, where the tests are defined to monitor the design process and validate that the system meets the specifications.
-The development cycle consists of the feature selection, rapid development, and variable detail steps.
-These three steps are applied to each feature in the initial design individually.
+The last step of the preparation phase is the test protocol step, where the tests are defined to monitor the design process and validate that the system meets the requirements.
+The development cycle consists of the feature selection, rapid development, and variable-detail steps.
+These three steps are applied to each feature in the system 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.
@@ -349,5 +367,5 @@ 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.
+However, if features prove to be infeasible, some steps have to be revisited.
 

content/background.tex

@@ -48,18 +48,23 @@ If the tests show that the added detail is not conform the requirements, the add
 When the added detail passes the tests, the process is repeated to add more detail.
 The variable-detail approach is finished when all the tests are passed and all the detail is added.
 
-\subsection{Preparation}
+\subsection{Preparation steps}
 Although the \ac{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 partitioning the functionality of the system, such that features can be implemented and tested individually.
+The rapid development cycle requires a list of features that can be implemented and tested individually.
+These features are gained by partitioning the functionality of the system.
+
 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 \ac{ridm} states that critical features must 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.
 
+Following the feature separation step is the system test protocol.
+The goal of this step is to describe how the requirements of the system are tested.
+These tests can cover a single feature or multiple features.
+
 \begin{marginfigure}
     \centering
-    \includegraphics[width=66mm]{graphics/design_flow.pdf}
+    \includegraphics[width=55mm]{graphics/design_flow.pdf}
     \caption{Combined design plan, where the first three steps are based on the \ac{se}-approach and the other four steps are taken from the \ac{ridm} \autocite{broenink_rapid_2019}}
     \label{fig:design_flow}
 \end{marginfigure}
@@ -70,5 +75,5 @@ To meet this requirement, a linear set of steps from problem description to init
 These three steps are shown at the top of \autoref{fig:design_flow} in the \acl{se} group.
 The steps show some similarity with the first steps of a V or Waterfall model.
 
-The requirements and initial design the four steps of \ac{ridm}.
+The requirements and initial design are used in the four steps of \ac{ridm} continue the design process.
 These four steps are grouped at the bottom of \autoref{fig:design_flow}.

graphics/design_flow.tex

@@ -1,31 +1,47 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
-\usetikzlibrary {arrows.meta,positioning}
-\tikzset{nodes={text height=.7em, text width=2.8cm, align=center,
+\usetikzlibrary {arrows.meta,positioning,calc,math}
+\tikzset{nodes={text height=.7em, text width=2.7cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}
 
+\pgfdeclarelayer{bg}
+\pgfsetlayers{bg,main}
+
 \begin{document}
-\begin{tikzpicture}[on grid,y=1.2cm,x=3.2cm]
-    \draw[fill=lightgray] (-1.7cm , 0.5cm) rectangle (4.9cm, -2.8cm);
-    \draw[fill=lightgray] (-1.7cm,-3cm) rectangle (4.9cm, -7.2cm);
+\begin{tikzpicture}[on grid,y=1.2cm,x=2.9cm]
+\def\rectoffset{-1.2mm,2.5mm};
+\def\rectoffsetleft{-2.90cm,0cm};
+\def\textoffset{2.9cm,0cm};
+\def\phasegroup(#1,#2,#3){%
+    \begin{scope}[nodes={draw=none, fill=none,text height={}}]
+        \coordinate (a) at ($(#1.north west)+(\rectoffset)$){};
+        \coordinate (b) at ($(#2.south east)-(\rectoffset)-(\rectoffsetleft)$){};
+        \draw[fill=lightgray] (a) rectangle (b);
+        \node[anchor=center] at ($(#1)+(\textoffset)$) {#3};
+    \end{scope}
+    };
     \node (pd) {Problem Description};
     \node (sp)[below=1 of pd]  {Requirements};
     \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 (tp)[below=1 of fs]  {Test Protocol};
+    \node (ss)[below=1 of tp]  {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};
     \path[->] (pd) edge (sp)
               (sp) edge (id)
               (id) edge (fs)
-              (fs) edge (ss)
+              (fs) edge (tp)
+              (tp) edge (ss)
               (ss) edge (rd)
               (rd.east) edge[bend right] (va)
               (va) edge[bend right] (ss.east);
-    \draw (3.4cm,0cm) node[draw=none, fill=none,text width=2.7cm] (wf) {Systems Engineering};
-    \node (ridm)[right=1 of fs, fill=none, draw=none] {Rapid Iterative Design Method};
+    \begin{pgfonlayer}{bg}
+        \phasegroup(pd,id,Systems Engineering);
+        \phasegroup(fs,rd,Rapid Iterative Design Method);
+    \end{pgfonlayer}
 \end{tikzpicture}
 \end{document}

graphics/design_flow_analysis.tex

@@ -11,7 +11,7 @@ draw=black!50, thick, font=\footnotesize, fill=white},
     \draw[fill=lightgray] (-1.7cm, 1.5cm) rectangle (1.7cm, -5.3cm);
     \draw[fill=lightgray] (-1.7cm,-5.5cm) rectangle (5cm, -9.2cm);
     \node (pd) {Problem Description};
-    \node (sp)[below=1 of pd]  {Specifications};
+    \node (sp)[below=1 of pd]  {Requirements};
     \node (id)[below=1 of sp]  {Initial Design};
     \node (fs)[below=1 of id]  {Feature Definition};
     \node (tp)[below=1 of fs]  {Test Protocol};

graphics/model_versions.tex

@@ -2,7 +2,7 @@
 \documentclass{standalone}
 \usepackage{tikz}
 \usepackage{siltex}
-\usetikzlibrary {arrows.meta,positioning,calc,math}
+\usetikzlibrary{arrows.meta,positioning,calc,math}
 \tikzset{nodes={text height=.6em, text width=2.5cm, align=center,
 draw=black!50, thick, font=\footnotesize, fill=white},
 >={Stealth[round,sep]}, rounded corners, semithick}
@@ -16,8 +16,8 @@ draw=black!50, thick, font=\footnotesize, fill=white},
 \def\textoffset{-2.5cm,0cm};
 \def\modelgroup(#1,#2,#3){%
     \begin{scope}[nodes={draw=none, fill=none,text width={},text height={}}]
-        \node (a) at ($(#1.north west)+(\rectoffset)+(\rectoffsetleft)$){};
-        \node (b) at ($(#2.south east)-(\rectoffset)$){};
+        \coordinate (a) at ($(#1.north west)+(\rectoffset)+(\rectoffsetleft)$){};
+        \coordinate (b) at ($(#2.south east)-(\rectoffset)$){};
         \draw[fill=lightgray] (a) rectangle (b);
         \node[anchor=center] at ($(#1)!0.5!(#2)+(\textoffset)$) {#3};
     \end{scope}

graphics/test_flow_graph.tex

@@ -14,11 +14,11 @@ draw=black!50, thick, fill=white, font=\footnotesize},
     block/.style={rectangle, minimum height=4em, text width=4em},
     cloud/.style ={draw=red, thick, ellipse,fill=red!20, minimum height=2em}]
 
-    \node[block] (ft) {Failed Test};
+    \node[block] (ft)[fill=lightgray] {Start:\\Failed Test};
     \node[decision] (pb)[below = 1 of ft] {Passed Before?};
     \node[decision] (ep)[below = 1 of pb] {Expected to pass?};
     \node[decision] (ef)[right = 1 of pb] {Expected to fail?};
-    \node[block]  (cont)[below = 1 of ef] {Continue};
+    \node[block]  (cont)[below = 1 of ef] {Continue, add next detail};
     \node[decision] (fu)[right = 1 of cont] {Will pass in future?};
     \node[block]   (res)[below = 0.8 of cont] {Review Design};
     \begin{scope}[nodes={draw=none, fill=none, midway,text width={}}]

include

@@ -1 +1 @@
-Subproject commit 84c052f510e74f7fc101c7440b1cc48ffbde7387
+Subproject commit 100951d197953549c8fa1d3d143b4e714c4525df

report.tex

@@ -1,9 +1,7 @@
 \documentclass[english,titlepage,nomath,nopackage,oneside]{siltex-book}
 \include{include/preamble}
 
-\newcommand{\ridm}{\ac{ridm} }
-
-\title{Title}
+\title{}
 \subtitle{Thesis Report}
 \course{}
 \faculty{\large Electrical Engineering, Mathematics and Computer Science}