
\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{enumitem}
\usepackage{tikz}
\usepackage{multicol}

\title{Qualitätsziele}
\begin{document}
\maketitle
\section*{Beschreibung}

\subsection*{Funktionale Eignung}
	Zu häufigen Qualitätsaspekte oder auch Qualitätsmerkmale zählt zunächst die \textbf{Funktionale Eignung}. Das ist die Voraussetzung, dass die Software die erwarteten Anforderungen erfüllt.
		
\subsection*{Zuverlässigkeit}
	Die \textbf{Zuverlässigkeit} ist wichtig, wenn die Leistung der Software über einen bestimmter Zeitraum entsprechend den Anforderungen erfüllt werden muss. Gerade bei einer großen Nutzerbasis wie es bei einem Flughafen der Fall ist, ist dieser Aspekt von hoher Bedeutung.

\subsection*{Kompatibilität}
	Findet eine Interaktion mit anderen Systemteilen statt, so ist wichtig, dass \textbf{Kompatibilität} herrscht. Das bedeutet, dass sie problemlos Informationen austauschen können oder auf der entsprechenden Hard- und Softwareumgebung laufen.
		
\subsection*{Benutzbarkeit}
	Da mit Anwender leicht mit dem Programm umgehen können und es möglichst wenig menschliche Fehler gibt, ist eine hohe \textbf{Benutzbarkeit} wichtig. 

\subsection*{Leistungseffizienz}
	Damit die Anwendung keine unnötigen Kosten verursacht, ist die \textbf{Leistungseffizienz}, also der Umgang mit Ressourcen wie Speicherplatz und Bearbeitungszeit wichtig.

\subsection*{Sicherheit}
	Um Fehlverhalten aufgrund von nicht autorisierten Zugriffen zu verhindern ist die \textbf{Sicherheit} der Anwendung wichtig. Trotzdem muss der Zugang zu den Daten für diejenigen, die darauf zugreifen dürfen nicht verwehrt sein.

\subsection*{Wartbarkeit}
	Tauchen während der Anwendungszeit Fehler aufgrund einer Veränderung der Umgebung auf, sollen diese möglichst leicht entfernt werden können. Dazu ist ein gut \textbf{Wartbarkeit} wichtig. Dafür ist eine Wiederverwendbarkeit von Programmteilen hilfreich.
\subsection*{Übertragbarkeit}
	Falls sich Hard- oder Software ändert, ist es gut, wenn die Anwendung eine stabile \textbf{Übertragbarkeit} aufweist, damit die Anwendung problemlos auch auf anderen Rechnern laufen kann. 

	\section*{Bemerkungen}


	Außerdem gibt es noch die \emph{Qualitätsziele}, die ein angestrebte Qualitätsaspekte darstellen, die in der Anwendung relevant sind. Das kann zum Beispiel "Robustheit gegen hohe Netzlast" sein.  Häufig finden Wechselwirkungen zwischen verschiedenen Qualitätsaspekten statt, sodass sie sich gegenseitig ausschließen. Dadurch können nie alle Qualitätsziele vollständig erfüllt werden (Zeit- vs. Verbrauchverhalten, Sicherheit vs. Benutzbarkeit, Leistungseffizienz vs. Wartbarkeit, ...). In diesen Fällen muss überprüft werden, welches Ziel die höhere Priorität hat.

	Die Gesamtheit aller Qualitätsziele bildet die \emph{Qualitätsanforderung}. Um diese überprüfen zu können müssen alle Qualitätsziele konkret festgehalten werden. Teilweise kann der Erfolg eines Qualitätsaspektes in \emph{Qualitätsmetriken} gemessen werden diese können während der Laufzeit gemessen werden (Transaktionen pro Stunde, Anzahl paralleler Benutzer, MTBF (mean time between failures), LOC (lines of code), Anzahl der Accounts mit bestimmter Zugriffsberechtigung, ...) oder durch Analyse des Codes festgestellt werden (Anzahl der Schnittstellen, Anzahl an Geschäftsprozessen, ...). Es ist wichtig, das bei der Planung der Metriken festgehalten wird, wie genau gemessen wird, da gerade bei statischen Analysen die zum Beispiel die Zählweise unterscheiden kann.

	Ein Beispiel für eine feste Metrik für die Metrik der Komplexität ist die McCabe-Metrik. Sie zählt die Anzahl der if-Anweisung, der Schleifen und der Anzahl der Zweige.

	In einem \emph{Qualitätsmodell} kann der Kunde zunächst abstrakte Qualitätsziele definieren, diese auf seinen angewendet konkretisieren und schließlich messbare Indikatoren und Metriken finden. Ein solches Modell sollte sich im Lastenheft wiederfinden. Dabei kann es helfen, \emph{Qualitätsszenarien} zu entwickeln, die festlegen wie das System in einer bestimmten Situation sich zu verhalten hat. Diese Szenarien lassen sich in drei Typen unterteilen: Verwendungsszenarien im Fall der Standardverwendung des Systems, Änderungsszenarien, also Abweichungen von der Standardanwendung, und Stressszenarien, im Fall von unerwarteten Veränderungen.

		Zusätzlich gibt es, nachdem die funktionalen Anforderungen und Qualitätsanforderungen geklärt sind, noch die \emph{constrains}. Sie sind weitere Bedingungen des Kunden, beispielsweise an das Format von Daten oder das Einhalten  der DSGVO.

		\newpage
		\section*{Qualitätsmerkmale nach ISO/IEC 25010}
		\begin{multicols}{2}


\subsection*{Funktionale Eignung}

\begin{itemize}
\item
  Funktionale Vollständigkeit
\item
  Funktionale Korrektheit
\item
  Funktionale Angemessenheit
\end{itemize}

\subsection*{Zuverlässigkeit}

\begin{itemize}
\item
  Reife
\item
  Verfügbarkeit
\item
  Fehlertoleranz
\item
  Wiederherstellbarkeit
\end{itemize}

\subsection*{Kompatibilität}

\begin{itemize}
\item
  Koexistenz
\item
  Interoperabilität
\end{itemize}

\subsection*{Benutzbarkeit}

\begin{itemize}
\item
  Verständlichkeit
\item
  Erlernbarkeit
\item
  Bedienbarkeit
\item
  Schutz vor Fehlbedienung
\item
  Attraktivität der Nutzungsoberfläche
\item
  Barrierefreiheit
\end{itemize}

\subsection*{Leistungseffizienz}

\begin{itemize}
\item
  Zeitverhalten
\item
  Verbrauchsverhalten
\item
  Kapazität
\end{itemize}

\subsection*{Sicherheit}

\begin{itemize}
\item
  Vertraulichkeit
\item
  Integrität
\item
  Nachweisbarkeit
\item
  Verantwortlichkeit
\item
  Authentizität
\end{itemize}

\subsection*{Wartbarkeit}

\begin{itemize}
\item
  Modularität
\item
  Wiederverwendbarkeit
\item
  Analysierbarkeit
\item
  Änderbarkeit
\item
  Testbarkeit
\end{itemize}

\subsection*{Übertragbarkeit}

\begin{itemize}
\item
  Anpassbarkeit
\item
  Installierbarkeit
\item
  Austauschbarkeit
\end{itemize}
	\end{multicols}

%\begin{figure}[h]
%	\includegraphics[width=0.5\columnwidth]{./images/Merkmale.png}
%\end{figure}


\end{document}
