|
|
|
@@ -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. |
|
|
|
|
