WIP: reflection

content/case_evaluation.tex

@@ -53,15 +53,3 @@
         Making structured documentation of these decisions at a later point in time without missing any of them was impossible.
         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.
-        

content/reflection.tex

@@ -2,7 +2,7 @@
 \chapter{Design Method Evaluation}
     \label{chap:reflection}
 
-    \section{Factorizing features}
+    \section{Elements of a Feature}
         During the course of this study, the concepts of specifications, components and functions are added to the design method.
         As explained in the background chapter, having an approach to determine specifications is a crucial concept of a design process.
         Because \ac{ridm} did not include such an approach, a \ac{se} approach was added.
@@ -34,64 +34,62 @@
 
         What is interesting about this new insight is that it helps to understand the difference with the case study performed by \textcite{broenink_rapid_2019}.
         The hardware components used by Broenink and Broenink was a mini-segway, which was designed for a student project.
-        The requirement of this mini-segway is that has to balance, drive, and steer.
+        The requirement for this mini-segway to be able to balance, drive and steer, is inherited directly from the student project.
         Causing the requirements and components to be implicitly defined in their case study.
         Therefore, the function that needs to be implemented, fits very well within the definition of a feature.
 
-    \section{Information Flow}
-        %% Aanknopen op het vorige verhaal?
-        Although team members improve the information flow within a design team, it does not guarantee that all information is available.
-        Throughout the case study, more and more information becomes available.
-        During the initial design, new insight was gained that would have been useful during the problem description and the specifications step.
-        And while making the tests, it became clear that the specifications were incomplete.
-        It is possible to review the specifications step, but the succeeding steps have to be redone as well. 
-        During the case study, I decided to continue with the design due to the scope of the research, namely the development design cycle was.
+    \section{Model and Design Relation}
+        The \ac{ridm} as well as the design method in this study fail to make a explicit distinction between the model and the design.
+        %Hierdoor wordt de harde grens hier tussen onduidelijk.
+        This implicitly caused the model itself to dictate the design.
+        %Een goed model voldoet namelijk aan het volgende ...
+        According to \textcite{stachowiak_allgemeine_1973}, three general properties apply for a model.
+        First is that the model is always representative to its original; 
+        second, the model must only include attributes of its original that are relevant to the respective developer or user;
+        and third, the model must be pragmatic to the original, meaning that models are an adaptation of the original with respect to a specific purpose.
+
+        %Dus als je design verder ontwikkeld dan moet je dus schakelen tussen models.
+        These properties coincide with the different modelling approaches used during the case study.
+        The dynamic models did not start directly with 3D physics as it would conflict with the second property.
+        However, as the design becomes more refined, it could not be represented with only basic kinematics calculations. 
+        The step to 2D, and later 3D physics, is made such that the model still represents the design.
+        Parallel to the dynamics model, a CAD drawing was used to model the shape of the hardware components.
+        Simply because models represent the design for a different purpose.
 
-        Dealing with these design changes is a known weakness of the waterfall model.
-        Many publications give credit to \textcite{royce_managing_1970}, for the concept of the waterfall model.
-        Where they refer to the simple 5 to 8 step design concept, similar to the one in \autoref{sec:SE}.
-        What these publications fail to address is that \textcite{royce_managing_1970} says: "I believe in this concept, but the implementation described above is risky and invites failure."
-        Followed by multiple steps of improving the waterfall model.
-        Royce adds a complete design step, loads of intermittent testing and documentation, and the instruction to "Do it twice".
-        On initial thought this feels as a disproportionate amount of extra work.
-        Especially since the current design plan already includes small feedback cycles.
-        However, the small feedback cycles only apply to the current design, and do not provide information about the current design direction.
-        Thus, the current level of detail might work, passing the tests of the current cycle does not guarantee a successful implementation of the design.
-        Based on the evaluation, it was often difficult to justify the design decisions as there was insufficient information.
-        A simple proof of concept would improve the information about the direction of the design, required resources and the feasibility of the project.
-        Although this requires additional work, it is very likely that it improves the projects feasibility and thus reducing the risks of the project.
+        Even though the models in the case study satisfy the properties as described above, it has a significant implication for the current design method.
+        As the model is used to represent the current design, switching to a different modelling approach changes the representation of the design as well.
+        From the case study it is possible to identify two direct consequences.
+        The first is that there is discrepancy for the required effort between a design change and the corresponding model update.
+        This can be seen in the case study when the model was reconstructed with 3D physics but the design did not change.
+        Resulting in a couple of days of work spend reconstructing the model, without significant progress in the design.
+        The second consequence is that the design got split up over the dynamics model and the CAD drawing:
+        Both included the kinematics of the SCARA;
+        the controller and stepper behavior was defined in the dynamics model;
+        and the shapes of the components was defined in the CAD drawing.
+        Such a subdivision of details across different models is, without any doubt, undesired.
 
-    \section{Development Cycle}
-        \subsection{Design and model}
-            Prior to the case study I expected the model to be the design.
-            So when the level of detail of the design is increased, this is achieved by expanding the model with more detail or components.
-            Resulting in different versions of a single model where each version has more detail than the previous one.
-            However, during this development a 2D dynamics model, 3D dynamics model and a 3D component model.
-            Although these models have components in common, they are not compatible.
-            Therefore, adding detail to the design requires two or three models to be updated.
 
-            Furthermore, the step from 2D to 3D physics was in no means a small increment in detail.
-            The first four levels of detail, as describe in the previous section, all were implemented in with two dimensions.
-            As the later details required a third dimension, all the detail was directly converted from 2D into 3D.
-            This is a large amount of work, introducing a high cost when the conversion fails.
-            Moreover, it creates a new 3D physics model, parallel to the 2D physics model instead of adding detail to the latter.
-            Alternative approaches for 3D model physics could be:
-            \begin{itemize}
-                \item Ignore 2D and start implementation in 3D modelling.
-                \item Retrace all incremental detail steps of the 2D model in a 3D model.
-            \end{itemize}
-            Both options are not ideal, the first one does not allow a simple basic model and the second approach redoes work.
-            The advantage of starting with 3D is that allows for a continuous development of one model, instead of switching the complete model.
+    \section{Information Flow}
+        %% Aanknopen op het vorige verhaal?
+        %Although team members improve the information flow within a design team, it does not guarantee that all information is available.
+        %Throughout the case study, more and more information becomes available.
+        %During the initial design, new insight was gained that would have been useful during the problem description and the specifications step.
+        %And while making the tests, it became clear that the specifications were incomplete.
+        %It is possible to review the specifications step, but the succeeding steps have to be redone as well. 
+        %During the case study, I decided to continue with the design due to the scope of the research, namely the development design cycle was.
+
+        %Dealing with these design changes is a known weakness of the waterfall model.
+        %Many publications give credit to \textcite{royce_managing_1970}, for the concept of the waterfall model.
+        %Where they refer to the simple 5 to 8 step design concept, similar to the one in \autoref{sec:SE}.
+        %What these publications fail to address is that \textcite{royce_managing_1970} says: "I believe in this concept, but the implementation described above is risky and invites failure."
+        %Followed by multiple steps of improving the waterfall model.
+        %Royce adds a complete design step, loads of intermittent testing and documentation, and the instruction to "Do it twice".
+        %On initial thought this feels as a disproportionate amount of extra work.
+        %Especially since the current design plan already includes small feedback cycles.
+        %However, the small feedback cycles only apply to the current design, and do not provide information about the current design direction.
+        %Thus, the current level of detail might work, passing the tests of the current cycle does not guarantee a successful implementation of the design.
+        %Based on the evaluation, it was often difficult to justify the design decisions as there was insufficient information.
+        %A simple proof of concept would improve the information about the direction of the design, required resources and the feasibility of the project.
+        %Although this requires additional work, it is very likely that it improves the projects feasibility and thus reducing the risks of the project.
 
 
-    \section{Models}
-        Where I assumed to end up with one model of one design, the result is a design based on four models.
-        One model is the CAD drawing and another one models the dynamic behavior.
-        However, during the development the dynamic behavior has evolved through three different modeling approaches.
-        Switching to a new modeling approach becomes unavoidable, when the newly added detail cannot be represented in the current approach.
-        In the case of the SCARA, to model the first levels of detail a 2D physics approach on a single plane sufficed.
-        Later in the design, the end-effector, which moved on the plane, had to be moved perpendicular to that 2D plane.
-        Moving the end-effector in this third dimension also moves the center of mass out of the plane.
-        Taking into account that the SCARA would be suspended with wires inside of this 2D plane, moving the mass out of this plane could result in unwanted rotation of the SCARA.
-        Based on that, I decided that a 3D physics model is required to represent that behavior.
-        To make this switch the dynamics of the SCARA, which have been modeled in 2D, must be implemented into a 3D model as well.

include

@@ -1 +1 @@
-Subproject commit c481ca012ef63f75bae07a0174d5098a4623e8e9
+Subproject commit a5283462a0203ba48df468afcbb9a55f70acb42a