Merge branch '87_FrameworkEvaluationAndQualityMeasures' into 'master'

87 framework evaluation and quality measures

See merge request !52

Documentation/src/02_product-documentation/03_architecture.tex

@@ -42,8 +42,10 @@
 		\subsection{Collaboration}
 			\subsubsection{GitLab}
 				The source code is centrally stored on a GitLab server, which offers integrated issue management and merge request capabilities, streamlining the development process and allows for better teamwork.
+				We chose to work with GitLab because the development team is familiar with it and it is our schools primary choice of environment for issue management and such.
 			\subsubsection{Microsoft Teams}
 				Microsoft Teams serves as the primary communication platform for online meetings and peer calls. Additionally, it functions as a data storage hub for documents that do not require source control, ensuring easy access to relevant information and resources.
+				We chose to work with Microsoft Teams because the whole team already had an account and is familiar with it.
 		\subsection{Build and Deployment}
 			More detailed description \hyperref[sec:buildTools]{here}
 			\begin{itemize}
@@ -51,6 +53,7 @@
 				\item Docker
 				\item GitLab CI/CD
 			\end{itemize}
+			Our lead backend-developer is already familiar with the above mentioned toolstack, which is why we chose to work with these tools.
 		\subsection{Testing}
 			More detailed description \hyperref[sec:testing-tools]{here}
 			\begin{itemize}
@@ -64,6 +67,7 @@
 				\item \href{https://github.com/novotnyllc/MetroLog}{Source on GitHub}
 			\end{itemize}
 			MetroLog allows to use different loggers, like file-based or in-memory ones, and adjust log levels to control logging detail.
+			This Logging-Package is specifically made for development with .NET MAUI, is easy to register and use and is thus a fitting choice for the team.
 			We defined a simple trace-logger for debugging in the development environment and a file-based logger in the apps executing directory.
 			Both loggers operate in the full scope of severity-levels (From Info to Critical).
 		\subsection{Documentation}

Documentation/src/02_product-documentation/04_quality-measures.tex

@@ -47,7 +47,23 @@
 			\begin{center}
 				\includegraphics[scale=0.5]{resources/SonarQube.png}
 			\end{center}
+			SonarQube allows the user to specify certain conditions which need to be fullfilled by the code base.
+			We have decided to specify following conditions:\vspace*{3mm}\\
+			\begin{center}
+				\includegraphics[scale=0.5]{resources/sonarqube_conditions.png}
+			\end{center}
+			\begin{itemize}
+				\item \textbf{Reliability Rating:} This refers to the total number of bug issues. (Rating A = 0 Bugs)
+				\item \textbf{Security Rating:} This refers to the total number of vulnerability issues. (Rating A = 0 Vulnerabilites)
+				\item \textbf{Coverage:} This refers to how many lines of code are covered by tests.
+				\item \textbf{Duplicated Lines:} This refers to how many lines of code are duplicated.
+			\end{itemize}
 
+		\subsection{Git-Branching \& Merges}
+		To avoid mistakes, we forbid any developer to push anything directly to the master branch.
+		We have defined that each developer should create a feature branch for a new Git issue, which is tagged with the issue number.
+		After a developer has implemented his feature and the definition of done is fulfilled, the developer can start a merge request via the Git server.
+		This merge request must be approved by someone else in order for the feature branch to be merged into the master branch.
 
 		\subsection{Sprint Retrospective}
 			The team defined a quality measure checklist, which needs to be inspected during the Sprint Retrospective.