mar/content/casestudy.tex

%&tex
\chapter{Case Study: Whiteboard writer}
\label{chap:casestudy}
    \section{Monitoring}
        A survey is design to assess how the method is applied during the case study.
        The survey specifies a list of questions.
        All the questions will be adressed for each step in \autoref{fig:flowgraph}.
        Part of the questions will be answered prior to the step.
        The rest of the questions will be answered after the step.
        The questions are not soley to measure the effectiveness of the design method, but as well to investigate the usability.
        For a good usability the step feels intuitive and does not interfere with the workflow.

        Important is that these answers will be used to improve the design method for the next cycle.
        Resulting in a better suited method at the end of the development.
        This survey will be evaluated as well in each step.
        Because it is expected that there are points of interest that are looked over.
        It could be that a step is split in multiple ones or that questions are added during the case study.

        \autoref{tab:prepost} contains the set of paired questions.
        One question prior to the step and one question that reflects on that answer after the step.
        \autoref{tab:questionsmethod} is a list of questions that reflect on the design method itself.

        \begin{table*}
            \caption{Table with questions to evaluate the steps. With corresponding questions ordered in pre and post step columns.}
            \label{tab:prepost}
            \begin{tabular}{|p{0.35\paperwidth}|p{0.35\paperwidth}|}
                \hline
                \vspace{1mm} \large{Prestep}  & \vspace{1mm} \large{Poststep} \\
                Questions prior to the execution of the step to set a baseline. & Questions after the execution of the step to check if the implementation met the expectations. In hind-sight, what should have been executed differently?\\
                \hline 
                \textbf{What was the previous step?} & \textbf{What will be the next step?} \\
                Does this influence this step? Is this a review? & Moving forward or is a review required of previous step(s)? \\
                \hline
                \textbf{Describe the plan of action.} & \textbf{Explain any deviations from the plan of action.} \\
                What is the next step going to be? How is it going to be executed? & What changed during the execution, what deviations where taken and why? \\
                \hline
                \textbf{What is the expected workload?} & \textbf{Was the workload different than expected?} \\
                How many hours are required for the execution of the step? Also give a range in your incertainty. & How much time was invested in the step? Why was it more or less than expected? \\
                \hline
                \textbf{What is the expected result of the step?} & \textbf{Is the result as expected?} \\
                At the end of the step, what is the expected result? & Does the result match the description made prestep? Why does it not match? \\
                \hline
                \textbf{What is the expected feasibility?} & \textbf{Was the expected feasibility of the implementation accurated?} \\
                What are the problems you expect during implementation? Why? & Even if the implementation succeeded, the feasibility does not have to be 100\%. Give an estimate for the feasibility now that the implementation is finished. Explain the difference with the prestep feasibility.\\
                \hline
            \end{tabular}
        \end{table*}

        \begin{table*}
            \caption{Table with questions to evaluate the design method itself}
            \label{tab:questionsmethod}
            \begin{tabular}{|p{0.35\paperwidth}|}
                \hline
                \textbf{Is this method a suitable approach for the hardware design?}\\
                Are there aspects in the hardware design that is not covered by the method? Or is the method not suited at all for hardware? Why not? How to do it different? \\
                \hline
                \textbf{Does the method contain counter-intuitive steps?} \\
                Are there steps that feel not optimal? Is it appealing to execute the step different? Is it just getting used to? Or really inefficient?\\
                \hline
                \textbf{What is the feasibility of this step in the method itself?} \\
                Not the execution of the step, but the step itself. Are those steps realistic? How can the method be improved? Why? \\
                \hline
                \textbf{Are there questions that can be added to this evaluation?} \\
                Can we add step specific questions or general questions to improve the evaluation? \\
                \hline
            \end{tabular}
        \end{table*}

        \subsection{Reporting}
        To answer all these questions and record all the steps a template was made.
        This template is a markdown-document that contains all the questions.
        The filled in documents will be stored in a git-repository.
        With continuous integration the documents will be merged to a single pdf.

        The development of the hardware will be done in a separate git repository.
        Each step will have its own issue. 
        This issue has a description and a checklist for the evaluation.
        Commits will be referenced to the issue, in that way all commits are grouped and can be tracked in the issue.

        %\rro{Use forms to evaluate the method}
        %\rroi{Questions answered before and after each step}
        %\rroi{Forms are also updated during the design}
    \section{Preliminary Design}
        \subsection{Problem Definition}
            The whole design process is initiated with the problem definition.
            For this case study, the problem definition is a bit different.
            In preparation of the case study it was decided to design a Whiteboard Writer from \autoref{sec:whiteboardwriter}.
            The Whiteboard writer was chosen because it would test the most aspects of the design method during the case study.
            In other words, a problem was needed that could be solved.
            And the problem needed to be complex enough so that the design method could be tested.

            However, during the case study, decisions have to be made about the solution space.
            Some of these decisions are not related with the testing of the design method itself.
            In these situations it is good to have a more concrete goal.
            Therefore, it is decided that the whiteboard writer has to be able to put a twitter message on the board.

            Normally the goal of the problem definition would be to describe the problem that needs to be solved.
            Testing the design method is in this case the problem, which makes it tightly coupled.
            Furthermore, a good problem definition focusses on getting the stake holders on the same line \autocite{shafaat_exploring_2015}.
            However, as the case study is performed by the author, there is only one stake holder.
            Discussion, communication and interaction between team member improves the problem solving in general \autocite{lamb_221_2008}.

            Even though the problem definition stayed in a very minimalistic state.
            The core goals are as follows:
            \begin{itemize}
                \item The system under design shall be used to evaluate the design method.
                \item Engineering decisions are made, in the first place, to aid the evaluation of the design method.
            \end{itemize}

            Secondary goals can be described as:
            \begin{itemize}
                \item The system shall write a twitter message on the board.
            \end{itemize}
            
        \subsection{Specifications}
            \rro{Present Specifications for Case}
            \subsubsection{Evaluation}
                \rro{EARS is a good method}
                \rro{Expected walk in the park}
                \rro{Was difficult to validate}
        \subsection{Initial Design}
            \rro{Research on Existing Systems}
                \rroi{Cable bot}
                    \rroii{Cable Tensioning, helps avoid oscillations}
                \rroi{Cartesian-coordinate robot}
                \rroi{SKARA}
                \rroi{Polar-coordinate robot}
                \rroi{Combination of the different systems}
            \rro{Choice of system}
                \rroi{Combine Cable bot with SCARA}
                    \rroii{Combination gives more dimensions of freedom to system}
                    \rroii{Otherwise it is expected that modeling is too easy}
            \subsubsection{Evaluation}
                \rro{Difficult to validate if the system is working}
                \rro{Design stays very rough}
                    \rroi{Not sufficient detail to communicate to other engineers}
                    \rroi{Lack in experience.}
                \rro{Tested: Discussed and reviewed with daily-supervisor}
        \subsection{Feature Definition}
            \rro{Goal: define features that can be implemented one by one}
            \rroi{Additionally, division of system requirements}
            \rro{Expected: A list of features, with corresponding dependencies}
            \rro{Could define features, but non of them described mechanical components that could be implemented.}
            \rro{Result: Improvised a structure that was loosely based on Robmosys}
            \rroi{The lose features:}
            \rroii{End-effector}
            \rroii{SCARA}
            \rroii{Carriage}
            \subsubsection{Evaluation}
                \rro{Multiple problems:}
                \rroi{Specifications were to broad or to specific}
                \rroi{Taking the following steps in to account, none of the features made sense}
                \rroii{None of the features were something that could be modeled}
                \rroii{Type of motor was depending on the forces required}
                \rro{Inspired from RobMoSys we made a tree structure}
                \rroi{The mission, task, skill etc separation helped a lot in structuring}
                \rroi{For now, this solution suffices to continue the case study}
                \rro{Mid-way Conclusion: Preliminary requires large changes}
        \subsection{System Test Specification}
            \rro{Specify tests for the different specifications}
            \rro{Made a document with tests}
            \rroit{Should this document be included in the report?}
            \rroi{Each test covers one or more specs}
            \subsubsection{Evaluation}
                \rro{Was quite easy to perform}
                \rroi{Difficult due to specs and features not working out as expected}
                \rroi{Most features could not be tested as the subsystem needs to be completed first}
                \rro{Tested by peer-review}
                \rroi{Found that a review without all the project information is difficult}