Auf dieser Seite finden Sie Informationen für die Betreuung von Praxisprojekten im Bachelor (Informatik BA, Code & Context BA, Wirtschaftinformatik BA oder Medieninformatik BA) durch mich oder Mitarbeiter:innen meines Labors.
Meine aktuellen Angebote für Praxisprojekte finden Sie auf der Oberseite dieser Seite oder direkt in der Projektbörse Prox. Wie bei Abschlussarbeiten können Sie aber jederzeit auch selbst Vorschläge für ein Thema machen. Das Thema ist üblicherweise im Kontext einer Firma angesiedelt, für die Sie tätig sind, oder zu der Sie Kontakt haben. Es kann aber auch ein anderer Kontext sein – ein eigenes Startup, eine sonstige eigene Initiative (die vielleicht einmal in ein Open-Source-Projekt mündet), oder ein formal definiertes oder informelles Forschungsvorhaben, in dessen Rahmen Sie dann auch Ihre Bachelorarbeit schreiben können. Das Thema sollte nahe an meinen eigenen fachlichen Themen liegen, damit eine Betreuung durch mich sinnvoll ist.
Vor der Betreuung müssen wir uns auf ein Exposé für Ihr Praxisprojekt einigen, um Projektziel, Kontext und Zeitplan zu klären. Füllen Sie also bitte folgendes Praxisprojekt-Exposé-Template aus und stimmen es mit mir ab. Tipp: Es ergibt Sinn, ein Draft des Exposés zum ersten Besprechungstermin mitzubringen - auch wenn Sie erstmal nur ein paar Stichworte zusammen haben.
Für alle Abschlussarbeiten vereinbare ich mit den Studierenden ein 2-wöchentliches Statusgespräch. Dies gilt auch für die vorbereitenden Praxisprojekte für die Bachelorarbeit. Diese Termine sind zweiwöchentlich immer zur gleichen Uhrzeit am gleichen Tag, immer Mittwochs vormittags zwischen 8:00 und 11:00. Von diesem Terminslot kann ich leider nicht abweichen (sonst fliegt mir mein Kalender um die Ohren, und der Verwaltungsaufwand wird zu groß).
Praxisprojekte in Bachelorstudiengängen (Informatik oder andere) bewerte ich gemäß des nachfolgenden Schemas.
| Bereich | Gewicht | Kriterium | Note „1-2“ | Note „2–3“ | Note „3-4“ | Note „5“ |
|---|---|---|---|---|---|---|
| Projektergebnis | 40% | Qualität der Ergebnisse | Die Inhalte des Projekts sind sehr gut umgesetzt, ohne erkennbare Schwachpunkte. | Die Inhalte des Projekts sind angemessen umgesetzt. Es gibt kleinere Mängeln, die aber das Projektziel nicht gefährden. | Die Inhalte des Projekts sind noch akzeptabel umgesetzt. Es bestehen größere Mängel, die das Projektziel gefährden können. | Die Inhalte des Projekts sind nicht akzeptabel umgesetzt. Das Projektziel wurde verfehlt. |
| 30% | Umfang und Effizienz | Der Studierende hat sehr engagiert und effizient gearbeitet. Umfang der Arbeiten übertrifft die Erwartungen an ein solches Projekt. | Die Projektdokumentation spiegelt angemessenes Engagement und Effizienz wieder. Umfang des Projekts erfüllt die Erwartungen. | Die Projektdokumentation gibt wenig Hinweise auf Engagement und Effizienz im Projekt wieder. Umfang des Projekts lässt Raum für Verbesserung. | Die Projektdokumentation strahlt ein inakzeptables Maß an Engagement und Effizienz aus. Der Umfang des Projekts ist unangemessen. | |
| Dokumentation | 20% | Qualität von Bericht und Begründung | Die einzelnen Aspekte des Projekts sind konsistent, nachvollziehbar, formal korrekt und verständlich beschrieben. Es gibt in jedem Fall sinnvolle Begründungen für Projekt-Entscheidungen. | Die einzelnen Aspekte der des Projekts sind weitgehend konsistent, nachvollziehbar, formal korrekt und verständlich beschrieben. Es gibt in den meisten Fällen sinnvolle Begründungen für Projekt-Entscheidungen. | Die einzelnen Aspekte des Projekts sind in noch akzeptabler Weise konsistent, nachvollziehbar, formal korrekt und verständlich beschrieben. Es gibt in einigen Fällen sinnvolle Begründungen für Projekt-Entscheidungen. | Die Beschreibung ist nicht nachvollziehbar, inkonsistent oder weist formal erhebliche Mängel auf. |
| 10% | Formale Qualität | Projektdokumentation ist formal hochwertig und sorgfältig erstellt (Aufbau, Zitierweise, Formulierung, Rechtschreibung, Layout) und liest sich “aus einem Guss”. | Projektdokumentation ist formal angemessen erstellt (Aufbau, Zitierweise, Formulierung, Rechtschreibung, Layout), mit einzelnen Stilbrüchen und Inkonsistenzen. | Formale Qualität der Projektdokumentation ist noch akzeptabel, mit vielfachen Stilbrüchen und Inkonsistenzen, aber mit noch erkennbarem “roten Faden”. | Projektdokumentation ist formal unzureichend (Aufbau, Zitierweise, Formulierung, Rechtschreibung, Layout) |
Häufig bekomme ich die Frage, wie der Bericht zu einem (von mir betreuten) Praxisprojekt (PP) im AI-, COCO-, MI- oder WI-Bachelor aussehen sollte. Deshalb dazu ein paar Gedanken und Hilfestellungen. Disclaimer: Der nachfolgende Text gibt lediglich meine persönliche Meinung wieder und stellt keine rechtsverbindliche Grundlage einer Bewertung dar.
Das Modulhandbuch Informatik Bachelor (Stand: 31.08.2013) sagt zum Praxisprojekt: „Die Studierenden sollen lernen, Methoden und Techniken, die sie im Studium erlernt haben, in einem realitätsnahen Projekt weitgehend selbstständig anzuwenden“. Inhalt ist die „Anwendung von Modulinhalten des ersten bis fünften Semesters anhand von realen Anforderungen in einem praxisrelevanten Kontext“ (Hervorhebungen alle von mir).
Die Forderung der Realitätsnähe und Praxisrelevanz bedeuten, dass das PP die Gelegenheit eröffnet, sich ein komplexes Themenfeld systematisch zu erschließen. Das gilt insbesondere, wenn es die Vorbereitung auf eine thematisch darauf aufbauende Bachelorarbeit (BA) darstellt. Ein PP beginnt man also selten mit einer ganz klar definierten Themenstellung. Vielmehr arbeitet man oft explorativ („mal nach links, mal nach rechts schauend“) und sucht nach Übersicht sowie nach den Aspekten, die für die BA relevant sein können.
Die BA hat eine klar dokumentierte und kontrollierte Dauer; hier ist eine fokussierte Themenstellung essentiell. Das PP sorgt (im Idealfall) dafür, dass diese fokussierte Themenstellung entstehen kann. Inhalt eines PP kann daher beispielsweise sein:
Beim PP zählt weniger die Dauer, sondern die die Menge an investierter Arbeit, die den 15 CP (= 450 Arbeitsstunden, = ca. 2-3 Monate Vollzeit-Arbeit) entspricht (Wert gilt für das AI-/WI-/MI-PP, bei COCO sind es 10 CP).
Wie sollte jetzt eine gute PP-Dokumentation aussehen?
Die PP-Dokumentation kann und sollte in den Formaten gemacht werden, die für das Zielpublikum passt. Wenn es also eine Entwickler-Dokumentation ist, dann kann auch ein Confluence, Markdown oder AsciiDoc (als Beispiele) sinnvoll sein. Das sollten Sie mit mir abstimmen.
Noch eine (für mich) sehr wichtige Anforderung zum Schluss: Der PP-Bericht ist ein eigenständiges Dokument. Sie können (und sollten!) es in der BA als Quelle referenzieren. Ein wortwörtliches Kopieren von Textteilen aus dem PP-Bericht in die BA ist ein (Selbst-)Plagiat, und gehört damit zu den schlimmeren Sünden des Wisssenschaftsbetriebs.