Skip to content
Snippets Groups Projects

Describe Method

Merged Wouter Horlings requested to merge method into master
1 file
+ 118
2
Compare changes
  • Side-by-side
  • Inline
+ 118
2
%&tex
\chapter{case method}
\label{case_method}
\chapter{Case Study: Method}
\label{chap:case_method}
The goal of this case study is to evaluate the design plan as presented in the previous chapter.
The evaluation is done by developing a system according to the design plan.
In general, the method of the case study follows all the steps of the design plan.
Additionally, an evaluation protocol ensures that the development is evaluated consistently.
The last important thing is a subject of design that is developed in the case study.
The next sections present the evaluation protocol and the subject of design.
\section{Evaluation Protocol}
The evaluation protocol ensures that the different steps, decisions and changes of the design are consistently evaluated.
This protocol contains a questionnaire and model validation.
The full questionnaire is administered during each step in the design plan.
It covers questions about the design process as well as the design plan.
The model validation is performed at the end of the development.
This validation is done by creating a physical prototype of the design and comparing the operation with the designed model.
\subsection{Questionnaire}
The questionnaire consists of two sets of questions.
The first set of questions is shown in \autoref{tab:prepost}.
This set consists of pairs of questions and focusses specifically on the execution of the design step.
Each pair embodies a theme, with one questions answered before, and the other question answered after the execution of the design step.
The goal of these pairs is to record the expected and planned execution with the results of the execution.
The second set of questions focusses on the described method of the design step.
These questions are shown in \autoref{tab:questionsmethod}.
To answer and record the questions consistently, there is a template document with these questions.
The document with the answers is stored in version control and is automatically typeset into a PDF document.
\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 method of testing?} & \textbf{How did you test/validate the step?} \\
What is the protocol to review the result of this step? & How was the evaluation done? Did it reveal something new? \\
\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 uncertainty. & 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 pre-step? Why does it not match? \\
\hline
\textbf{What is the expected feasibility?} & \textbf{Was the expected feasibility of the implementation accurate?} \\
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 pre-step 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
\end{tabular}
\end{table*}
\subsection{Model validation}
The design plan focusses on the modelling of the system.
It is, however, not given that passing all the tests does also results in a working design.
If the tests are incomplete or complications in the design are overlooked, the design process is worthless.
Therefore, the model will be validated with a physical prototype of the design.
This shows whether the model is correct and whether all assumptions about the system are correct.
The prototype does not only show where the design process went wrong, it can also be used to improve the design plan to prevent these modeling problems.
\section{Subject of Design}
The choice in subject of design has a strong influence on the effectiveness of the evaluation of the design plan.
To ensure the best subject of design a list of requirements is composed.
Based on this list the best subject of design is a "Tweet on a whiteboard writer", which is referred to as system.
Other subjects were considered, but did not meet the desired requirements.
The most important requirement is that, while developing the system, the different aspects of the design plan are used.
Taking into account that there is a limited time budget and that the system must be within the scope of the design plan, the set of possible subjects of design is slim.
The time budget is set to 10 weeks of development and the system must have a dynamic system that is actuated via a software controller.
The tweet on a whiteboard fits within these requirement as it can have interesting dynamics and has multiple features.
Although it is possible that the system is seen as a simple wall plotter with simple XY-movement, there are alternative implementations that achieve more complex XY-movement.
This provides the required complexity and allows for different levels of detail needed for the variable detail approach.
The system can be split into more than one feature, which is required to evaluate the rapid development cycle.
One of the features is the XY-movement and other features are:
\begin{enumerate}
\item Lifting the marker from the board
\item Erasing: End effector manipulation
\item Changing color: Switching Marker
\item Speed increase
\end{enumerate}
Similar to the XY-movement, these features have multiple implementations that add complexity to the system.
This gives the possibility during the case study to go with a more or less complex design, allowing to fit the case study in the time budget without compromising the quality of evaluation.
Although a finished product is not required, a partial prototype is part of the testing and validation procedure.
As the design method focuses on the physical component, a mechanical prototype is important.
The prototype would originally been constructed with the rapid prototyping facilities at the university.
However, the COVID-19 pandemic forced the university to close and to work from home.
This limited the rapid prototyping to DIY-tools and a 3D-printer.
It is expected that this set of tools is sufficient to construct a prototype of the tweet on a whiteboard system
Other options that were looked at was a 3D calibration system for a positioning system.
This idea was rejected because the complexity originated from the required accuracy instead of the dynamics.
In other words, choosing interesting dynamics would degrade the usability of the system.
A peg-in-hole problem, was also considered briefly as well.
But that is mainly a complex sensing and control problem, and not dynamically interesting.
Loading