fixup! fixup! fixup! fixup! fixup! Add analysis

content/analysis.tex

@@ -67,12 +67,78 @@ The steps that are introduced by \ridm are covered in more detail.
 
 \subsection{Feature Definition}
     \label{sec:featuredefinition}
-    During the feature definition, the system will be split into features as to prepare for the rapid development cycle and the variable-detail approach.
-    The goal is to split the system in such way that the resulting features are as small as possible, but can still be implemented and tested individually.
+    During the feature definition, the system will be split into features as preparation for the rapid development cycle and the variable-detail approach.
+    The aim of the \ridm is to have short implementation cycles to have early testing feedback.
+    To achieve this, the features are as small as possible, but can still be implemented and tested individually.
+    Together with the definition of the features, the requirements are divided along the features as well.
+    The optimal strategy on splitting features and specifications is strongly dependent on the type of system.
+    Therefore, the best engineering judgement of the developer the best tool available.
 
+    Sometimes features are dependent on each other, the implementation of one feature influences another.
+    This dependency can occur in specifications, where strength of one feature dictates the maximum mass of another feature.
+    Such a dependency can work both ways and can be resolved by strengthening the one feature, or reduce the weight of the other feature.
+    Another type of dependency is when the implementation influences other features.
+    In this case, if the implementation of one feature changes, it requires a change in the other features.
+    An example of this is a robot arm, where the type of actuation strongly influences the end-effector.
+    When the robot arm approaches an item horizontally, the end-effector will be different than approaching the item vertically.
+
+    Due to these dependencies it is possible that the division of requirements changes, because the result of the implemented feature was not as expected.
+    This is not directly a problem, but a good administration of the requirements makes an update of the requirements easier.
 
 \subsection{Feature Selection}
     \label{sec:feature_selection}
+    The rapid development cycle does not specify which feature should be implemented first, even though the order of implementation does change the feasibility of the complete development.
+    An example that shows the importance of the order of features is the development of a car.
+    To have a critical damped suspension in a car, the weight distribution of the car must be known.
+    If the suspension of the car is designed before all the features that determine the weight distribution, it is likely that the suspension design is not up to specifications.
+    Resulting in a redesign of the suspension feature and thus increasing the overall development cost.
+    This example is caused by the dependency between different features.
+
+    For the design plan, the order of implementation of features will be determined by the following rules:
+    \begin{enumerate}
+        \item Features that are dependencies of others must be implemented first.
+        \item Features that complete more system test than other features when implemented have priority.
+        \item Features with the higher \emph{risk per time} score than other features have priority.
+    \end{enumerate}
+    The risk per time score for third rule is calculated by dividing the risk score with the time score.
+    The goal of this score is to eliminate as much risk as possible in the least amount of time.
+    It seems logic to always implement the highest risk feature first, but it is possible that within that feature multiple lower risk features can be finished.
+    This is visible in \autoref{tab:feature_selection}: In a time span of 6 days it is possible to implement feature E or features A, C, and D.
+    The risk that is cleared by E is 45 \% which is significantly less than the combined 65 \% of A, C and D.
+    Due to the limited scope of this thesis, it is not possible to give a good metric for determining risk and time.
+    Nevertheless, it is strongly advised that the developer defines some metric that fits his project best.
+
+    \begin{marginfigure}
+        \centering
+        \includegraphics[width=2.9cm]{graphics/feature_dependency.pdf}
+        \caption{Dependency graph for features.}
+        \label{fig:feature_dependency}
+    \end{marginfigure}
+    \begin{table}[]
+    \caption{Comparison of features with their corresponding risk and time. 
+        The last column is the risk value divided by the number of days.}
+    \label{tab:feature_selection}
+    \begin{tabular}{l|r|r|r|r|r|}
+    \cline{2-6}
+                                  & \multicolumn{1}{l|}{Dependees} & \multicolumn{1}{l|}{Tests} & \multicolumn{1}{l|}{Risk} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{l|}{Risk per time} \\ \hline
+    \multicolumn{1}{|l|}{Feat. A} & 2 (2, 3)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
+    \multicolumn{1}{|l|}{Feat. B} & 0                              & 3                          & 40 \%                     & 5  days                   & 8                                  \\ \hline
+    \multicolumn{1}{|l|}{Feat. C} & 1 (5)                          & 5                          & 25 \%                     & 2  days                   & 12.5                               \\ \hline
+    \multicolumn{1}{|l|}{Feat. D} & 0                              & 4                          & 15 \%                     & 1  day                    & 15                                 \\ \hline
+    \multicolumn{1}{|l|}{Feat. E} & 0                              & 4                          & 45 \%                     & 6  days                   & 7.5                                \\ \hline
+    \end{tabular}
+    \end{table}
+    Looking at an example of 5 features:
+    As seen in \autoref{fig:feature_dependency}, Features B and C are dependent on feature A.
+    Feature D does not have any dependency connections, and feature E is dependent on C.
+    Together with the information in \autoref{tab:feature_selection}, the order of implementation is:
+    \begin{description}
+        \item[Feature A:] has two features that are dependent on this feature, more than any other.
+        \item[Feature C:] has one feature that is dependent on this feature, most dependencies after A is implemented.
+        \item[Feature D:] has the same number of tests as E, but D has a significant higher risk per time score than E
+        \item[Feature E:] has the most number of tests.
+        \item[Feature B:] only one left to be implemented.
+    \end{description}
 
 \subsection{Rapid Development Cycle}