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

    \section{Reflection}
        In the following section, I will reflect on my own impact on the development.
        The preparation and development phase are discussed separately.

        \subsection{Preparation phase}
            During the preparation phase often I had difficulty with getting the required information.
            The information was often not specific enough or it it was overlooked.
            For the case of information not being specific, can be explained by the lack of stake-holders as explained in the previous section.
            Even though attempting to be thorough, requirements were never really specific.
            Furthermore, during the preparation information was often overlooked.
            Resulting in a situation where I needed information that should have been the result of a previous step.
            In most situations it was possible to continue with the execution of the step.
            However, during the test protocol step (\autoref{sec:test_protocol}) it was not possible to continue.

            One of the main causes that attribute to the information shortage is that I am relatively inexperienced in design.
            The experience that I have is a graduate course and two extracurricular projects. 
            Being inexperienced does definitely not make the design process easier.
            However, I think that more experience would improve the information situation, it would not solve the problem.
            The biggest issue is the linear approach of the waterfall model.
            A spiral model would be more appropriate, especially as each step results in more information that can improve the design.

        \subsection{Development phase}
            For the development phase I posses significantly more relevant experience compared to the preparation phase.
            Creating models is something that I really enjoy and this smooths the process significantly.
            Nevertheless, there is room for improvement in this system.
            Originally I attempted to create separate sub-models for each component.
            These sub-models could then be combined into larger models.
            For example, the SCARA and the cable bot both use two stepper motors.
            When I add detail to the stepper motor model, the SCARA and the cable bot would then be updated as well.
            However, the workflow to get this working is labor intensive, as each sub-model has to be updated manually.

            A workflow that enables easy combination and interchange of sub-models is beneficial with this design method.
            It makes it easy to evaluate the latest changes, by comparing them with previous versions.
            In addition, it makes it possible to lower the detail on some models during the development.
            The lower detail of the sub-models can improve the simulation speed significantly.
            And during the final test use the full detail to ensure that every thing is still functioning as expected.

        

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