Grammatik Kontrolle des gesamten Dokumentes

doku/content.tex

@@ -4,7 +4,7 @@ Wir möchten eine Plattform für Markthändler schaffen welche es ihnen
 ermöglicht geeignete Standflächen an attraktiven Standorten zu mieten.
 Zusätzlich sollen sie auf einer Plattform die Möglichkeit haben sich
 zu präsentieren. Diese Plattform soll interessierten Kunden einen
-Überblick über die verschieden Anbieter geben und somit Neugierde
+Überblick über den verschiedenen Anbietern geben und somit Neugierde
 wecken. Dies alles soll mit möglichst wenig Aufwand verwaltet
 werden können.
 
@@ -37,7 +37,7 @@ zum Projekt noch grafisch auf.
 
 \subsubsection{Risiken}
 Ein grosses Risiko ist das wir uns beim Erarbeiten der Datenbank sowie
-beim schreiben der Applikation in Details verlieren die nicht
+beim Schreiben der Applikation in Details verlieren die nicht
 gefordert werden. Sowie unter Umständen Dinge einbauen welche wir nicht
 genügend kennen. Dies könnte uns zu einem späteren Zeitpunkt zum Verhängnis
 werden.
@@ -54,21 +54,21 @@ werden.
     den Aufgaben zugeordnet. Abweichungen wurden mittels einer
     Abweichungsanalyse aufgezeichnet.
     \item Die Lösung wurde dokumentiert.
-    \item Eine Teilfunktion des Geschäftsmodell wurde in einer C\# Applikation
+    \item Eine Teilfunktion des Geschäftsmodells wurde in einer C\# Applikation
     abgebildet.
 \end{itemize}
 
 \subsection{Wunschziele}
 \begin{itemize}
-    \item Die Datenbank enthält alle statische Daten Wie
+    \item Die Datenbank enthält alle statischen Daten Wie
     etwa Länder, Städte, Postleitzahlen, Standorte.
     \item Die Datenbank enthält ein Rechtekonzept.
 \end{itemize}
 
 \newpage
 \section{User Stories}
-User Stories sind sind eine in Alltagssprache geschriebenen
-Software-Anforderungen. Sie sind bewusst kurz gehalten und
+User Stories sind eine in Alltagssprache geschriebenen
+Software-Anforderungen. Sie sind bewusst kurzgehalten und
 beschreiben die Wünsche und Ziele der Rollen welche die
 Software verwenden.
 
@@ -159,6 +159,7 @@ Wir haben uns dabei zu Beginn die folgenden drei möglichen Szenarien
 Bei dieser Lösungsvariante würde der komplette Registrierungsprozess
 abgebildet werden. Dabei würden auch die Adressdaten etc. der Person
 erfasst werden.
+
 \paragraph{Lösen eines Abonnements.}
 
 Das Lösen eines Abonnements würde beinhalten das eine bestehende
@@ -267,7 +268,7 @@ Notes & -\\
 UC History & 1.0 Draft erstellt durch AZ\\
  & 1.1 kleinere Anpassungen durch AZ\\
 \hline
-Author & A. Zweili \& I. Cadaroski\\
+Autor & A. Zweili \& I. Cadaroski\\
 \hline
 Date & 24. August 2017\\
 \hline
@@ -341,13 +342,13 @@ Date & 24. August 2017\\
  \hline
  Normal Flow & 1. User wählt einen Standort aus\\
   & 2. User wählt das Datum aus an dem er den Standort gerne mieten möchte.\\
-  & 3. User bestätigt die Miete mit einem Klick auf den Insert Button.\\
+  & 3. User bestätigt die Miete mit einem Klick auf dem Insert Button.\\
  \hline
  Alternative Flow
   & \textbf{Der Alternative Flow wurde in der Applikation nicht umgesetzt.}\\
   & 1. User wählt einen Standort aus\\
   & 2. User wählt das Datum an dem er den Standort gerne mieten möchte.\\
-  & 3. User bestätigt die Miete mit klick auf den Insert Button.\\
+  & 3. User bestätigt die Miete mit Klick auf dem Insert Button.\\
   & 4. Die Applikation meldet zurück das der Standort an diesem Datum\\
   & bereits besetzt ist.\\
  \hline
@@ -441,7 +442,7 @@ ursprünglich angenommen. \\ \hline
 
 Dokumentation & Doku & 25 & 45 & 20 & Wir haben bei dieser Arbeit
 wesentlich mehr Zeit in die Dokumentation investiert. Ein Teil davon
-ist sicher der Tatsache zu schulden das wir die Arbeit in LaTeX
+ist sicher der Tatsache zu Schulden das wir die Arbeit in LaTeX
 geschrieben haben. \\ \hline
 
 Vision & Doku & 1 & 1 & 0 & \ \\ \hline
@@ -449,7 +450,7 @@ Vision & Doku & 1 & 1 & 0 & \ \\ \hline
 User Stories & Doku & 2 & 2 & 0 & \ \\ \hline
 
 ERM erstellen & Doku & 3 & 2 & -1 & Beim RM haben wir weniger Details
-eingezeichnet sondern uns hauptsächlich darauf beschränkt uns eine
+eingezeichnet, sondern uns hauptsächlich darauf beschränkt uns eine
 grobe Übersicht zu verschaffen. \\ \hline
 
 ERD erstellen & Doku & 4 & 12 & 8 & Die Aufgabenstellung hat sich als
@@ -462,7 +463,7 @@ Aufwand, als ursprünglich gedacht. Da wir mit den Use Cases bereits
 gute Vorlagen hatten. \\ \hline
 
 SQL Code & & & & & \ \\ \hline
-SQL Scripts erstellen & Code & 7 & 8 & 1 & Das erstellen der Testdaten
+SQL Scripts erstellen & Code & 7 & 8 & 1 & Das Erstellen der Testdaten
 Scripts hat etwas mehr Zeit gebraucht als erwartet. Insbesondere da
 wir zuerst versucht haben, die Länder und Städte Listen bereits
 komplett zu erstellen. \\ \hline
@@ -470,9 +471,9 @@ komplett zu erstellen. \\ \hline
 C\# Code & & & & & \\ \hline
 Frontend (GUI) erstellen & Code & 25 & 30 & 5 & Der Aufbau unseres GUI
 zeigte sich um einiges komplizierte als wir es uns zu Anfang
-vorgestellt haben. Ein grosser Anteil des Aufwanfes ging an die
+vorgestellt haben. Ein grosser Anteil des Aufwandes ging an die
 Nachforschung des Codes verloren, da wir dies zu diesem Zeitpunkt noch
-nicht angewendet Haben. \\ \hline
+nicht angewendet haben. \\ \hline
 
 Datenbankverbindung & Code & 2 & 3 & 1 & Es entstand ein kleiner
 Mehraufwand, da bei Applikation jeweils der Verbindungsstring
@@ -487,17 +488,17 @@ Login und Registration & Code & 4 & 6 & -2 & Die ID- Vergabe und die
 Verarbeitung benötigten mehr Aufwand als vorgesehen \\ \hline
 
 Standort-Abfrage & Code & 6 & 9 & 3 & Durch Wissenslücken ging ein
-Grossteil der Zeit in der Infromationssuche verloren \\ \hline
+Grossteil der Zeit in der Informationssuche verloren \\ \hline
 
 Rent-Reservation-Eingabe & Code & 20 & 32 & 12 & Die Übergabe der
 verschiedenen ID`s in der Applikation warfen einige Probleme auf, die
-in der Reservation besonders Zum vorschein gekommen sind \\ \hline
+in der Reservation besonders Zum Vorschein gekommen sind \\ \hline
 
 Rent-Abfrage & Code & 8 & 8 & 0 & \\ \hline
 
 Coding (Verbinden der Funktionen) & Code & 20 & 40 & 20 & Da wir in
 unserer Applikation gleich mehrere Funktionen abgebildet
-haben(Login/Informationsabfrage/ Informationseingabe/Abfrage
+haben (Login/Informationsabfrage/ Informationseingabe/Abfrage
 eingefüllter Daten), war das darauffolgende Verbinden des Codes auch
 ein grosser Aufwand \\ \hline
 
@@ -522,9 +523,9 @@ Zur Zusammenarbeit am Code haben wir uns für Git entschieden. Dies
 ermöglichte es uns gleichzeitig am Code zu arbeiten und zwischendurch
 die Änderungen des anderen zu ``mergen''. Dies war von grossem Vorteil
 da wir so unabhängig voneinander am Code weiterarbeiten konnten. So
-entstanden insgesammt über 150 Commits.
+entstanden insgesamt über 150 Commits.
 
-Desweiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst
+Des Weiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst
 unabhängig voneinander arbeiten konnten und somit nicht aufeinander
 warten mussten.
 
@@ -585,14 +586,14 @@ jeweilige Standort hat damit mein ein Überbuchen verhindern kann.
 Sind die eigentlichen User im System. In der Regel verweisen sie auf
 eine reale Person können zu Testzwecken aber auch ohne eine reale
 Person im Hintergrund angelegt werden. Diese Entität wird dabei auch
-mit den jeweiligen Käufen verbunden damit man nachvollziehen kann wer
+mit den jeweiligen Käufen Verbunden damit man nachvollziehen kann wer
 diese getätigt hat. Hier wird auch gespeichert ob das Mitglied die
 notwendigen Dokumente unterzeichnet und die Kreditüberprüfung bestanden
 hat.
 
 \paragraph{member\_status / (Mitgliedsstatus)}
-Die Mitgliedsstatus Tabelle enthält die möglichen Stati die ein
-Mitglied haben kann. Dabei werden hier auch Mitglieder Stati wie
+Die Mitgliedsstatus-Tabelle enthält die möglichen Status die ein
+Mitglied haben kann. Dabei werden hier auch Mitglieder Status wie
 Mitarbeiter oder Admin erfasst.
 
 \paragraph{subscribtions / (Abonnemente)}
@@ -600,9 +601,9 @@ Beschreiben die Abonnementsarten welche von den Mitgliedern gekauft
 werden können.
 
 \paragraph{commercials / (Werbung)}
-Diese Tabelle enthällt alle Daten zu Änderungen des Webauftritt eines
+Diese Tabelle enthält alle Daten zu Änderungen des Webauftritts eines
 Mitgliedes. Diese Tabelle wird benötigt damit sichergestellt werden
-kann das ein Mitglied nur nur die zugelassene Anzahl an Änderungen
+kann das ein Mitglied nur die zugelassene Anzahl an Änderungen
 beantragt.
 
 Je nach Kundenwunsch könnte man diese noch erweitern um zusätzliche
@@ -617,15 +618,15 @@ Zusätzlich wird erfasst an welchem Tag der Check geplant ist und Ob
 der Check bestanden wurde.
 
 \paragraph{subscription\_orders / (Abonnementsbestellungen)}
-Enthält die Abokäufe die ein Mitglied macht und welcher Standort dabei
+Enthält die Abo Käufe die ein Mitglied macht und welcher Standort dabei
 gewählt wurde Sowie an welchem Tag der Kauf getätigt wurde. Das
 Kaufdatum kann in der finalen Version dazu verwendet werden zu
 berechnen ob das aktuelle Abo noch gültig ist oder nicht.
 
 \paragraph{trial\_period / (Probezeit)}
 Beinhaltet die Zeit wie lange die Probezeit ist damit diese nicht als
-ein Fixwert im Code abgelegt werden muss. Diese sollte es ermöglichen
-das die Dauer der Probezeit auch nachträglich noch einfach angepasst
+ein Fix Wert im Code abgelegt werden muss. Diese sollte es ermöglichen
+dass die Dauer der Probezeit auch nachträglich noch einfach angepasst
 werden kann.
 
 \paragraph{rents / (Mieten)}
@@ -641,7 +642,7 @@ Interessengruppen anzupassen.
 
 \paragraph{RentedLocations}
 Damit wir die getätigten Mieten in der Applikation sauber ausgeben
-können war es nötig eine View zu erstellen. Diese behinhaltet drei
+können war es nötig eine View zu erstellen. Diese beinhaltet drei
 ``inner joins'' über die Tabellen ``members'', ``rents'',
 ``rent\_prices'' und ``locations''. Somit kann man einsehen welches
 Mitglied an welchem Ort und zu welchem Preis einen Stand gemietet hat.
@@ -665,7 +666,7 @@ Mitglied an welchem Ort und zu welchem Preis einen Stand gemietet hat.
 
 \subsection{C\#}
 
-In dieser Sektion wird das Erstellen einer kleiner Anwendung
+In dieser Sektion wird das Erstellen einer kleinen Anwendung
 beschrieben, in der wir gewisse Segmente unserer Datenbank abrufen und
 bearbeiten können. Damit zeigen wir die Funktionalität und
 Verarbeitung unsere Datenbank auf.
@@ -694,7 +695,7 @@ Hier werden alle eingesetzten Klassen der Applikation vorgestellt
 und definiert.
 
 Zu jeder Klasse gibt es eine passende Grafik welche ihre Methoden und
-Attribute beschreibt. Nachfolgend habe wir eine Beispiel Grafik, Abbildung:
+Attribute beschreibt. Nachfolgend haben wir eine Beispiel Grafik, Abbildung:
 (\ref{fig:class_example}) eingefügt welche die Symbole und den Aufbau
 beschreibt.
 
@@ -760,7 +761,7 @@ Abbildung: (\ref{fig:dashboard}) aufgezeigt und/ oder eingefügt. Damit
 möchten wir einen Teil der finalen Applikation und Datenbank abbilden
 mit dem, die Benutzer Standorte heraussuchen und den Mietbeginn
 eingegeben können. Um einen Standort zu mieten muss ein User sich
-zuerst einen Standort heraussuchen und diesen markieren. Anschliesend
+zuerst einen Standort heraussuchen und diesen markieren. Anschliessend
 kann er das passende Datum markieren und zum Abschluss die Miete mit
 dem ``Rent-Button'' tätigen.
 
@@ -800,7 +801,7 @@ Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in
 C\# Klassen der ``locations'', ``rents'' und ``members'' erstellt, die
 sie abbilden. Damit nehmen die dazu benötigten Spalten der jeweiligen
 Tabellen entgegen. Danach werden die benötigten Datensätze mit den
-``Methoden-Infos'' der derweiligen Klasse aufgerufen.
+``Methoden-Infos'' der derzeitigen Klasse aufgerufen.
 
 Die ``GetMembers'' Klasse, Abbildung: (\ref{fig:getmembers}), wird für
 die Registration und den Login der Mitglieder benötigt:
@@ -812,7 +813,7 @@ die Registration und den Login der Mitglieder benötigt:
   \label{fig:getmembers}
 \end{figure}
 
-Die ``GetLocations'' Klasse, Abbildung: (\ref{fig:getlocations}), für
+Die ``GetLocations'' Klasse, Abbildung: (\ref{fig: getlocations}), für
 das Herauslesen der Märkte um dem Mitglied alle im Moment
 hinzugefügten Mietoptionen darzubieten:
 
@@ -841,16 +842,16 @@ und Abbilden der jeweiligen Märkte:
 	Test-Anwender der Datenbank angepasst werden.
 
 \item Insert Data
-	Nach den ersten Test's wurde uns klar, dass wir ein Problem mit
-    der weitergabe der ID's hatten. Der Fehler kam erst ans Licht, als wir
+	Nach den ersten Tests wurde uns klar, dass wir ein Problem mit
+    der Weitergabe der ID's hatten. Der Fehler kam erst ans Licht, als wir
     anfingen die jeweiligen ``locations'' und ``members''- ID's durch das
-    GUI einzufügen. Gelöst wurde das ganze mit einer statischen Klasse.
+    GUI einzufügen. Gelöst wurde das Ganze mit einer statischen Klasse.
 
 \end{itemize}
 
 \subsubsection{Addons/ Packages}
 Dapper \cite{dbcs6} ist ein simpler ``object mapper'' für .NET. Wir
-nutzen ihn anstelle von einem ADO.NET data reader da er nütziche
+nutzen ihn anstelle von einem ADO.NET data reader da er nützliche
 Erweiterungen bei unserer IDbConnection bietet, indem er
 Erweiterungsmethoden zur Datenbankabfrage bietet.
 
@@ -964,24 +965,25 @@ und gibt Die in TC-08 getätigte Miete aus. & Mietliste wurde Befüllt.
 
 \section{Fazit}
 
-Im Bezug auf die Planung verlief diese Case Study wesentlich besser
-als die vorherige. Insbesondere die Zeitplanung lief sehr gut. Wir
-hatten zwar geplant nach den Sommerferien mit der Arbeit fertig zu
-sein was wir schlussendlich nicht erreicht hatten. Jedoch wurden wir
-ca. einen Monat später, Anfangs September, mit dem grössten Teil der
+In Bezug auf die Planung verlief diese Casestudy wesentlich besser
+als die vorherige in Webtechnologie. 
+Insbesondere die Zeitplanung lief sehr gut, da wir diesbezüglich Erfahrungen aus der Webtechnologie- Case Study mitnehmen konnten. 
+Wir hatten zwar geplant nach den Sommerferien mit der Arbeit grösstenteils fertig zu
+sein, was schlussendlich nicht erreicht wurde. Jedoch wurden wir
+ca. einen Monat später, (anfangs September), mit dem grössten Teil der
 Arbeit fertig und lagen somit immer noch sehr gut in der Zeit.
 
-Durch die regelmässigen Meetings waren wir bezüglich dem Fortschritt
+Durch die regelmässigen Meetings, waren wir bezüglich des Fortschritts
 immer auf dem aktuellsten Stand. Zusätzlich ermöglichten uns die
-Meetings frühzeitig Korrekturen bezüglich der Planung vorzunehmen und
+Meetings frühzeitig Korrekturen der Planung vorzunehmen und
 somit allfällige Probleme zu umgehen.
 
-Desweiteren hatten wir so auch ideal Zeit technische Schwierigkeiten
-miteinander zu besprechen. Wie etwa wie wir gewisse Entitäten abbilden
-wollen oder bei Problemen bei der C\# Applikation.
+Des Weiteren hatten wir so auch ideal Zeit technische Schwierigkeiten
+miteinander zu besprechen. Beispielsweise wie wir gewisse Entitäten abbilden
+möchten, oder Probleme die bei der C\# Applikation auftraten.
 
 Die C\# Applikation war insgesamt der grösste Knackpunkt dieser
-Casestudy. Die Anwendung funktioniert soweit wie geplant könnte in
+Casestudy. Die Anwendung funktioniert so weit wie geplant, jedoch könnte sie in
 dieser Form allerdings wohl eher nicht produktiv eingesetzt werden.
 
 Der Aufbau der Datenbank hat uns dazu im Vergleich verhältnismässig
@@ -990,8 +992,8 @@ schwammige Beschreibung der Anforderung des Kunden.
 
 Wie auch in der letzten Case Study hat sich das Arbeiten mit Git
 wieder bewährt. Allerdings könnten wir uns die Funktionen von Git
-stärker zu nutzen machen. Etwa Test Branches erstellen um schnell
-etwas zu testen oder die Commits noch sauberer zu erstellen damit man
+stärker zu nutzen machen. Etwa Test Branches erstellen, um schnell
+etwas zu testen, oder die Commits noch sauberer zu erstellen, damit man
 einfacher mit ihnen arbeiten kann.
 
 Bezüglich der Dokumentation haben wir uns ein gute und stabile