diff --git a/content/analysis.tex b/content/analysis.tex index 0a2f34f..d141d14 100644 --- a/content/analysis.tex +++ b/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}