Update analysis table

.gitignore

@@ -1,3 +1,4 @@
 /*.rro
 /*.pdf
 graphics/*.pdf
+*.xmpdata

content/analysis.tex

@@ -51,28 +51,6 @@ The second part is the Development Cycle, which contains the features selection,
         The best alternative is materialized in a design document together with the system requirements.
         This design document is used in the next phase of the design.
 
-%\section{Rapid Iterative Design Method}
-%    From this point, the design plan is based on the \ac{ridm} and not anymore on the waterfall model.
-%    The first step is the feature definition, which prepares the required features based on the initial design.
-%    The features are defined by splitting the system in such a way that the results of each implemented feature are testable.
-%    The definition of the feature contains a description and a set of sub-requirements which is used to implement and test the feature.
-%    During the feature definition, the dependencies, risks and time resources are determined as well, this establishes the order of implementation in the feature selection step.
-%
-%    Based on the requirements of \ac{ridm} as explained in \autoref{chap:background}, the next step is the feature selection.
-%    However, it became apparent that the number of tests related to a specific feature is a good metric for the selection step.
-%    Because, at the point that a feature is implemented, the tests are completed as well, and when the tests of the complete system pass, the system meets the requirements.
-%    Following the \ac{ridm}, these tests are specified at the start of the rapid development cycle.
-%    This makes it impossible to use the tests during the feature selections.
-%    Therefore, a test protocol step is added after the feature definition and before the feature selection step.
-%
-%    The third step is the feature selection, where one of the features is selected. 
-%    This selection is based on the dependencies, tests, risk, and time requirements in the feature definitions.
-%    The fourth step is the rapid development cycle, which uses the sub-requirements and description of the selected feature to create an initial design and a minimal implementation.
-%    In the last step, the variable-detail approach is used to add detail to the minimal implementation over the course of multiple iterations.
-%    The tests are used to determine if the added detail does not introduce any unexpected behavior.
-%    This cycle of adding detail and testing is repeated till the feature is fully implemented.
-%    From this point, the \ac{ridm} is repeated from the third step until all features are implemented.
-
 \subsection{Feature Definition}
     \label{sec:featuredefinition}
         During the feature definition step, the initial design is split into features as preparation for the rapid development cycle and the variable-detail approach.
@@ -113,80 +91,6 @@ The second part is the Development Cycle, which contains the features selection,
         For example, having a mobile robot arm near a coffee machine does meet the hardware requirements, it does not have any functionality if that is not yet implemented.
         This also creates a clear division for the developer as the functions cannot be mixed with the hardware.
 
-%        
-%
-%
-%        
-%
-%        
-%        
-%
-%        
-%    
-%
-%        As explained in the previous chapter, the goal of the \ac{ridm} is to get feedback on the design as early as possible. 
-%        To achieve this, the design is split into features, and each feature is implemented and tested sequentially.
-%        Resulting in smaller development cycles that are tested individually.
-%        If a feature fails its test it occurs directly after its implementation, instead of when the full system is implemented.
-%        The goal of this step is to apportion the system into features.
-%        Each feature must be small but independent, meaning that the feature can still be individually implemented and tested.
-%
-%        In some cases it is not possible to define a feature that can be implemented and tested independently.
-%        This occurs when the feature is dependent on the implementation of other features.
-%        This dependency can occur in requirements where, for example, strength of one feature limits the mass of another feature.
-%        Such a dependency can work both ways and can be resolved by strengthening one feature, or reduce the mass 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, it requires a different end-effector than approaching the item vertically.
-%
-%    \subsubsection{Feature Hierarchy}
-%        
-%
-%        
-%
-%
-%        %%%%%%%% ->
-%        There are two important responsibilities for the developer when the design encounters feature dependency.
-%        The first one is that the developer must determine where to split the system.
-%
-%        In case of a dependency, the developer must evaluate the optimal order of implementation.
-%        The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
-%        In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
-%        The second responsibility is organizing the feature requirements.
-%        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 these requirements easier. 
-%
-%        
-%        
-%
-%
-%
-%
-%    To achieve these short cycles, the features that are implemented in these cycles, are as small as possible. 
-%    However, the features must still be implemented and tested individually during the implementation and can thus not be split indefinitely.
-%    Together with the definition of the features, the requirements are divided along the features as well.
-%    The optimal strategy on splitting features and requirements is strongly dependent on the type of system.
-%    Therefore, the best engineering judgement of the developer the best tool available.
-%
-%    In some cases it is not possible to define a feature that can be implemented and tested independently.
-%    This occurs when the feature is dependent on the implementation of other features.
-%    This dependency can occur in requirements, 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, it requires a different end-effector than approaching the item vertically.
-%
-%    There are two important responsibilities for the developer when the design encounters feature dependency.
-%    The first one is during the definition, where the developer has to decide on how to split the system and how the dependency is stacked.
-%    For the requirement and the implementation dependency the developer must evaluate the optimal order of dependency.
-%    The developer must arrange the dependency of the features such that the influence on the dependent feature is as small as possible.
-%    In other words, if feature A can be easily adapted to the implementation of feature B, but not the other way around, the developer must go for A dependent on B.
-%    The second responsibility is organizing the feature requirements.
-%    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 these requirements easier. 
-
 \subsection{Test protocol}
     \label{sec:systemtesting}
     During the rapid development cycle and the variable-detail approach, the system is tested constantly.
@@ -224,20 +128,24 @@ The second part is the Development Cycle, which contains the features selection,
         \caption{Dependency graph for features.}
         \label{fig:feature_dependency}
     \end{marginfigure}
-    \begin{table*}[]
+    \begin{table}[]
         \caption{Comparison of features with their corresponding \ac{cof} and time. 
-        The last column is the \ac{cof} 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}{p{0.13\paperwidth}|}{\acl{cof} (\acs{cof})} & \multicolumn{1}{l|}{Time} & \multicolumn{1}{p{0.13\paperwidth}|}{Change of Failure over time} \\ \hline
-    \multicolumn{1}{|l|}{Feat. A} & 2 (B, C)                       & 2                          & 15 \%                     & 3  days                   & 5                                  \\ \hline
-    \multicolumn{1}{|l|}{Feat. B} & 0                              & 3                          & 40 \%                     & 5  days                   & 8                                  \\ \hline
-    \multicolumn{1}{|l|}{Feat. C} & 1 (E)                          & 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*}
+        The last column is the \ac{cof} value divided by the planned number of days.}
+        \label{tab:feature_selection}
+        \rowcolors{2}{lightgray}{white!100}
+        \begin{tabular}{lrrrrr}
+            \cline{2-6}
+            \toprule
+            & \multicolumn{1}{l}{Dependees} & \multicolumn{1}{l}{Tests} & \multicolumn{1}{l}{\ac{cof}} & \multicolumn{1}{l}{Time} & \multicolumn{1}{l}{\ac{cof} over time} \\
+            \midrule
+            \multicolumn{1}{l}{Feat. A} & $2$ (B, C)                       & $2$                          & $15 \%$                     & $3$  days                   & $5$                                  \\ 
+            \multicolumn{1}{l}{Feat. B} & $0$                              & $3$                          & $40 \%$                     & $5$  days                   & $8$                                  \\ 
+            \multicolumn{1}{l}{Feat. C} & $1$ (E)                          & $5$                          & $25 \%$                     & $2$  days                   & $12.5$                               \\ 
+            \multicolumn{1}{l}{Feat. D} & $0$                              & $4$                          & $15 \%$                     & $1$  day                    & $15$                                 \\ 
+            \multicolumn{1}{l}{Feat. E} & $0$                              & $4$                          & $45 \%$                     & $6$  days                   & $7.5$                                \\ 
+            \bottomrule
+        \end{tabular}
+    \end{table}
 
     To determine the order of implementation of features, a dependency graph and a comparison table is made.
     The dependency graph and the comparison table for a theoretic system is shown in \autoref{fig:feature_dependency} and \autoref{tab:feature_selection} respectively.