mar/content/case_evaluation.tex

%&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.
        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.

        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.

    \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.

        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}.