Describe Method

content/case_method.tex

@@ -1,3 +1,129 @@
 %&tex
 \chapter{case method}
-\label{case_method}
+\label{chap:case_method}
+
+
+\section{Subject of Design}
+The choice in subject of design has a strong influcence on the evaluation of the design plan.
+A set of requirements is used to ensure that the optimal subject of design is selected.
+    
+        \subsection{Requirements}
+            The goal is to find a case study that can be used to evaluate the design method within a Master's Thesis.
+            Some requirements are defined to help the selection of a suitable case study.
+            To fit the design in the period of a Master's Thesis it should not require more than 10 weeks.
+            A fully-designed and constructed product is a nice result but is not required.
+            The case study can be terminated at the end of the period if all the elements of the design method have been sufficiently evaluated.
+
+            Although a finished product is not required, a partial prototype is part of the testing and validation procedure.
+            As the design method focuses on the physical component, a mechanical prototype is important.
+            The prototype would originally been constructed with the rapid prototyping facilities at the university.
+            However, the COVID-19 pandemic forced the university to close and to work from home.
+            This limited the rapid prototyping to DIY-tools and a 3D-printer.
+
+            To comply with the limited time and construction options it is tempting to go with a simple system.
+            Going for a simple system is not an option.
+            The goal of the design method is to reduce the complexity of the development.
+            Therefore, the case study should cover at least multiple features and interesting dynamics.
+            Multiple features allow for multiple design cycles.
+            Complex dynamics make multiple levels of detail possible.
+
+            \subsection{Tweet on a Whiteboard}
+            \label{sec:whiteboardwriter}
+            An example is for a system to be designed is a device that writes tweets on the white board.
+            That would be device that can write on white board.
+            This can be split in multiple features, with increasing complexity:
+            \begin{enumerate}
+                \item Moving the marker on the board: Simple XY-movement
+                \item Lifting the marker from the board: Z-movement
+                \item Erasing: End effector manipulation
+                \item Changing color: Switching Marker
+                \item Speed increase.
+                \item Direct input.
+            \end{enumerate}
+
+            The moving and change of color have multiple solutions, which satisfy the features requirement.
+            The complexity is also present in this example, the movement of the marker introduces multiple degrees-of-freedom.
+            Furthermore, the speed increase adds complexity as well.
+            The actuation of the system requires software.
+            However, instead of characters on the board it is possible to make basic figures, like squares and circles.
+            This minimizes the implementation of the software.
+
+            \subsection{Decision}
+                The preferred case study is the whiteboard writer in \autoref{sec:whiteboardwriter}.
+                The Peg-in-Hole problem is mainly a control problem instead of a mechanical challenge.
+                Therefore the Peg-in-Hole problem disqualifies as a good case study for goal of this Thesis.
+                The RTK Calibration is a good case study.
+                However, as it is a calibration device it has to be accurate.
+                It is expected that this abstracts the complex dynamics from the design space.
+                Overall the whiteboard writer gave more possibilities and is also a better demo.
+                Sending a tweet to a robot has never been a bad demo.
+
+    
+\section{Evaluation Protocol}
+    A survey is design to assess how the method is applied during the case study.
+    The survey specifies a list of questions.
+    All the questions will be adressed for each step in design plan.
+    Part of the questions will be answered before the step is performed.
+    The rest of the questions will be answered after the step is performed.
+    The questions are not soley to measure the effectiveness of the design method, but to investigate the usability as well.
+    To ensure the usable design plan, the step must feel intuitive and must not interfere with the workflow.
+
+    The duo questions, consisting of a before and after question are listed in \autoref{tab:prepost}.
+    The questions that focus on the design plan are listed in \autoref{tab:questionsmethod}.
+
+     \begin{table*}
+        \caption{Table with questions to evaluate the steps. With corresponding questions ordered in pre and post step columns.}
+        \label{tab:prepost}
+        \begin{tabular}{|p{0.35\paperwidth}|p{0.35\paperwidth}|}
+            \hline
+            \vspace{1mm} \large{Prestep}  & \vspace{1mm} \large{Poststep} \\
+            Questions prior to the execution of the step to set a baseline. & Questions after the execution of the step to check if the implementation met the expectations. In hind-sight, what should have been executed differently?\\
+            \hline 
+            \textbf{What was the previous step?} & \textbf{What will be the next step?} \\
+            Does this influence this step? Is this a review? & Moving forward or is a review required of previous step(s)? \\
+            \hline
+            \textbf{Describe the plan of action.} & \textbf{Explain any deviations from the plan of action.} \\
+            What is the next step going to be? How is it going to be executed? & What changed during the execution, what deviations where taken and why? \\
+            \hline
+            \textbf{What is the method of testing?} & \textbf{How did you test/validate the step?} \\
+            What is the protocol to review the result of this step? & How was the evaluation done? Did it reveal something new? \\
+            \hline
+            \textbf{What is the expected workload?} & \textbf{Was the workload different than expected?} \\
+            How many hours are required for the execution of the step? Also give a range in your incertainty. & How much time was invested in the step? Why was it more or less than expected? \\
+            \hline
+            \textbf{What is the expected result of the step?} & \textbf{Is the result as expected?} \\
+            At the end of the step, what is the expected result? & Does the result match the description made prestep? Why does it not match? \\
+            \hline
+            \textbf{What is the expected feasibility?} & \textbf{Was the expected feasibility of the implementation accurated?} \\
+            What are the problems you expect during implementation? Why? & Even if the implementation succeeded, the feasibility does not have to be 100\%. Give an estimate for the feasibility now that the implementation is finished. Explain the difference with the prestep feasibility.\\
+            \hline
+        \end{tabular}
+    \end{table*}
+
+    \begin{table*}
+        \caption{Table with questions to evaluate the design method itself}
+        \label{tab:questionsmethod}
+        \begin{tabular}{|p{0.35\paperwidth}|}
+            \hline
+            \textbf{Is this method a suitable approach for the hardware design?}\\
+            Are there aspects in the hardware design that is not covered by the method? Or is the method not suited at all for hardware? Why not? How to do it different? \\
+            \hline
+            \textbf{Does the method contain counter-intuitive steps?} \\
+            Are there steps that feel not optimal? Is it appealing to execute the step different? Is it just getting used to? Or really inefficient?\\
+            \hline
+            \textbf{What is the feasibility of this step in the method itself?} \\
+            Not the execution of the step, but the step itself. Are those steps realistic? How can the method be improved? Why? \\
+            \hline
+        \end{tabular}
+    \end{table*}
+
+   \subsection{Reporting}
+        To answer all these questions and record all the steps a template was made.
+        This template is a markdown-document that contains all the questions.
+        The filled in documents will be stored in a git-repository.
+        With continuous integration the documents will be merged to a single pdf.
+
+        The development of the hardware will be done in a separate git repository.
+        Each step will have its own issue. 
+        This issue has a description and a checklist for the evaluation.
+        Commits will be referenced to the issue, in that way all commits are grouped and can be tracked in the issue.