From 1e35132aa5eab6c8e054374b87525738547427a3 Mon Sep 17 00:00:00 2001 From: Wouter Horlings Date: Wed, 27 Jan 2021 16:03:02 +0100 Subject: [PATCH] Add time comparison --- content/case_evaluation.tex | 94 ++++++++----------- .../case_experiment_feature_definition.tex | 1 + graphics/time_table.tex | 27 ++++++ 3 files changed, 68 insertions(+), 54 deletions(-) create mode 100644 graphics/time_table.tex diff --git a/content/case_evaluation.tex b/content/case_evaluation.tex index b6e867b..060c345 100644 --- a/content/case_evaluation.tex +++ b/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. diff --git a/content/case_experiment_feature_definition.tex b/content/case_experiment_feature_definition.tex index b2096e3..d4951c6 100644 --- a/content/case_experiment_feature_definition.tex +++ b/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. diff --git a/graphics/time_table.tex b/graphics/time_table.tex new file mode 100644 index 0000000..fded169 --- /dev/null +++ b/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}