Update evaluation of case

content/case_evaluation.tex

@@ -1,10 +1,8 @@
 %&tex
 \chapter{Case Study: Evaluation}
 \label{chap:case_evaluation}
-
-
     \section{Time Investment}
-        Prior to each step in the development I made an estimation on the workload of that particular step.
+        Prior to each step in the development, I made an estimation on the workload of that particular step.
         In \autoref{fig:time_spend} the planned and spend time on each step is plotted next to each other.
         Five of these steps were completed in the planned number of days.
         However, three steps required more time than expected.
@@ -18,20 +16,26 @@
             \caption{Overview of the planned and spend number of days for each step during the case study.}
             \label{fig:time_spend}
         \end{figure}
-        Furthermore, there is a significant difference between the planned number of days of the between the development cycles.
+        Furthermore, there is a significant difference between the planned number of days for both development cycles.
         Prior to the first development cycle I was not confident about the feasibility of the end-effector implementation.
-        Based on that, I decided to spend about three days on basic model of the end-effector to gain more information.
-        These three days let me to the conclusion that the end-effector was not feasible for this case study.
-        The second development cycle was significantly more feasible so I planned to spend two and a half week on the development.
-        This development was also three days for the basic model and another two weeks for the additional levels of detail.
+        Based on that, I decided to spend about three days on the basic model of the end-effector to collect more information.
+        This let me to the conclusion that the end-effector was too time-consuming for this case study.
+        For the second cycle, I also planned three days to create the basic model.
+        This time, the basic model was finished within a couple of hours.
+        Based this early success and prior experience, I planned an additional two weeks of development time for this cycle.
 
-        To create a functional prototype, writing software was unavoidable, even though it was not part of the design plan.
-        However, the time required to get to a basic software implementation too substantial to keep it out of the evaluation.
-        Especially when I take the quality and evaluation overhead in account.
-        The dynamic model was build up with different levels of detail including documentation for each level.
-        Furthermore, between the levels I also did the evaluation of the design process.
-        For the software, I skipped documentation and evaluation, as it would not contribute to the case study.
-        The code quality of the software is decent in my opinion but significantly lower than the quality of the dynamic models.
+        Although not directly part of the design method, I did build a prototype.
+        This consisted of acquiring and assembling the hardware, and writing software.
+        Acquiring and assembling the hardware took about two days.
+        This was mainly due to CoViD-19 restrictions which made part ordering and printing more challenging.
+        Without these restrictions I think it would it would be a day of work.
+        However, the time required to get the software to a viable state was four weeks.
+        Even though, the focus was not on the software, this timespan of four weeks is too significant to ignore.
+        Especially when the software is compared to the developed models.
+        In total I build eight competent models: a CAD drawing, one kinematics model, three 2D models and three 3D models.
+        Each of these models includes documentation and an evaluation of the design process.
+        The software, on the other hand, is in a bare minimum state; I skipped documentation and evaluation; and the code quality relatively low.
+        Still, the software was more time consuming than the hardware modeling and development.
 
     \section{One-man development team}
         The case study was performed by me, as a single developer.
@@ -46,3 +50,14 @@
         The social interaction within a design team stimulates this documenting process as it improves the recall and interpretation of information.
         It also improves the judgement and selection between design alternatives \autocite{lamb_221_2008}.
 
+    \section{Switching Modelling Language}
+        The initial idea of the development was to start with a basic model and extend that model by adding more detail.
+        Meaning that one design and one model would develop in parallel with each other.
+        However, the development of the SCARA resulted in four major model versions.
+        The basic model started with a kinematics model. 
+        To take the physics of the design into account, a 2D dynamics model was created.
+        Multiple steps of detail into the development, the 2D model was not adequate anymore.
+        Therefore, the design was remodeled with 3D physics.
+        Although this 3D physics model was able to implement the dynamic behavior, the modeling language was not suitable to design the shape of the mechanical components.
+        Resulting in a fourth model which represents the mechanical component design, in the form of a CAD drawing.
+