fixup! Process feedback case evaluation

content/case_evaluation.tex

@@ -7,8 +7,8 @@ The design method itself is evaluated in the next chapter.
 However, some of the topics discussed in this chapter have a strong overlap with those in the next chapter.
 
 The first section is about the time spend on the development.
-Followed by two sections on the role of stake holders and the use of modelling languages during a development.
-The last section is a more personal reflection about the development.
+Followed by a section about the role of stake holders and one about the use of modelling languages during a development.
+The last section is a more personal reflection about the case study.
 
     \section{Time Investment}
     \label{sec:time_investment}
@@ -16,17 +16,22 @@ The last section is a more personal reflection about the development.
         In \autoref{fig:time_spend} the planned and spend time on each step are plotted next to each other.
         In addition to the steps, time was also spend on the hardware construction and software development.
 
-        The original implementation of the feature definition was not feasible and had to be reviewed.
-        As the new approach for the feature definition is based on the expected result.
-        The time spend on performing the feature definition is not representative as there is not clear starting moment.
+        The initial approach for the feature definition did not result in a statisfactory set of features.
+        Therefore, the approach for the feature definition was reformulated.
+        Before new approach was formulated, multiple attempts were made to get a representative set of features.
+        The time spend on performing the feature definition is not representative as formulating the new approach and creating the set of features were performed in parallel.
+        The real execution time is estimated to be around 3 to 5 days ( {\textsuperscript{1} in \autoref{fig:time_spend}).
 
         \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. 
-            Some of the values in this do not represent the time requirements of this design method:\newline
-            \textsuperscript{1} During the feature definition the design method was reviewed. 13 days were spend on this review and execution, obfuscating the actual execution time. The execution time is an estimated 3 to 5 days.\newline
-            \textsuperscript{2} The first cycle was cut short due to its complexity.\newline
+            \caption{
+                Overview of the planned and spend number of days for each step during the case study. 
+                Some of the values in this do not represent the time requirements of this design method:\newline
+                \textsuperscript{1} During the feature definition the design method was reviewed. 
+                13 days were spend on this review and execution, obfuscating the actual execution time. 
+                The execution time is an estimated 3 to 5 days.\newline
+                \textsuperscript{2} The first cycle was cut short due to its complexity.\newline
             }
             \label{fig:time_spend}
         \end{figure}
@@ -35,12 +40,14 @@ The last section is a more personal reflection about the development.
         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.
+        Therefore, first development cycle was cut short ( \textsuperscript{2} in \autoref{fig:time_spend})
+
         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.
+        Based on this successful implementation and prior experience, I planned an additional two weeks of development time for this cycle.
 
-        To validate the design of the \ac{scara}, I build a prototype.
-        This consisted of acquiring and assembling the hardware, and writing software.
+        To validate the design and model of the \ac{scara}, I build a prototype.
+        This consisted of building 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 be a day of work.
@@ -54,7 +61,7 @@ The last section is a more personal reflection about the development.
         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.
+        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 requirements 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.
@@ -94,8 +101,8 @@ The last section is a more personal reflection about the development.
             The information was often not specific enough or it was overlooked.
             Even though attempting to be thorough, requirements were never really specific.
             As explained in the previous section, the lack of stake-holders is one of the reasons for information not being 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, which was not the case.
+            
+            Information that was overlooked created a situation where I needed information that should have been the result of a previous step, which was not the case.
             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.
             Resulting in additional requirements added to the design, before continuing with the design process.
@@ -105,7 +112,7 @@ The last section is a more personal reflection about the development.
             Being inexperienced does definitely not aid the design process. 
             Needless to say, more experience would improve the information situation. 
             However, it does not solve the problem.
-            Further improvements for the design method is required, to improve the information process during development.
+            Further improvements for the design method are required to improve the information process during development.
             
         \subsection{Development phase}
             \label{sec:evaluation_reflection_development}
@@ -127,7 +134,7 @@ The last section is a more personal reflection about the development.
 
         \subsection{Continuation of this Case Study}
             \label{sec:evaluation_reflection_protoype}
-            At the point that the \ac{scara} was implemented, I gathered so much new information that the some of the design choices felt obsolete.
+            At the point that the \ac{scara} was implemented, I gathered so much new information that some of the design choices felt obsolete.
             In this case study, the prototype is used to validate the design.
             However, the current prototype contains so much information that it would improve the requirements and initial design significantly.