\documentclass[signature]{deltares_manual}
\usepackage[titletoc]{appendix}

\renewcommand\BackgroundPicChapter{
    \put(0,0){
    \parbox[b][\paperheight]{\paperwidth}{%
        \vspace{4\baselineskip}
        \hspace{220mm}
        \includegraphics[width=15mm]{pictures/algemeen-strookje20mm.jpg}
        \vfill
        }
    }
}
\renewcommand{\contactsalesandsupport}{
	\textbf{Contact:}\\
	\begin{tabular}[t]{@{}p{0.50\textwidth}p{0.50\textwidth}}
	\vspace*{-1.5\baselineskip}
	\begin{tabbing}
Deltares \\
Boussinesqweg 1 \\
2629 HV Delft \\
P.O. 177 \\
2600 MH Delft \\
The Netherlands \\
	\end{tabbing}
	&
	\vspace*{-1.5\baselineskip}
	\begin{tabbing}
	telephone: \= +31\,88\,335\,8273 \\
	www:       \> https://www.deltares.nl \\
	\end{tabbing}
	\end{tabular}
}

%-----------------------------------------------

\begin{document}
\pagestyle{empty}
\includepdf[pages=1, offset=72 -70]{pictures/dam_cover_technical_design.pdf} % links-rechts past precies
\cleardoublepage
%

\newcommand{\ProgramName}{DAM}
\newcommand{\ProgramNamePlusSpace}{DAM }

\title{\ProgramName}
\manualtype{Technical Design}
\subtitle{}
\projectnumber{1210702-000}
\client{Deltares - Geo engineering DKS}
\reference{1210702-000-GEO-0004}
\classification{-}

\date{Jan. 2017}
\version{0.1}

\keywords{Dike, safety assessment, design, software, macro stability, piping}

\references{Refer to \autoref{chapter5}.}

\summary{This document contains the technical design for \ProgramName, an application that computes the strength of a complete dikering with respect to several failure mechnanisms, such as macro stability and piping.\\
\\
\textbf{\footnotesize{Samenvatting}} \\
Dit document bevat het technisch ontwerp voor \ProgramName, een User Interface applicatie die een gebruiker in staat stelt om voor een dijktraject berekeningen uit te voeren voor verschillende faalmechanismen, waaronder macrostabiliteit en piping.}

\versioni{0.1}
\datei{Jan 2017}
\authori{Tom The}
\revieweri{John Bokma}
\approvali{Maya Sule}

\status{draft}


\deltarestitle


%------------------------------------------------------------------------------
\chapter{Introduction} \label{chapter1}

\section{Purpose and scope of this document} \label{sec:1.1}

This document contains the technical design for the standalone program \ProgramName, a software package for the automated calculation of the strength of dikes. DAM was developed by Deltares with and for STOWA for all water authorities.


\section{Other system documents} \label{sec:1.2}

The full documentation on the program comprises the following documents.

\renewcommand{\arraystretch}{1.3}

\begin{table}[H]
%\caption{xxx}
%\label{xxx}
\begin{tabular}{|p{40mm}|p{\textwidth-40mm-24pt}|} \hline
\textbf{Title} & \textbf{Content} \\ \hline
Functional Design \newline  \citep{GrassUI_FunctionalDesign} & Description of the requirements and functional design. \\ \hline
Technical Design \newline  \citep{GrassUI_TechnicalDesign} & Description of the implementation of the technical design of \ProgramName. \\ \hline
Technical documentation \newline \citep{GrassUI_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
Test Plan (this document) & Description of the different regression and acceptation tests, including target values.  \\ \hline
Test Report \newline \citep{GrassUI_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
User Manual  (included  \newline with the software) & Description of the different functionalites available in the \textit{User Interface} and background information. \\ \hline
\end{tabular}
\end{table}


\section{Requirements} \label{sec:1.3}

\subsection{Functional requirements} \label{sec:1.3.1}

In the Functional Design of the \textit{User Interface} \citep{GrassUI_FunctionalDesign}, the following requirements are defined and must be therefore tested. They will be tested at System Testing level (see \autoref{chapter4}). 


\begin{longtable}{p{13mm}p{\textwidth-13mm-24pt}}
\textbf{REQ 1} & The \textit{User Interface} must support the input of all required data. \\
\textbf{REQ 2} & The \textit{User Interface} must support the validation of all required input data. \\
\textbf{REQ 3} & The \textit{User Interface} must be able to start the Grass Run up Assessment calculation. \\
\textbf{REQ 4} & The \textit{User Interface} must be able to retrieve the results of the Grass Run up Assessment calculation. \\
\textbf{REQ 5} & The \textit{User Interface} must support the display of the results of the Grass Run up Assessment calculation. \\
\textbf{REQ 6} & The \textit{User Interface} must be able to start the Grass Impact Assessment calculation. \\
\textbf{REQ 7} & The \textit{User Interface} must be able to retrieve the results of the Grass Impact Assessment calculation. \\
\textbf{REQ 8} & The \textit{User Interface} must support the display of the results of the Grass Impact Assessment calculation. \\
\textbf{REQ 9} & The \textit{User Interface} must be able to read and write all data to its own file for storage and reuse of the data. \\
\textbf{REQ 10} & The \textit{User Interface} must offer functionality to switch between all of its parts. \\
\textbf{REQ 11} & The \textit{User Interface} must be available in Dutch. \\
\textbf{REQ 12} & The \textit{User Interface} must offer simple visualization of the input for the Grass Impact Assessment Calculation. \\
\textbf{REQ 13} & The \textit{User Interface} must offer simple visualization of the input for the Grass Impact Run up Calculation. \\
\end{longtable}


\subsection{Non-functional requirements} \label{sec:1.3.2}

Besides the functional requirements, \ProgramNamePlusSpace must meet some non-functional requirements. These  non-functional requirements are the same as required for WTI software. All non-functional requirements (NFR, U, TAB, TOI, PSR, R, SLA and Top) are given in the spreadsheet that lists all WTI requirements \citep{WTINonFunctionalRequirementsList}. The non-functional requirements with relevance to the development of this application and its proposed use are listed in the Functional Design \citep{GrassUI_FunctionalDesign}.

Not all non-functional requirements can be addressed via automatic tests or even by manual testing. Only the non-functional requirements given in \autoref{tab:NonFunctReqs} can be tested via unit/integration tests or test-scripts and will be therefore reported in the Test Report.

\begin{table}[H]
\caption{``Non-Functional Requirements'' relevant at Test level for \ProgramNamePlusSpace}
\label{tab:NonFunctReqs} 
\begin{tabular}{|p{15mm}|p{90mm}|p{\textwidth-105mm-36pt}|} \hline
\rowcolor[gray]{.8} \textbf{Nr.} & \textbf{Requirement} & \textbf{Testing level} \\ \hline %& \textbf{Description of the test} \\ \hline

NFR3 & Data definitions will follow existing and emerging standards such as IRIS as much as possible. & System Testing \\ \hline %&  The names and symbols of the input parameters used in the test-scripts must be conform the WTI parameter list \citep{WTIParameterList}. \\ \hline

NFR6 &  Sufficient error checks on the validity and completeness of data during import or input, as well as during a computation.  & System Testing \\ \hline %& The valid interval of the input parameters and the other possible validation errors must be tested via test-script. \\ \hline

NFR8 & Output of detailed deterministic results must enable all users to trace back the correctness of the implemented mechanism models. & System Testing \\ \hline %& See REQ 5 and REQ 8 in \autoref{xxx}. \\ \hline

NFR12 & The user-interface may not cause crashes during regular usage. & System Testing \\ \hline %& The tester should not get crash when testing the program.  \\  \hline

NFR14 & Consistency between the input data and the output data must be guaranteed. & System Testing \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline

NFR15 & The general required code coverage is 80\%, except for the Delta Shell Light components, therefore the code coverage of 60\% is required. & Component and Integration Testing \\ \hline %& See \autoref{chapter2} and \autoref{chapter3}. \\  \hline

%U158 & Voor elke WTI applicatie moet worden aangetoond dat de netwerk-installatie ook werkt binnen een Citrix omgeving.
 
U123   & De WTI Software moet tot een eenduidig en reproduceerbaar resultaat leiden. & System Testing \\ \hline

U124 & De WTI Software moet robuust zijn voor kleine variaties in de invoer. Onder 'robuust' wordt verstaan: nooit een software crash. Dus: ofwel een melding dat invoer onjuist is, ofwel een melding dat een som niet convergeert, ofwel een antwoord retourneert.  &  System testing  \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline

U129 & Alle componenten binnen een bibliotheek moeten foutcodes retourneren met een gestandaardiseerde (nog nader vast te stellen) betekenis of gebruiken excepties om fouten door te geven. & System testing \\ \hline %& Idem as NFR6. \\ \hline

U131 & Om de bibliotheken te kunnen testen levert elke bibliotheek testsoftware mee in de vorm van unit tests. & Component and Integration Testing \\ \hline

U132 & De IO laag sluit altijd aan op een intern bestand voor opslag van de invoer- en (tussen)resultaten. & System Testing \\ \hline %& See REQ 9 in \autoref{xxx}. \\ \hline

U133 & De WTI tools worden standaard alleen uitgeleverd met een Nederlandstalige UI en met Nederlandstalige meldingen en rapportages. & System Testing \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline

U145 & De naamgeving van objecten, parameters, functies moet over alle applicaties heen consistent zijn. Voor dat doel moet gebruik worden gemaakt van de actuele versies van de terminologielijst en de parameterlijst. & System Testing \\ \hline %& Idem NFR3. \\ \hline

TAB2 & De applicaties moeten door gebruikers gebruikt kunnen worden met standaardrechten. Het moet dus niet nodig zijn om de applicatie uit te voeren met administrator rechten, met uitzondering van installatie. & System Testing \\ \hline %& Can be tested via relevant test-script(s). \\ \hline

Top 10 & De gebruiker kan bepalen waar de gegevens worden neergezet. & System Testing \\ \hline %& See REQ 9 in \autoref{xxx}. \\ \hline

\end{tabular}
\end{table}


\section{Test levels} \label{sec:1.4}
According to \cite{OverallTestPlanWTI}, the program \ProgramNamePlusSpace should be tested on four different levels (V-Model):
\begin{enumerate}
	\item Component Testing
	\item Integration Testing
	\item System Testing
	\item Acceptance Testing
\end{enumerate}

\subsection*{Component Testing (Unit tests)}
Component Testing is testing on code level using the unit tests. For each relevant function, a unit test is defined within the C\# solution\footnote{A C\# solution is essentially a collection of source files and their relations. This collection is used to build the actual program. Besides the source code for the program itself it also contains the source code for the unit and system tests.}. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrative functions do not have unit tests. \\
Refer to \Cref{chapter2} for more information.

\subsection*{Integration Testing (Integration tests)}
Integration Testing is testing on functional level using integration tests. These types of tests combine multiple functions to prove that high level functionality works. For this, a unit test is defined within the C\# solution
 for each method with high level functionality.\\
Refer to \Cref{chapter3} for more information.

\subsection*{System Testing (Benchmarks and test scripts)}
System Testing is testing the functioning of the complete system:
\begin{itemize}%[no separator]
	\item The main calculator must provide the correct answers to confirm its performance according to the functional design;
	\item All possible errors must be handled and reported properly;
	\item The \textit{User Interface} must function properly.
\end{itemize}	
Refer to \Cref{chapter4} for more information.

\subsection*{Acceptation level (Acceptance tests)}
The Acceptance Test of \ProgramNamePlusSpace will be covered in the acceptance test for the overall WTI system (which includes acceptance tests for the stand-alone tools) and will be reported in a so-called Acceptance Report \citep{AcceptatieTestPlan}.


\section{Code coverage}\label{sec:1.5}

Testing is considered to be ok when all the unit tests pass and when the code coverage of those tests is more than 60\% so as prescribed in \cite{OverallTestPlanWTI}.

Note that within the context of this test plan the components which are not part of the program development, i.e. external component but also the DSL components, are not included in the test coverage.\footnote{For the DSL components separate test plans and test reports are available.}

To determine the code coverage of the \textit{Calculation} components, the feature `Code coverage' of Visual Studio can be used. This tool shows the percentage of the code that was tested in each assembly, class, and method, and is visible on the build server.





%------------------------------------------------------------------------------
\chapter{Component Testing (Unit tests)} \label{chapter2}

The tests on code level are the unit tests. For each relevant function, a unit test is defined within the C\# solution. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrational functions do not have unit tests.

These tests are considered to be ok when the unit tests pass and when the code coverage of those tests is more than 60\%, as prescribed in \cite{OverallTestPlanWTI} for UI solutions. For these tests, see the C\# solution.

The following information must be provided in the Test Report:\footnote{Unit tests are related directly to the implementation in source code and therefore have no direct relation to the functional requirements, referred to above.}
\begin{itemize}
	\item Number of unit tests
	\item Code coverage of the unit tests
	\item Specify if all unit tests succeed or not
\end{itemize}





%------------------------------------------------------------------------------
\chapter{Integration Testing (Integration tests)} \label{chapter3}

The tests on functional level are the integration tests. These types of tests combine multiple functions in the kernel to prove that high level functionality works. For this, an integration test is defined within the C\# solution for each method with high level functionality.

These tests are considered to be ok when the integration tests pass. For these tests, see the C\# solution. Both the source code and the external data for these tests and the unit tests are an integral part of the delivery.

The following information must be provided in the Test Report:
\begin{itemize}
	\item Number of integration tests
	\item Code coverage of the integration tests
	\item Specify if all integration tests succeed or not
\end{itemize}




%------------------------------------------------------------------------------
\chapter{System Testing (Benchmarks and Test Scripts)}  \label{chapter4}

The tests on this level are to provide proof of the fact that the program meets its acceptation criteria:
\begin{itemize}
	\item all main functions must provide the correct answers;
	\item all possible errors must be handled and reported properly;
	\item the functionalities of the \textit{User Interface} listed in the functional requirements (\Sref{sec:1.3.1}) must be present and work properly;
	\item the non-functional requirements listed in \Sref{sec:1.3.2} must be present and work properly.
\end{itemize}


\section{Test of the output} \label{sec:4.1}

Based on the formula in the Functional Design of the Grass Run-up Zone and the Grass Wave Impact Zone kernels, benchmarks were created to test both kernels \citep{GrassWaveRunupKernel_TestReport_15_2_1, GrassWaveImpactKernel_TestReport_15_2_1}. The same benchmarks can be used to test \ProgramName.

For the Grass Run-up calculation, there are 13 benchmarks:
\begin{enumerate}
	\item One stationary event, `not scaled' computation of cumulative overload
	\item One stationary event, `scaled' computation of cumulative overload
	\item One stationary event, `scaled' computation of cumulative overload, $z_{\text{eval}}$ = 2 m			
	\item One stationary event, `scaled' computation of cumulative overload, $z_{\text{eval}}$ = 3 m
	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{M}}$ = 1.5
	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{S}}$ = 0.8
	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{S}}$ = 0.8 and $\alpha_{\text{M}}$ = 2
	\item One stationary event, `scaled' computation of cumulative overload, small waves
	\item One stationary event, `scaled' computation of cumulative overload, very small waves
	\item One stationary event, `scaled' computation of cumulative overload, very large waves
	\item Synthetic storm data (time series), `not scaled' computation of cumulative overload
	\item Synthetic storm data (time series), `scaled' computation of cumulative overload
	\item Direct input storm data, `scaled' computation of cumulative
overload  	
\end{enumerate}

For the Grass Wave Impact calculation, there are 9 benchmarks:
\begin{enumerate}
	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - closed sod
	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - open sod
	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - fragmented sod
	\item `Direct input' storm event (Benedenrivierengebied) - closed sod
	\item `Direct input' storm event (Benedenrivierengebied) - open sod
	\item `Direct input' storm event (Kust) - open sod
	\item `Synthetic' storm event (Time series Q-variant)
	\item `Synthetic' storm event - Time series water level exceeds Q-Variant water level +0,03 m
	\item `Direct input' storm event (Vechtdelta deelgebied A -1) - closed sod - $t_{\text{s,top}} < t_{\text{s,top,min}}$
\end{enumerate}

The output of those benchmarks will be checked via unit tests and the result will be visible on the build server.


\section{Test of the error(s)/warning(s)} \label{sec:4.2}

The error(s) generated by an incomplete input or input outside its limits can be tested at code level via the unit tests, see \Cref{chapter2}, using the valid intervals of the input parameters given in the Functional Design \citep{GrassUI_FunctionalDesign}. Results of those unit tests will be visible on the build server.



\section{Test of the \textit{User Interface}} \label{sec:4.3}

The test of the \textit{User Interface} will be executed by a tester using \textit{Test Script(s)}. All the requirements listed in the Functional Design of the program (\Sref{sec:1.3.1}) and all the relevant non-functional requirements (\Sref{sec:1.3.2}) must be tested. 

A \textit{Test Script} describes a sequence of actions and the expected outcome. All the \textit{Test Scripts} are part of a so-called \textit{Test Document} that will be joined as Annex in the Test Report.



%------------------------------------------------------------------------------
\chapter{Literature}  \label{chapter5}

\bibliography{../DAM_references/dam_references}



\cleardoublepage

\pagestyle{empty}
\cleardoublepage
\mbox{}
\includepdf[pages=2, offset=-72 -70]{pictures/dam_cover_technical_design.pdf} % links-rechts past precies

%------------------------------------------------------------------------------
\end{document}
