Anmerkungen_schlachter_praxisarbeit.txt

Erst mal ein paar grundsätzliche Anmerkungen:
·         Lass die Arbeit von jemandem Fremden Korrekturlesen! (Lehramt-Studentinnen sind da meist eine gute Wahl. Nimm gleich zwei und koche ihnen derweil ein leckeres Abendessen!) 
Diese KorrekturleserInnen sollte sich nur auf die Sprache und Rechtschreibung konzentrieren – dafür kann es sogar sinnvoll sein, dass sie keine Ahnung von der Materie haben. 
Deine Arbeit ist hier nicht schlecht, aber man stolpert immer mal wieder über Wiederholungen wie „In diesem Abschnitt werden die unterschiedlichen Daten unterschieden, 
... Hierzu wird eine Unterscheidung zwischen...“ (s. 9). Auch sprichst Du beim DB-Teil zweimal plötzlich von „statischen“ (statt von „statistischen“ Daten“ – obwohl das sonst nie vorkommt), 
das könnte einfach auffallen.
Aber keine Panik: Die Bachelorarbeit wird nicht nach der Rechtschreibung bewertet.
·         Hol Dir auch fachliches Feedback von Kollegen, die sich (zumindest halbwegs)mit der Materie auskennen. Auch die sollen die Arbeit lesen, aber eben nicht auf Rechtschreibung,
 sondern auf die Inhalte achten und ggf. Fragen an Dich formulieren, wenn ihnen an einer Stelle etwas nicht klar wird. (Die Kollegen kommen gerne zu Dir, weil sie ebenfalls scharf aus das 
 Abendessen (und ggf. auf die PH-Studentinnen) sind.)
·         In einer solchen Arbeit (Programmieraufgabe) sollte es inhaltlich eine Unterscheidung zwischen Entwurf/Konzept/Planung und der Implementierung geben. 
Das hast Du für den DB-Bereich gemacht, bei der eigentlichen App verwischt das aber. 
Im Entwurfsteil sollten grundlegende Entscheidungen diskutiert und getroffen werden, ggf. (je nach Komplexität) bis hin zu einer detaillierten Planung (z.B. UML-Diagramme). 
Im Implementierungsteil sollten dann im Wesentlichen davon abweichende Aspekte behandelt werden, sowie Probleme/Schwierigkeiten, die beim Entwurf noch nicht absehbar waren. 
Ein Implementierungsteil ist in der Regel ziemlich kurz, Code gehört (außer sehr zentrale Aspekte) im Allgemeinen eher in den Anhang, wenn es viel ist auf einen Datenträger.
·         Die vielen Implementierungsdetails der vorliegenden Arbeit waren für mich durchaus interessant, im Allgemeinen sollten sie in einer 
wissenschaftlichen Arbeit deutlich knapper ausfallen. Lediglich herausragende Stellen oder bestimmte Probleme sollten im Detail präsentiert und besprochen werden, 
dann aber auch eher erläutern an einem Klassendiagramm. Ob eine bestimmte Methode dabei überschrieben wurde ist in der Regel daraus ersichtlich, 
meist ist diese Information für den Leser einer solchen Arbeit aber gar nicht relevant (zu sehr im Detail).
Gerade für Deine Model-Schicht sagt Abb. 6.9 mehr aus als die viele Prosa und die Codeschnipsel in den Abschnitten zuvor. Für das Verständnis wäre es also sinnvoll, diese vorzuziehen.
·         Grundsätzlich solltet Du am Ende der Arbeit auf die gesetzten Ziele eingehen und diese bewerten.
 Das hast Du (eher oberflächlich) auch getan, indem Du sie praktisch noch mal aufgezählt hast. 
 Grundsätzlich sollten Ziele überprüfbar (möglichst sogar messbar) [s.m.a.r.t.e Ziele: http://de.wikipedia.org/wiki/SMART_%28Projektmanagement%29] sein, so dass man eine qualifizierte Aussage über deren Erreichen oder Verfehlen treffen kann. Das ist in Deiner Zusammenfassung noch ziemlich schwammig.
·         Insgesamt gefällt mir Deine Sprache ganz gut, der Text ist insgesamt flüssig zu lesen, hat Spaß gemacht.
·         An einigen Stellen (insb. bei längeren Beschreibungen ) hätte ich mir noch ein unterstützendes Bild oder einen Screenshot gewünscht, das versteht mal oft schneller als eine Seite Prosa.
·         Die Einführung Deiner Zwischenschicht „Model“ und die generische Nutzung von UI-Elementen hat mir sehr gut gefallen.
 
Nun noch ein paar konkrete Anmerkungen:
·         Ich habe keinen Doktortitel! (Titelblatt) – aber Danke für die Lorbeeren. ;-)
·         Achte auf Konsistenz bei der Namensgebung, z.B. „trainingsGruppeId“ vs. „traingings_group_id“ (Abb. 3.1 und Abb. 3.2 – da gibt es sogar beide)
·         Beim Theorieteil, evtl. auch im Entwurfsteil wäre es schön von den Technologien/technischen Begriffen einen Bogen zu Deinem eigenen Projekt zu schlagen, z.B. bei der 
Erklärung von „Fragment“ oder „Activity“ die Sinnhaftigkeit oder sogar Notwendigkeit zum Verwenden einer generischen Schicht  
zu motivieren. So wie es jetzt ist, stehen diese Teile etwas für sich alleine (und die meisten werden später sogar noch mal erklärt).
·         Gerade bei GUIs bietet es sich an, Screenshots im Rahmen der Dokumentation zu verwenden, 
wenn ein Sachverhalt erstmals beschrieben wird. Z.B. hätte ich mir Abbildung 5.7 (S. 31) schon auf Seite 27 gewünscht.
·         Die Literaturreferenzen sind für das Praxismodul ausreichen und passend gesetzt, bei der Bachelorarbeit dürfen es aber durchaus noch ein paar mehr werden, 
auch die Darstellung der Technologien/Entwurfsentscheidungen (z.B. „dies entspricht dem Designpattern XY [GAMMA95]“ ) sind ggf. zu hinterlegen.
·         Reine Geschmackssache: Du hast Verweise teilweise per Referenz in die Literaturliste, teilweise als Fußnote gemacht. Dabei konnte ich keine eindeutige Strategie erkennen (Verweise auf Android-Developers gibt es z.B. in beiden). Entscheide Dich für eines (vorzugsweise die Literaturliste) und ziehe es durch.
·         Hast Du im Programmcode bewusst (fast) keine Kommentare oder sind die rausgefiltert?
Der Code im Anhang ist nicht vollständig. Ein paar Worte zur Erläuterung (Was ist da zu sehen? Warum, d.h. nach welchen Kriterien, wurde das so ausgewählt?) wären da hilfreich. 
Wenn es keinen konkreten Bezug zum Text (also Verweise auf Code-Stellen im Anhang gibt), reicht der Code auf dem Datenträger.
·         Für ein einzelnes Praxismodul ist der Gesamtumfang der Arbeit schon fast etwas zu groß. Halte Dich möglichst an die Richtlinien der DHBW. [Mich persönlich scheren die aber nicht besonders, wenn Du nicht zu labern anfängst… ;-)] Es geht aber darum zu üben, einen Sachverhalt in einem vorgegebenen Umfang zu präsentieren und sich ggf. auf das Wesentliche zu beschränken. 
Andersrum ausgedrückt: Du warst sehr fleißig!