Small changes.

chapter/AnforderungenUndNutzererwartungen.tex

@@ -318,7 +318,7 @@ \subsubsection{Verborgene Erwartungen}
 Ein weiteres Beispiel, welches ebenfalls im Kontext \gqq{DEV-CHAT} relevant ist, ist die Unabhängigkeit der Applikation von dem Betriebssystem, beziehungsweise der Art der zugrundeliegenden Hardware.
 
 \subsubsection{Prägende Erwartungen}
-Prägende Erwartungen ergeben sich aus der Erfahrungen mit der Benutzung bestimmter Applikationen.
+Prägende Erwartungen ergeben sich aus der Erfahrungen mit der Benutzung bestimmter App\-li\-ka\-tio\-nen.
 Bestimmte Interaktionsmuster oder auch Designentscheidungen werden durch eine regelmäßige Benutzung verinnerlicht und als intuitiv empfunden.
 Ein Beispiel hierfür ist Social Media.
 Die meisten Nutzer sind mit der Benutzung von Social-Media-Plattformen vertraut und kennen den Sinn und Zweck der enthaltenen Interaktionselemente.

chapter/Einleitung.tex

@@ -4,12 +4,12 @@ \section{Einleitung}
 Hierzu wird das Softwareprodukt \gqq{DEV-CHAT} aus der Vorlesung Software-Engineering 1 verwendet.
 \newparagraph
 %Beschreibung devchat
-DEV-CHAT ist ein Chatportal mit mehreren Chatrooms, denen man über einen Schlüssel beitreten kann.
+\gqq{DEV-CHAT} ist ein Chatportal mit mehreren Chaträumen, denen man über einen Schlüssel beitreten kann.
 Die Oberfläche ist schlicht im Informatik/Konsolen Stil gehalten und alle Operationen werden über eine Kommandozeile ausgeführt.
 Über die Kommandozeile lassen sich Befehle ausführen, um zum Beispiel Direktnachrichten zu senden oder Umfragen zu starten.
 \newparagraph
 %Aufgabenstellung
 Zu Beginn der Hausarbeit werden, wie bereits angekündigt, die Begriffe Softwarequalität und Qualität definiert und gegeneinander abgegrenzt, anschließend wird das Kano-Modell erläutert und begründet, wieso Requirements Engineering essenziell für eine hohe Softwarequalität ist.
-Die Folgeschritte werden auf den DEV-CHAT angewandt, diese gliedern sich in drei Punkte.
+Die Folgeschritte werden auf den \gqq{DEV-CHAT} angewandt, diese gliedern sich in drei Punkte.
 Zunächst werden die Anforderungen und Nutzerwartungen definiert, in einem weiteren Schritt werden Fehler, Kosten und Qualitätsmaßnahmen behandelt.
 Abschließend wird das Thema Umsetzung und Tests erörtert.

chapter/FehlerKostenQualitaetsmaßnahmen.tex

@@ -20,7 +20,7 @@ \subsection{Faults und Defects}
         % Fehlerschwere (1-5) (Prio auch noch mit rein?)
         % Priorität
         % potentielle Fehlerkosten
-Im folgenden Abschnitt werden die typischen Faults und Defects des DEV-CHAT's dargestellt.
+Im folgenden Abschnitt werden die typischen Faults und Defects des \gqq{DEV-CHAT}'s dargestellt.
 Zusätzlich werden die Fehlerschwere, Priorität und potentielle Fehlerkosten identifizert und dargestellt.
 Dies ist in der Tabelle \ref{tab:FaultsAndDeffects} dargestellt.
 Die Fehlerschwere wird aus Nutzersicht beschrieben und teilt sich in fünf Kategorien die in der nachfolgenden Auflistung definiert werden.
@@ -112,7 +112,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz}
     \textbf{Check}: Vergleich Sollzustand und Istzustand.\\
     \textbf{Act}: Abhängig davon, ob die Maßnahmen erfolgreich sind, werden diese als Standard definiert oder der Prozess wird erneut durchlaufen.
 \end{quote}
-Da DEV-CHAT einmalig in der Vorlesung Software-Engineering entwickelt wurde, wird es einen weiteren Entwicklungsprozess mit dieser Teamkonstellation nicht geben, weshalb eine Prozessoptimierung nur theoretisch durchgeführt werden kann.
+Da \gqq{DEV-CHAT} einmalig in der Vorlesung Software-Engineering entwickelt wurde, wird es einen weiteren Entwicklungsprozess mit dieser Teamkonstellation nicht geben, weshalb eine Prozessoptimierung nur theoretisch durchgeführt werden kann.
 Die Probleme und die zugeordneten Maßnahmen der Plan Phase werden in Tabelle~\ref{tab:pdca} dargestellt.
 \begin{table}[H]
   \centering
@@ -154,7 +154,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz}
 Alternativ zu der PDCA-Analyse kann auch \ac{CMMI} verwendet werden, auf welches in dieser Arbeit nicht tiefer eingegangen wird.
 \newparagraph
 Bei der Produktverbesserung wird die Qualität des tatsächlichen Produkts verbessert.
-Da DEV-CHAT nur im Rahmen der Vorlesung entwickelt wurde und nicht veröffentlicht wird, ist eine Qualitätsoptimierung auch nur theoretisch durchführbar. 
+Da \gqq{DEV-CHAT} nur im Rahmen der Vorlesung entwickelt wurde und nicht veröffentlicht wird, ist eine Qualitätsoptimierung auch nur theoretisch durchführbar. 
 Sollte eine Weiterentwicklung bzw. eine Veröffentlichung erfolgen, sollten die Untenstehenden Punkte abgearbeitet werden.
 \begin{itemize}
     \item Erweiterung der UnitTests, bisher nur Exemplarisch
@@ -166,7 +166,7 @@ \subsection{Qualitätskostensenkung und Fehlertoleranz}
 \subsection{\acl{FMEA}}
 \label{sec:FMEA}
 % Failure Mode and Effects Analysis (FMEA) (realistische Annahme für Risikoprioritätszahl RPZ
-Im folgenden wird für den DEV-CHAT eine \ac{FMEA} durchgeführt.
+Im folgenden wird für den \gqq{DEV-CHAT} eine \ac{FMEA} durchgeführt.
 \gqq{
     Ziel der FMEA ist es, bei der Entwicklung eines Produktes bzw. der Bearbeitung einer Aufgabe mögliche Fehler frühzeitig zu erkennen, um die Funktion sowie die Sicherheit und eine hohe Produkt- bzw. Prozessqualität gewährleisten zu können.
     Durch die frühzeitige Erkennung können sowohl die Anlaufkosten und die entstehenden Kosten infolge von Rückrufaktionen und Reklamationen reduziert werden als auch die Entwicklungszeit verkürzt werden

chapter/GrundwissenUndBegriffe.tex

@@ -45,7 +45,7 @@ \subsection{Kano-Modell}
 Die x-Achse definiert dabei den Grad der Erfüllung der Merkmale, wobei die y-Achse den Grad der Kundenzufriedenheit darstellt.
 
 Die rote Kurve in Abbildung~\ref{fig:kano-modell} zeigt die Charakteristik der Basismerkmale.
-Während eine unzureichende Erfüllung des Merkmals eine negative Kundenzufriedenheit verursacht, führt eine übermäßige Erfüllung des Merkmals nicht zu einer positiven Kundenzufriedenheit, da diese Merkmale als absolutes Minimum (Must-be) angesehen werden.
+Während eine unzureichende Erfüllung des Merkmals eine negative Kundenzufriedenheit verursacht, führt eine übermäßige Erfüllung des Merkmals nicht zu einer positiven Kundenzufriedenheit, da diese Merkmale als absolutes Minimum (must-be) angesehen werden.
 
 Im Gegensatz dazu stehen die Leistungsmerkmale, welche durch die blaue Kurve charakterisiert werden.
 Hierbei handelt es sich um einen linearen Zusammenhang zwischen dem Grad der Erfüllung eines Merkmals und der Kundenzufriedenheit.

chapter/UmsetzungTests.tex

@@ -172,7 +172,7 @@ \subsubsection*{Testumfang}
 In der Konzeptionsphase wurden die Use-Cases des Systems modelliert und Abläufe definiert.
 Mit den Systemtests werden diese Abläufe simuliert und überprüft, ob diese wie erwartet funktionieren.
 Abschließend werden Akzeptanz-Tests verwendet um die User-Storys zu verifizieren.
-Während der Production werden Availability-Tests durchgeführt, um die Verfügbarkeit zu gewährleisten.
+Während dem Betrieb des \gqq{DEV-CHAT} werden Availability-Tests durchgeführt, um die Verfügbarkeit zu gewährleisten.
 \subsubsection*{Teststrategie}
 Bei der Entwicklung wird der \ac{TDD} Ansatz verfolgt, d.h. dass die Tests vor der Entwicklung der Funktion geschrieben werden.
 Zusätzlich wird \ac{CI} verwendet, um einen automatisierten Build der Software zu erstellen und um die Tests auszuführen.
@@ -190,7 +190,7 @@ \subsubsection{Testfall 1: Benutzer registrieren}
 % Testfall 1: Benutzer registrieren
 Bei diesem Test wird überprüft, ob ein Benutzer sich registrieren kann.
 \paragraph{Ablaufbeschreibung} \mbox{}\\
-Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist noch nicht registriert. Folgende Schritte:
+Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist noch nicht registriert. Folgende Schritte:
 
 \begin{enumerate}
   \item Website Aufrufen.
@@ -215,7 +215,7 @@ \subsubsection{Testfall 2: Nachrichten senden}
 % Testfall 2: Nachrichten senden
 Bei diesem Test wird überprüft, ob ein Benutzer Nachrichten senden kann.
 \paragraph{Ablaufbeschreibung} \mbox{}\\
-Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: 
+Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: 
 
 \begin{enumerate}
   \item Website Aufrufen.
@@ -241,7 +241,7 @@ \subsubsection{Testfall 3: Administrationsbereich aufrufen}
 % Testfall 3: Administrationsbereich aufrufen
 Bei diesem Test wird überprüft, ob ein Benutzer den Administrationsbereich aufrufen kann.
 \paragraph{Ablaufbeschreibung} \mbox{}\\
-Ausgangssituation: Instanz wird ausgeführt und mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: 
+Ausgangssituation: Instanz wird ausgeführt und ist mit dem Browser erreichbar. Der Benutzer ist eingeloggt. Folgende Schritte: 
 \begin{enumerate}
   \item Website Aufrufen.
   \item Den Button \gqq{Admin Settings} klicken.

main.tex

@@ -162,7 +162,7 @@
   \include{pages/abkuerzungsverzeichnis}
   \include{pages/abbildungsverzeichnis}
   \include{pages/tabellenverzeichnis}
-  \include{pages/listingsverzeichnis}
+  % \include{pages/listingsverzeichnis}
   % \include{pages/vorwort}