Another round of typos.

tipps.tex

@@ -492,7 +492,7 @@ Paradoxe Anforderungen zeigen, dass gutes Design eine Kunst ist.
     der durch Vererbung und Polymorphie erreicht wird.
     Siehe auch \href{https://en.wikipedia.org/wiki/Open/closed_principle}{Open-Closed Principle}.
   \item Liskovsches Substitutionsprinzip bei Vererbung erfüllt?
-    Unterklassen sollte alle Nachbedingungen
+    Unterklassen sollten alle Nachbedingungen
     und alle Invarianten der Oberklasse erfüllen.
     Andernfalls könnte es zu Fehlern kommen,
     wenn eine Unterklasse als Oberklasse verwendet wird.
@@ -519,9 +519,9 @@ Paradoxe Anforderungen zeigen, dass gutes Design eine Kunst ist.
 
 Ähnlich zu den üblichen Entwurfsmustern,
 gibt es auch Anti-Entwurfsmuster.
-Also Muster die man im Entwurf erkennen kann,
+Also Muster, die man im Entwurf erkennen kann,
 die praktisch immer zu Problemen führen.
-Ein paar Beispiel, die in vergangenen PSE Projekten auftraten:
+Ein paar Beispiele, die in vergangenen PSE-Projekten auftraten:
 
 \begin{itemize}
   \item God Object.
@@ -531,12 +531,12 @@ Ein paar Beispiel, die in vergangenen PSE Projekten auftraten:
     Wenn das Model praktisch nur noch Datenspeicher ist.
     Objekt-Orientiertes Design zeichnet sich gerade dadurch aus,
     dass Daten \emph{und} Verarbeitung in Objekten zusammengebaut werden.
-    Objekte die nur zur Datenhaltung da sind
+    Objekte, die nur zur Datenhaltung da sind,
     erzwingen prozedurale Programmierung.
   \item \texttt{switch} und \texttt{instanceof}.
     Sieht man im Entwurf zwar noch nicht direkt,
     ist aber manchmal absehbar.
-    Dynamische Binding ist meistens die bessere Wahl.
+    Dynamische Bindung ist meistens die bessere Wahl.
 \end{itemize}
 
 \subsection{UML Diagramme}
@@ -580,7 +580,7 @@ Ein paar Beispiel, die in vergangenen PSE Projekten auftraten:
 \subsection{Inhalt der Präsentation}
 
 \begin{itemize}
-  \item Gerade für UML Diagramme wäre eine unkonventionelle Präsentation
+  \item Gerade für UML-Diagramme wäre eine unkonventionelle Präsentation
     mit \href{http://prezi.com/}{Prezi} einen Versuch wert.
     Man kann ein großes allumfassendes Klassendiagram zeigen
     und dann in Packages und Klassen reinzoomen.
@@ -591,19 +591,19 @@ Ein paar Beispiel, die in vergangenen PSE Projekten auftraten:
   \item Überblick über das Gesamtklassendiagramm, Pakete, Module geben.
     Hier kann man über die Verwendung von Entwurfsmustern erzählen.
     Das \textbf{Klassendiagramm} sollte den Kern der Präsentation bilden,
-    also sollte man hier auch die meiste Zeit für aufwenden.
+    also sollte man hierfür auch die meiste Zeit aufwenden.
   \item Ein großformatig ausgedrucktes Klassendiagramm vermittelt einen Eindruck von der Gesamtarchitektur
     und ist für die folgende Diskussion nützlich.
   \item Einhaltung softwaretechnischer Prinzipien zeigen
-    (z.B. Kohäsion, Lokalitätsprinzip, etc)
+    (z.B. Kohäsion, Lokalitätsprinzip, etc.)
   \item Gestrichene Wunschkriterien können, aber müssen nicht erwähnt werden.
     Man muss hier aufpassen, dass kein negativer Eindruck zurückbleibt.
     Für manches gibt es gute Gründe, aber oft ist es geschickter
     Streichungen nur im Dokument zu erwähnen.
   \item Verwendete externe Resourcen
-    (Bilder,Frameworks,Bibliotheken,Sounds,Musik,etc)
+    (Bilder, Frameworks, Bibliotheken, Sounds, Musik, etc.)
   \item Nur kurz erwähnen weil eher langweilig:
-    Eigene Formate, Datenbankschemata, Einstellungen, Menüstruktur
+    eigene Formate, Datenbankschemata, Einstellungen, Menüstruktur
     und Dialoge.
 \end{itemize}
 
@@ -776,7 +776,7 @@ but never to show their absence!
   \item Komplette Testszenarien aus dem Pflichtenheft durchgehen.
     Ein Testdurchlauf sollte möglichst automatisch ablaufen.
   \item \href{http://developer.android.com/tools/help/monkeyrunner_concepts.html}{Monkey Testing}
-    für einfaches GUI testen.
+    für einfaches Testen der GUI.
     Der Ertrag ist erfahrungsgemäß nicht sehr groß,
     also nicht zuviel Aufwand hineinstecken.
   \item \href{http://developer.android.com/tools/debugging/improving-w-lint.html}{Lint}
@@ -798,7 +798,7 @@ but never to show their absence!
 
 \subsection{Interne Abnahme}
 
-Von der Phaseneinteilung gehört die interne Abnahme zur Qualitätssicherung.
+Von der Phaseneinteilung her gehört die interne Abnahme zur Qualitätssicherung.
 Terminlich ist sie entweder zusammen mit dem Kolloquium der Qualitätssicherung
 oder kurz danach.
 Hier ist der Code nun endgültig \enquote{fertig},
@@ -810,15 +810,15 @@ Prüfungsunterlagen 5 Jahre lang aufzubewahren.
 Da niemand so genau weiß, was das im Fall von PSE bedeutet,
 wird am einfachsten \textsc{Alles} archiviert.
 \begin{itemize}
-  \item Source-code (TeX,Java,Makefile,C++,Python,HTML,etc):
+  \item Sourcecode (TeX, Java, Makefile, C++, Python, HTML, etc.):
     vermutlich einfach der Inhalt eures Versionskontrollsystems.
-  \item Artefakte (Compiliertes Programm, Dokumente, etc).
+  \item Artefakte (compiliertes Programm, Dokumente, etc.).
     Zwischenstufen (TeX .aux Dateien) kann man sich sparen,
     andererseits sind die auch nicht so groß.
 \end{itemize}
 
-Außerdem ist das der Zeitpunkt wo euer Betreuer
-zum letzten Mal euer Produkt testet.
+Außerdem ist das der Zeitpunkt,
+zu dem euer Betreuer zum letzten Mal euer Produkt testet.
 Falls es aufwendiger ist es lauffähig zu bekommen
 (bspw. auf ein Androidgerät laden)
 am einfachsten ein Gerät mit fertiger Software mitbringen.
@@ -868,7 +868,7 @@ Es sollten auch folgende Informationen in den Vortrag:
 Zu diesem Zeitpunkt habt ihr erfolgreich ein ordentliches Softwareprojekt
 von Anfang bis Ende durchgeführt.
 Selbst wenn nicht alles glatt lief,
-so könnt ihr trotzdem Stolz auf euch sein.
+so könnt ihr trotzdem stolz auf euch sein.
 Egal was ihr gemacht habt,
 völlig falsch kann es nicht gewesen sein.
 
@@ -892,8 +892,8 @@ Lasst euch stilistisch also woanders inspirieren.
 \newpage
 \section{Probleme im Team}
 
-Am schönsten ist PSE wenn alle Teammitglieder hochmotiviert sind,
-so dass alle ihren Beitrag leisten.
+Am schönsten ist PSE, wenn alle Teammitglieder hochmotiviert sind,
+sodass alle ihren Beitrag leisten.
 Manchmal läuft es auch so.
 Manchmal kracht es aber auch.
 
@@ -912,7 +912,7 @@ Ein wichtiger Punkt ist klare Erwartungen auszusprechen.
 Besprecht in der Gruppe Fragen wie die Folgenden:
 
 \begin{itemize}
-  \item Welche Note / Teilnote erwarte ich?
+  \item Welche Note/Teilnote erwarte ich?
     Ist eine 1,0 das klare Ziel oder bin ich schon mit 1,7 zufrieden?
   \item Welche Aufgaben müssen zu welchen Deadlines erledigt sein?
     Sollte der Phasenverantwortliche wöchentliche Deadlines festlegen?
@@ -941,7 +941,7 @@ Wichtig ist als erstes Fakten zu sammeln und aufzuschreiben.
 Wer hat wann welche Aufgabe mit welcher Deadline zugeteilt bekommen?
 Wer hat wann wieviel Stunden gearbeitet?
 Welche Deadlines wurden wie schlecht oder gar nicht eingehalten?
-Man braucht konkreten Fakten.
+Man braucht konkrete Fakten.
 Die Aufgabenverteilung kann der Phasenverantwortliche kontrollieren.
 Stundenzettel muss jeder für sich führen.