fixup! fixup! Describe Method

content/case_method.tex

@@ -1,24 +1,32 @@
 %&tex
-\chapter{Case study Method}
+\chapter{Case Study: Method}
 \label{chap:case_method}
-The goal of this case study is to evaluta the design plan as presented in the previous chapter.
-The evalutation is done by developing a system according to the design plan.
-Ingeneral, the method of the case study follows all the steps of the design plan.
+The goal of this case study is to evaluate the design plan as presented in the previous chapter.
+The evaluation is done by developing a system according to the design plan.
+In general, the method of the case study follows all the steps of the design plan.
 Additionally, an evaluation protocol ensures that the development is evaluated consistently.
 The last important thing is a subject of design that is developed in the case study.
 The next sections present the evaluation protocol and the subject of design.
 
 \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 evaluation protocol ensures that the different steps, decisions and changes of the design are consistently evaluated.
+    This protocol contains a questionnaire and model validation.
+    The full questionnaire is administered during each step in the design plan.
+    It covers questions about the design process as well as the design plan.
+    The model validation is performed at the end of the development.
+    This validation is done by creating a physical prototype of the design and comparing the operation with the designed model.
 
-    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}.
+    \subsection{Questionnaire}
+        The questionnaire consists of two sets of questions.
+        The first set of questions is shown in \autoref{tab:prepost}.
+        This set consists of pairs of questions and focusses specifically on the execution of the design step.
+        Each pair embodies a theme, with one questions answered before, and the other question answered after the execution of the design step.
+        The goal of these pairs is to record the expected and planned execution with the results of the execution.
+        The second set of questions focusses on the described method of the design step.
+        These questions are shown in \autoref{tab:questionsmethod}.
+
+        To answer and record the questions consistently, there is a template document with these questions.
+        The document with the answers is stored in version control and is automatically typeset into a PDF document.
 
      \begin{table*}
         \caption{Table with questions to evaluate the steps. With corresponding questions ordered in pre and post step columns.}
@@ -38,13 +46,13 @@ The next sections present the evaluation protocol and the subject of design.
             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? \\
+            How many hours are required for the execution of the step? Also give a range in your uncertainty. & 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? \\
+            At the end of the step, what is the expected result? & Does the result match the description made pre-step? 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.\\
+            \textbf{What is the expected feasibility?} & \textbf{Was the expected feasibility of the implementation accurate?} \\
+            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 pre-step feasibility.\\
             \hline
         \end{tabular}
     \end{table*}
@@ -66,78 +74,46 @@ The next sections present the evaluation protocol and the subject of design.
         \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.
+    \subsection{Model validation}
+        The design plan focusses on the modelling of the system.
+        It is, however, not given that passing all the tests does also results in a working design.
+        If the tests are incomplete or complications in the design are overlooked, the design process is worthless.
+        Therefore, the model will be validated with a physical prototype of the design.
+        This shows whether the model is correct and whether all assumptions about the system are correct.
+        The prototype does not only show where the design process went wrong, it can also be used to improve the design plan to prevent these modeling problems.
 
 \section{Subject of Design}
 The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan.
 To ensure the best subject of design a list of requirements is composed.
-Based on this list the best subject of design is a "Tweet on a whiteboard writer", which will be referred to as system.
+Based on this list the best subject of design is a "Tweet on a whiteboard writer", which is referred to as system.
 Other subjects were considered, but did not meet the desired requirements.
 
 The most important requirement is that, while developing the system, the different aspects of the design plan are used.
 Taking into account that there is a limited time budget and that the system must be within the scope of the design plan, the set of possible subjects of design is slim.
-The time budget is set to 10 weeks of development and the system must have a dynamic system that can be controlled.
+The time budget is set to 10 weeks of development and the system must have a dynamic system that is actuated via a software controller.
 The tweet on a whiteboard fits within these requirement as it can have interesting dynamics and has multiple features.
-Although the system could be seen as a simple wall plotter with simple XY-movement, it has alternative implementations that achieve more complex XY-movement.
-%%%%%% Ligt toe dat er meerdere features zijn.
-
-    
-        \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}
+Although it is possible that the system is seen as a simple wall plotter with simple XY-movement, there are alternative implementations that achieve more complex XY-movement.
+This provides the required complexity and allows for different levels of detail needed for the variable detail approach.
+The system can be split into more than one feature, which is required to evaluate the rapid development cycle.
+One of the features is the XY-movement and other features are:
+    \begin{enumerate}
+        \item Lifting the marker from the board
+        \item Erasing: End effector manipulation
+        \item Changing color: Switching Marker
+        \item Speed increase
+    \end{enumerate}
+Similar to the XY-movement, these features have multiple implementations that add complexity to the system.
+This gives the possibility during the case study to go with a more or less complex design, allowing to fit the case study in the time budget without compromising the quality of evaluation.
 
-            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.
+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.
+It is expected that this set of tools is sufficient to construct a prototype of the tweet on a whiteboard system 
 
-            \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.
+Other options that were looked at was a 3D calibration system for a positioning system.
+This idea was rejected because the complexity originated from the required accuracy instead of the dynamics.
+In other words, choosing interesting dynamics would degrade the usability of the system.
+A peg-in-hole problem, was also considered briefly as well.
+But that is mainly a complex sensing and control problem, and not dynamically interesting.