mar/content/case_evaluation.tex

%&tex
\chapter{Case Study: Evaluation}
\label{chap:case_evaluation}

    \section{Result}
    \input{content/case_evaluation_result.tex}

    \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. For Development Cycle 1 three days were planned for the initial development, based on the outcome I decided to abandon this cycle. Therefore, no additional time was planned nor spend on the development.}
            \label{fig:time_spend}
        \end{figure}
        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 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.

        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.
        As explained in the previous section, I build a total of eight 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.
        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}.