Merge branch 'reflection' into 'master'

Reflection

See merge request horlingsw/master-assignment-report!16

content/background.tex

@@ -27,6 +27,7 @@ This waterfall model consists of number of steps that are all successively execu
 The successive steps make it possible to insert or replace the steps in the design method.
 
 \section{Rapid Iterative Design Method}
+\label{sec:RIDM}
 The \ridm by \textcite{broenink_rapid_2019} describes a methodology using two core components for the implementation: the rapid development cycle and the variable detail approach.
 The design method also describes the preparation steps that are required prior to this implementation.
 In short, the preparation prepares a list of features.
@@ -34,6 +35,7 @@ These features are implemented one by one with in the rapid development cycle us
 This section discusses each of these three parts and how they fit in the waterfall model.
 
 \subsection{Rapid Development Cycle} 
+\label{sec:background_rdc}
 The goal of the rapid development cycle is sequential implementation of the features in a system.
 Each iteration of the rapid development incorporates the following steps:
 \begin{enumerate}

content/case_evaluation.tex

@@ -123,6 +123,7 @@ The last section is a more personal reflection about the development.
             Further improvements for the design method is required, to improve the information process during development.
             
         \subsection{Development phase}
+            \label{sec:evaluation_reflection_development}
             For the development phase I have significantly more experience compared to the preparation phase.
             Creating models is something that I really enjoy and this improves the process significantly.
             Even though the development phase went smoother than the preparation phase, there is still room for improvement.
@@ -140,3 +141,14 @@ The last section is a more personal reflection about 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 performing as expected.
 
+        \subsection{Continuation of this Case Study}
+            \label{sec:evaluation_reflection_protoype}
+            At the point that the SCARA was implemented, I gathered so much new information that the some of the design choices felt obsolete.
+            Although, the current design method does not incorporate a prototype, the current state of the design is more or less a prototype.
+            In theory, if I would continue the case study, my proposal is to consider the current design as an actual prototype and revisit the preparation phase.
+            With the current knowledge, the specifications and initial design would improve significantly.
+            However, it is very important to note that this decision relies on the fact that the prototype is already created.
+            In other words, the work is already done and resulted in useful information for a next design iteration.
+            But, in case of a different system, I doubt that creating a prototype, followed by a full repeat of the design method is an efficient approach.
+            Therefore, the choice to revisit the preparation phase must not be considered as an improved design method but as an argument to improve the preparation phase itself.
+

content/case_experiment_end-effector.tex

@@ -47,6 +47,7 @@ Eventhough no progress was made, this attempted implementation did provide valua
             Within a design team a form of planning poker \autocite{grenning_planning_2002} could be a good option.
         
     \subsection{Rapid Development of the End-Effector}
+        \label{sec:case_development_cycle_1}
         This section explains the process of the development of the end-effector.
         The first step is to create an initial design of the model.
         In subsequent steps, detail is added to this model.

content/reflection.tex

@@ -1,3 +1,148 @@
 %&tex
-\chapter{reflection}
-\label{reflection}
+\chapter{Design Method Evaluation}
+    \label{chap:reflection}
+
+    \section{Elements of a Feature}
+        Over the course of this study, the definition of a feature evolved into requirements, components and functions.
+        As explained in the background chapter, having an approach to determine requirements is a crucial concept of a design process.
+        Because \ac{ridm} did not include such an approach, a \ac{se} approach was added.
+        The aim of the \ac{se} approach is to deliver a set of features to be used in the \ac{ridm}.
+        To be more specific, the set of features was expected to be the result of the feature definition step.
+        Contrary to that expectation, multiple attempts for this step did not produce a satisfactory definition of features.
+        As explained in \autoref{sec:case_featuredefinition}, there was a clear discrepancy between the expected and resulting features.
+        It was expected to get features in the form of components that developed during the design process.
+        However, the resulting features came off as functions of the system.
+        In the end, a solution was found in the RobMoSys approach.
+        Even though the RobMoSys approach was too comprehensive for this case study, it provided the basis for the split between functions and components.
+        Furthermore, it resulted in the hierarchical structure of functions and sub-functions as shown in \autoref{fig:robmosys}.
+
+        \begin{figure}
+            \centering
+            \includegraphics[width=85mm]{graphics/functional_relation.pdf}
+            \caption{Relations and elements within a feature. \autocite{kordon_model-based_2007}}
+            \label{fig:functional_relation}
+        \end{figure}
+
+        Creating a hierarchy for the functions and a separate set of components allowed for the continuation of the case study.
+        There were still a number of challenges with this approach.
+        For example, it was almost impossible to divide the requirements between components and functions.
+        Furthermore, the role of electronics did not fit in the current approach either.
+        In reviewing the literature, the approach used in this case study shows clear resemblances with \ac{mbed} \autocite{kordon_model-based_2007}.
+        \ac{mbed} introduces explicit relations between the requirements, components and functions, as shown in \autoref{fig:functional_relation}.
+        Additionally, the paper includes a layout for the hierarchy of requirements, functions and components.
+        Based on this, the approach by \textcite{kordon_model-based_2007} further supports the idea of dividing features into requirements or requirements, functions, and components.
+
+        What is interesting about this new insight is that it helps to understand the difference with the case study performed by \textcite{broenink_rapid_2019}.
+        The hardware components used by Broenink and Broenink was a mini-segway, which was designed to be used in a under-graduate practical.
+        The requirement for this mini-segway to be able to balance, drive and steer, is inherited directly from the student project.
+        Causing the requirements and components to be implicitly defined in their case study.
+        Therefore, the function that needs to be implemented, fits very well within the definition of a feature.
+
+    \section{Model and Design Relation}
+        \label{sec:evaluation_model_and_design}
+        The \ac{ridm} as well as the design method in this study do not make an explicit distinction between the model and the design.
+        This implicitly causes the model itself to dictate the design.
+        According to \textcite{stachowiak_allgemeine_1973}, three general properties apply for a model.
+        First is that the model is always representative to its original; 
+        second, the model must only include attributes of its original that are relevant to the respective developer or user;
+        and third, the model must be pragmatic to the original, meaning that models are an adaptation of the original with respect to a specific purpose.
+
+        These properties coincide with the different modelling approaches used during the case study.
+        The dynamic models did not start directly with 3D physics as it would conflict with the second property.
+        However, as the design becomes more refined, it can not be represented with only basic kinematics calculations. 
+        The step to 2D, and later 3D physics, is made such that the model still represents the design.
+        Parallel to the dynamics model, a CAD drawing was used to model the shape of the hardware components.
+        Simply because models represent the design for a different purpose.
+
+        Even though the models in the case study satisfy the properties as described above, it has a significant implication for the current design method.
+        As the model is used to represent the current design, switching to a different modelling approach changes the representation of the design as well.
+        Two direct consequences are identified from the case study.
+        The first is that there is discrepancy for the required effort between a design change and the corresponding model update.
+        This is seen in the case study when the model was reconstructed with 3D physics but the design did not change.
+        Resulting in a couple of days of work spend reconstructing the model, without significant progress in the design.
+        The second consequence is that the design got split up over the dynamics model and the CAD drawing:
+        Both included the kinematics of the \ac{scara};
+        the controller and stepper behavior was defined in the dynamics model;
+        and the shapes of the components was defined in the CAD drawing.
+        This organization of models and design has two major downsides.
+
+        The first that a switch in modelling approach, is not only labor intensive, it is error prone as well.
+        Copying parameters from one model and pasting them in another model is an unwanted practice.
+        The second problem is that not every type of model can represent the same information.
+        Although the CAD drawing contains a lot of detail, it cannot represent the electric behavior of the motors.
+        For this case study the motors are \ac{ots}-components.
+        The electric behavior of the motor is therefore represented by a product number.
+        However, this is not applicable when the design requires custom motors that are designed with a specific electric behavior.
+        Probably resulting in a situation where specific design details are spread over different sub-models.
+        Such a subdivision of details across different models is, without any doubt, undesired.
+
+    \section{Preparation Phase}
+        The start of this chapter explains the reason to prepend the preparation phase to the \ac{ridm}.
+        Where the preparation phase aims to produce the requirements and features, based on the waterfall method.
+        However, during the case study, the waterfall method proved to be problematic.
+        Especially during the first steps, the amount of information was scarce, which made it tempting to work ahead.
+        For example, a simple proof of concept during the requirement step would have resulted in valuable information.
+        This was however, not possible as the goal was to follow the specified design method as close as possible.
+
+        Looking at the current case study where the system under design is relatively simple, more design experience is sufficient to overcome the information shortage.
+        Unfortunately, it requires experienced developers, which are scarce by themself.
+        As was pointed out in \autoref{sec:evaluation_reflection_protoype}, perceiving the current design as a prototype would also improve the information situation.
+        Similarly, \textcite{royce_managing_1970} proposed to use a prototype in order to reduce the reliance on human judgment.
+        A common denominator of these proposals is that they all deal with the dependency on human judgement, either by improving or reducing this judgement.
+        Nonetheless, these proposal seem like a suppression of symptoms, instead of an actual improvement of the design method.
+
+        Interestingly, when the current design is regarded as prototype and the design method is repeated, the approach is comparable with the first cycle of the spiral model \autocite{boehm_spiral_1988}.
+        \textcite{broenink_rapid_2019} state about the \ac{ridm} that the development cycle is based, among other methods, on the spiral model.
+        It may be the case therefore that prepending the waterfall model was an attempt to reinvent the wheel.
+
+    \section{Rapid Iterative Design Method}
+        This chapter began by a breakdown of the elements of a feature, argued the importance of distinction between design and model, and explained the need for an integrated preparation phase.
+        The commonality between these three issues is that they all stem from the rapid development cycle, which was introduced in \autoref{sec:background_rdc} as part of the \ac{ridm}.
+        It is apparent that the current implementation of the rapid development cycle is not suited for the design of a cyber-physical system.
+        Further studies, which take these issues into account, should be undertaken.
+
+        Even though, these issues have a large impact on the overall performance, they must not overshadow the rest of the design method.
+        The feature selection step and variable detail approach did show a positive impact on the design method.
+        The following sections discuss their performance and what potential impact an improved rapid development cycle introduces.
+
+        \subsection{Feature Selection}
+            The goal of the rapid development is to process a list of features into a competent model.
+            In this case, the list of features was produced in the preparation phase.
+            The features are then, one by one, implemented according to the variable detail approach.
+            To determine the order of feature implementation, I specified a feature selection protocol, which is explained in \autoref{sec:feature_selection}.
+            Based on this case study, the feature selection is a suitable addition to the design method.
+            Especially for the failed feature implementation as described in \autoref{sec:case_development_cycle_1}.
+            Would the SCARA have been implemented first, a failure in the end-effector might result in a required redesign of the SCARA feature.
+            However, with only two uses during this case study, caution must be applied.
+
+            On the criteria itself, the time-risk factor and the dependees are, in my opinion, most relevant.
+            The dependees is a hard criteria: if there are any features that it depends on, but not yet implemented, it is cannot be selected.
+            Otherwise the feature would be implemented before the required information is available.
+            As explained in \autoref{sec:case_development_cycle_1}, the feature selection approach aims to clear the largest amount risk the smallest amount possible.
+            However, between the dependees and the risk-time factor, there is a criteria for the number of tests, which could hinder this approach.
+            The current approach would result in the situation where a feature with lots of easy to pass tests, is implemented before a features with less, but more difficult tests.
+            It is then possible to spend a lot of time on something that is very likely to pass anyway.
+
+            This does not alter the fact that to complete the design the all tests have to pass.
+            Which is also the reason for this criteria in the first place: give priority to the feature that passes the most tests on completion.
+            Even though it is difficult to draw concrete conclusions about the feature selection, a recommendation is to use the number and risk of tests as a metrics for the risk-time factor calculation.
+            In addition, it is possible that other metrics improve the risk time calculation, such as the number of dependees, the number of tests of those dependees, or other metrics that aid the risk assessment.
+            Further work is required to establish which metrics are suitable to improve the risk calculation.
+
+        \subsection{Variable Detail Approach}
+            The variable detail approach is be a very practical development tool.
+            A note of caution is due here since the variable detail approach has not been used to its full potential.
+            The goal was to add detail to a feature in strictly defined steps.
+            Between each step the tests are applied to the updated model.
+            Based on the test, the development continues or the model is rolled back to an earlier version.
+            In addition, the models, independent of the level of detail, can be reused in other models.
+            
+            However, multiple difficulties were encountered during the case study, which hindered the variable detail approach.
+            As was mentioned in \autoref{sec:evaluation_reflection_development}, the lack of good version control made it difficult to work with multiple versions of a model.
+            This made it difficult to switch or revert to other levels of detail.
+            However, the greatest difficulty is due to the model representing the design, as discussed in \autoref{sec:evaluation_model_and_design}.
+            Because the design contains a certain level of detail and the model is a full representation of the design, it is difficult to make a simple implementation or to switch back.
+            This strong relation between the model and the design, also caused the complete model to be switched to a different representation.
+            
+            Even though the variable detail approach did not perform as planned, I expect this approach to be a very strong part of the design method, given that a solution is found to the problems described above.
+

graphics/functional_relation.tex

@@ -0,0 +1,21 @@
+%&tex
+\documentclass{standalone}
+\usepackage{tikz}
+\usepackage{siltex}
+\usetikzlibrary {arrows.meta,positioning}
+\tikzset{nodes={text height=.7em, text width=2.5cm, align=center,
+draw=black!50, thick, font=\footnotesize},
+>={Stealth[round,sep]}, rounded corners, semithick}
+
+\begin{document}
+\begin{tikzpicture}[on grid,y=2.2cm,x=5.7cm]
+    \node (re) {Requirement};
+    \node (fu)[right=1 of re]  {Function};
+    \node (co)[above=1 of fu]  {Component};
+    \begin{scope}[nodes={draw=none, auto, fill=none, midway,text width={},text height={}}]
+        \path[->] (re) edge node[below] {Specifies} (fu)
+                  (co) edge node {Performs} (fu)
+                  (re) edge node {Specifies} (co);
+    \end{scope}
+\end{tikzpicture}
+\end{document}