From cbd31323d71878219983a0545ee1aaa59af360ee Mon Sep 17 00:00:00 2001 From: Wouter Horlings Date: Sun, 4 Apr 2021 14:18:38 +0200 Subject: [PATCH] Update analysis table --- .gitignore | 1 + content/analysis.tex | 126 ++++++------------------------------------- 2 files changed, 18 insertions(+), 109 deletions(-) diff --git a/.gitignore b/.gitignore index bbd57e8..600c8d9 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ /*.rro /*.pdf graphics/*.pdf +*.xmpdata diff --git a/content/analysis.tex b/content/analysis.tex index f9c4fa0..c3dd6bf 100644 --- a/content/analysis.tex +++ b/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.