fixup! fixup! fixup! fixup! fixup! fixup! fixup! fixup! Add analysis

content/analysis.tex

@@ -3,7 +3,7 @@
 \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 can be used in the case study.
+The goal is to have 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}.
@@ -14,7 +14,7 @@ The steps that are introduced by \ridm are covered in more detail.
     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 will have only one stakeholder, the author.
+    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.
 
@@ -32,7 +32,7 @@ The steps that are introduced by \ridm are covered in more detail.
     \subsection{System Requirements}
         The system requirements are derived from the problem definition, and describe the characteristics of the system.
         As these characteristics form the foundation of the system, the requirements must be defined without any ambiguity, vagueness or complexity.
-        The requirements will be written according to the \ac{ears} \autocite{mavin_easy_2009}.
+        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.
         Any issues, like ambiguity, in the requirements, propagate through these subsystems.
@@ -43,7 +43,7 @@ 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 can be used in the next phase of the design.
+        This step results in one initial design that 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.
@@ -62,7 +62,7 @@ The steps that are introduced by \ridm are covered in more detail.
 
 \subsection{Feature Definition}
     \label{sec:featuredefinition}
-    During the feature definition, the system will be split into features as preparation for the rapid development cycle and the variable-detail approach.
+    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.
     Together with the definition of the features, the requirements are divided along the features as well.
@@ -75,34 +75,19 @@ The steps that are introduced by \ridm are covered in more detail.
     Another type of dependency is when the implementation influences other features.
     In this case, if the implementation of one feature changes, it requires a change in the other features.
     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, the end-effector will be different than approaching the item vertically.
+    When the robot arm approaches an item horizontally, it requires a different end-effector than approaching the item vertically.
 
     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.
 
 \subsection{Feature Selection}
     \label{sec:feature_selection}
-    The rapid development cycle does not specify which feature should be implemented first, even though the order of implementation does change the feasibility of the complete development.
+    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.
     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.
     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.
-
-    For the design plan, the order of implementation of features will be 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.
-    \end{enumerate}
-    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 that within that feature multiple lower risk features can be finished.
-    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.
-    Nevertheless, it is strongly advised that the developer defines some metric that fits his project best.
-
     \begin{marginfigure}
         \centering
         \includegraphics[width=2.9cm]{graphics/feature_dependency.pdf}
@@ -123,6 +108,29 @@ The steps that are introduced by \ridm are covered in more detail.
     \multicolumn{1}{|l|}{Feat. E} & 0                              & 4                          & 45 \%                     & 6  days                   & 7.5                                \\ \hline
     \end{tabular}
     \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 describe 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.
+    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.
+    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:
+    \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.
+    \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 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.
@@ -134,9 +142,12 @@ The steps that are introduced by \ridm are covered in more detail.
         \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.
 
 \subsection{Rapid Development Cycle}
-Each iteration of this rapid development cycle will implement one complete feature.
+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.
 This foundation consists of a basic model, a set of detail elements and a list of tests.
@@ -156,7 +167,7 @@ A good starting point 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 should evaluate if states are required and implement them in the basic model.
+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.
 
 Lets take a motorized double inverted pendulum for example, which consists of two arms with motorized joints.
@@ -168,11 +179,38 @@ The dynamic behavior, motor characteristics, resistance, or gravitational force
 To finish this step 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 atleast one test.
+It is important that all the specifications are covered by at least one test.
 This relatively simple approach of testing is possible due to the limited scope of this thesis.
-For a complexer design, the testing should be automated.
-The \ac{atm} \autocite{jansen_automated_2019} is an interesting method to perform the testing of the models.
+For a complexer design, the testing needs to be automated.
+The \ac{amt} \autocite{jansen_automated_2019} is an interesting method to perform the testing of the models.
 However, at the time of writing, the software is in a proof of concept state and not usable for this thesis.
 
 \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}.
+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 for failed test results.}
+    \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.
+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}
+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.
+
+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.

graphics/test_flow_graph.tex

@@ -0,0 +1,37 @@
+%&tex
+\documentclass{standalone}
+%\usepackage[]{siltex}
+\usepackage{tikz}
+\usetikzlibrary {arrows.meta,graphs,positioning,shapes.geometric}
+\tikzset{nodes={text height=.7em, text width=1.7cm, align=center,
+draw=black!50, thick, fill=white, font=\footnotesize},
+>={Stealth[round,sep]}, rounded corners, semithick}
+
+\begin{document}
+\begin{tikzpicture}
+    [on grid,y=3.0cm,x=3.0cm, auto,
+    decision/.style={diamond, text width=4em,align=flush center, inner sep=1pt},
+    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[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[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={}}]
+        \path[->] (ft) edge (pb)
+                  (pb) edge node {no}  (ep)
+                  (ep) edge node {no}  (cont)
+                  (pb) edge node {yes} (ef)
+                  (ef) edge node {yes} (cont)
+                  (fu) edge node {yes} (cont);
+        \draw[->] (ep) |- node[near start] {yes} (res);
+        \draw[->] (ef) -| node[near start] {no} (fu);
+        \draw[->] (fu) |- node[near start] {no} (res);
+    \end{scope}
+\end{tikzpicture}
+\end{document}
+