
\section{Quality assurance}

\subsection{Reviews}

All documents will be reviewed by the project group and other appropriate interest groups. In addition to the documents, most relevant parts of the program code will also be reviewed.

A document or part of code will be frozen a few days before it's review. Between freezing and the review, no changes may be made to it.

\

\begin{tabular}{lll}
\textbf{Document}&\textbf{Freezing date}&\textbf{Review}\\
Requirements specifications&13.6.&17.6.\\
Design document&18.7.&20.7.\\
\end{tabular}

\

Anni is responsible for organizing the reviews and she will prepare a checklist for the document to be reviewed by the freezing date. All participating to the review will read the frozen document in advance, looking for possible errors and comparing it to the checklist.

In the review, found errors will only be noted and written down. They will be assigned to someone to be fixed later, usually the person who wrote the part. The errors will not be discussed during the review, that way as many errors as possible may be found.

\subsection{Coding style}

The project group will follow a uniform coding style throughout the program.

\begin{itemize}
\item Java code will follow the standard convention for Java, described in [Java99].
\item Fortran code will follow the convention proposed in [Fort01].
\end{itemize}

\subsection{Testing}

\textit{Testing} is an integral part of the development of any software. It is a way to 
(1) prove in practice that the software meets the requirements it has been developed to fulfill.  Also, (2) it verifies that the software works properly in the usual cases. 


\subsubsection{System tests}
Tests of the former category are called \textit{system tests}: They verify that the software,  as a whole, meets the required criteria. System tests are, in a way, superficial: They don't concern the inner structure of the software, they only look at the input-output interaction and functionality. In specific efficiency matters they may measure the time it takes for a function to complete. This enables us to design system tests as early as in the analysis phase. 
\subsubsection{Unit and integration tests}
Tests of the latter category have two subcategories: \textit{unit tests} and \textit{integration tests}. The former ones check that individual parts of the software function as they were planned to, and the latter ones, integration tests, check that the parts function correctly with the other parts that they are planned to interact with. So, naturally, designing both of these tests requires the information brought by the design phase, where the internal structure of the software is planned. 

\subsubsection{Phases of testing}
Any part should be tested before it is finished, and any part that is tested as functional is finished unless further requirements are set. The testing of individual parts is carried out in the implementation phase with the unit tests in this manner. Also, parts with common interfaces are tested with integration tests so that they function together in the expected manner. 
After the software is fully featured the system tests come in: They are to verify in the testing phase that all the requirements that were planned indeed are fulfilled. After the software passes the system tests it could be considered ready for release.

\subsubsection{Testing practices used}
The project group will use a standard testing practice for code in the Java programming language, such as JUnit. This will be decided later. 
For Fortran(90/95) another standard might be used or tests could be designed in a non-standard way if that better suits the case. 
A \textit{testing document} will be produced and updated as components are tested; The testing document will monitor the functionality implemented and that yet to be developed. 
The document will contain detailed information about each test, which part(s) of the software it is for, and in the case of system tests, the requirement that the test checks for. \newline
The document lists bugs found and their status; these tell on a smaller scale about the status of different parts and the completeness of different requirements. \newline 
Each bug entry can have a status of: \newline

\begin{tabular}[]{l p{10cm}}
Open & That is, discovered and not yet dealt with \\
& \\
Fixed & Found and fixed, but not reviewed by the one that reported the bug \\
& \\
Closed & Found, fixed and verified to have been fixed by the person who reported the bug \\
\end{tabular}
\vspace{.5cm}

Bugs will be tracked and fixed in this manner through the course of the project.
