Kontakt
Mail: stefan.bente@th-koeln.de
Tel.: +49 2261 8196 6367
Skype: stefan.bente
Discord Server
Adresse:
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

Betreuung von Praxisprojekten im Bachelor

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.

Was für ein Thema?

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.

Exposé

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.

2-wöchentliches Statusgespräch

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ß).

Bewertung eines Praxisprojekts

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)

Dokumentation eines Praxisprojekts

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.

Inhalt eines PP

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.

Gewünschter Umfang

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:

  • Recherche eines komplexen Themenfeldes, um Forschungsfrage und –Design der BA sauber definieren zu können,
  • ein Proof-of-Concept für einen Problemlösungsansatz, der in der BA dann vertieft betrachtet und ausgearbeitet wird,
  • Spezifikation und Implementation eines Basisfunktionalität / Plattform / Library / …, die für die zeitlich begrenzte Arbeit an der BA gebraucht wird,
  • etc.

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).

Dokumentation

Wie sollte jetzt eine gute PP-Dokumentation aussehen?

  • Sie sollte eine Arbeit von 450h angemessen dokumentieren, d.h. so viel inhaltliche Tiefe aufweisen, dass sich die Menge der investierten Arbeit wiederspiegelt.
  • Das ist nur schwer in Seitenzahlen zu übersetzen. Ich kann mir kaum vorstellen, dass man obige Forderung in nur 10 Seiten erreicht. Andererseits können 25 Seiten mit gut geschriebenem, kompakten Text einen hervorragenden Überblick geben, während 80 Seiten Blähtext überhaupt nichts aussagen. Lassen Sie also bitte Ihre eigene Intuition entscheiden, oder – fragen Sie mich einfach im konkreten Fall.
  • Die PP-Dokumentation folgt den denselben strengen Anforderungen an wissenschaftliches Arbeiten – sinnvolle Auswahl der Quellen, keine Wikipedia-Referenzen, Zitate kennzeichnen, etc.
  • Die Gliederung einer PP-Dokumentation ist oft allerdings weniger „geschlossen“ als die einer BA. Sie kann durchaus einen etwas episodischen Charakter haben. Schließlich geht es darum, die geleistete Arbeit zu dokumentieren. Dazu gehören auch auch Teilergebnisse, die dann nicht mehr weiterverfolgt wurden.

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.

Plagiate

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.