fix part 2

chapters/fazit.tex

@@ -29,7 +29,7 @@ Cases als auch der Funktionen der potenziellen Tools vorzunehmen.
 
 Erst wenn man sich in einem konkreten Use Case und auch in einer
 konkreten Toolumgebung befindet, werden aus dem generischen Maßnahmen
-für die Planung und das Design diejenige Detailtiefen entwickelt, die
+für die Planung und das Design diejenige Detailtiefen entwickelt, welche
 dann zu einer konkreten Umsetzungsmöglichkeit führen.
 
 ~
@@ -39,7 +39,7 @@ Problemlösung bestätigt.
 
 ~
 
-Der Inhalt dieser Seminararbeit beschränkte sich auf Probleme, die sich
+Der Inhalt dieser Seminararbeit beschränkte sich auf Probleme, welche sich
 vorwiegend durch Planung und technische Maßnahmen beheben lassen.
 
 Ein weiteres Problemfeld, welches nicht in dieser Arbeit betrachtet

chapters/grund.tex

@@ -78,7 +78,7 @@ betreffende System als \textbf{CI-CD Pipeline}\label{ci-cd-pipeline} bezeichnet.
 ~
 
 In Theorie und Praxis gibt es eine Vielzahl von Definitionen zu \cicd.
-Es gibt Funktionalitäten, die dem \cil zugeschrieben werden und an anderer
+Es gibt Funktionalitäten, welche dem \cil zugeschrieben werden und an anderer
 Stelle in einer Darstellung von \cicd dem \cdel zu
 geordnet wird. Zusätzlich wird häufig bei der Nennung der Abkürzung \cd
 nicht deutlich, ob \cdel oder \cdl gemeint ist.
@@ -125,7 +125,7 @@ aufzudecken oder auch auf schlecht wartbaren Code hinzuweisen.
 ~
 
 \cil wird meist durch sogenannte \textbf{\textit{Build-Server}}
-betrieben. Ein \textit{Build-Server} ist eine Software, die darauf spezialisiert ist, auf Anfrage
+betrieben. Ein \textit{Build-Server} ist eine Software, welche darauf spezialisiert ist, auf Anfrage
 Automatisierungen durchzuführen wie z.B. eine Integration. Diese
 automatische Integration wird in einer sterilen Umgebung ausgeführt.
 Eine solche Umgebung ist frei von umgebungsspezifischen Konfigurationen,

chapters/mass.tex

@@ -1,5 +1,7 @@
 \chapter{Empfehlungen für die Planung und Implementierung von CI/CD}
 \label{mas}
+Auch wenn ein CI/CD System nach der Einführung als Gesamtkomplex vorliegt, der schnell und einfach den Softwareentwicklungsprozess beschleunigt, ist es unumgänglich, sich bei der Einführung auf die Detailebene des Use Cases als auch der Tools zu begeben. Nur so besteht die Chance, später im Betrieb des Systems die Vorteile von CI/CD nutzen zu können.
+Während der xxx\todo{xx}Admin sehr viel dieses Detailkenntnisse besitzen wird, muss der Softwareentwickler nur das für ihn relevanten Wissen in Form von xx und xx vorliegen haben.
 
 Im Folgenden werden Empfehlungen aufgezeigt, welche das Auftreten der
 oben geschilderten Probleme verhindern können.

chapters/problems.tex

@@ -326,7 +326,7 @@ Featurebranch, sondern auf dem Masterbranch ausgeführt. Anstelle eine
 temporäre Testversion zu erhalten, bewirkt der Push auf dem Masterbranch
 die Ausführung von CI/CD für ein Release.
 
-Das bedeutet den Start der Releasepipeline, die Codeänderung landet als
+Dies führt zum Start der Releasepipeline. Die Codeänderung landet als
 neues Softwarerelease im Produktionssystem und nicht, wie gewünscht, in
 einer Testumgebung.
 
@@ -351,7 +351,7 @@ diese Löschung verloren gehen. \cite{plonski_herausforderungen_Leo_2020}
 $\Rightarrow$ Programmabbruch
 
 
-\subsubsection{\textbf{B06} -- unzureichende Tests - Nutzung des CI/CD Systems}\label{B06}
+\subsubsection{\textbf{B06} -- unzureichende Tests - Ungetesteter Code in Produktion}\label{B06}
 
 Die statische Codeanalyse erwartet den Source Code in einem spezifischen
 Ordner. Unkenntnis über diese Vorgabe kann dazu führen, dass der Source