Add time comparison

content/case_evaluation.tex

@@ -1,62 +1,48 @@
 %&tex
-\chapter{Case Evaluation}
+\chapter{Case Study: Evaluation}
 \label{chap:case_evaluation}
 
-\section{Preparation Phase}
-\subsection{One-man development team}
-The case study was performed by me, as a single developer.
-Against all expectations, this one-man development team made the preparation phase more difficult instead of easier.
-The goal of the problem description and the specifications step is to get the stakeholders on the same line \autocite{shafaat_exploring_2015}.
-This involves creating agreed-upon requirements for the system, but with only one stakeholder, this agreement is implicit.
-Moreover, it undermines the incentive of the problem description and specifications step.
-Part of this is that there is no penalty for future reviews of the specifications, as I already agreed.
 
-Furthermore, specific details and decisions were often made subconsciously, while I was commuting, waiting in line, or even showering.
-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{Time Investment}
+        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.
+        As evaluated in \autoref{sec:case_featuredefinition_evaluation}, the proposed design method for the Feature Definition was not feasible.
+        Solving this problem resulted in a delay of seven days.
+        The second development cycle experienced a delay of four days.
+        This was a underestimation of the time needed to complete the step.
+        \begin{figure}
+            \centering
+            \includegraphics{graphics/time_table.pdf}
+            \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.
+        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.
 
-\subsection{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.
+        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.
 
-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{One-man development team}
+        The case study was performed by me, as a single developer.
+        Against all expectations, this one-man development team made the preparation phase more difficult instead of easier.
+        The goal of the problem description and the specifications step is to get the stakeholders on the same line \autocite{shafaat_exploring_2015}.
+        This involves creating agreed-upon requirements for the system, but with only one stakeholder, this agreement is implicit.
+        Moreover, it undermines the incentive of the problem description and specifications step.
+        Part of this is that there is no penalty for future reviews of the specifications, as I already agreed.
 
-\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, specific details and decisions were often made subconsciously, while I was commuting, waiting in line, or even showering.
+        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}.
 
-            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.

content/case_experiment_feature_definition.tex

@@ -52,6 +52,7 @@
         \end{figure*}
 
     \subsubsection{Evaluation}
+    \label{sec:case_featuredefinition_evaluation}
         Even though there is a feature definition that can be used in the next step, there remain a couple of difficulties.
         There is still a clear separation between features and components.
         And the single level of components makes it impossible to depict the dependencies between components.

graphics/time_table.tex

@@ -0,0 +1,27 @@
+\documentclass{standalone}
+\usepackage{tikz,pgfplots}
+\usepackage{siltex}
+\usetikzlibrary{arrows.meta,positioning}
+\pgfplotsset{compat=1.17}
+\begin{document}
+\begin{tikzpicture}
+\begin{axis}[
+    xbar=-3mm,
+    bar width=4mm,
+    xmin=0,
+    xmax=21,
+    width=85mm,
+    height=75mm,
+    enlarge y limits=0.15,
+    legend style={at={(0.98,0.95)},
+        anchor=north east,legend columns=-1},
+    xlabel={Days},
+    symbolic y coords={Software Development,Development Cycle 2,Development Cycle 1,Test Protocol,Feature Definition,Initial Design,Specifications,Problem Description},
+    ytick=data,
+]
+    \addplot[draw=red,fill=red!40] coordinates {(2,Problem Description) (3,Specifications) (3.5,Initial Design) (13,Feature Definition) (0.5,Test Protocol) (3,Development Cycle 1) (17,Development Cycle 2) (20,Software Development)};
+    \addplot[draw=blue,fill=blue!40] coordinates {(2,Problem Description) (3,Specifications) (5,Initial Design) (6,Feature Definition) (1,Test Protocol) (3,Development Cycle 1) (13,Development Cycle 2)};
+\legend{Time Spend,Time Planned};
+\end{axis}
+\end{tikzpicture}
+\end{document}