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.

Projektergebnis 47,5% Qualität der Ergebnisse Die Inhalte des Projekts sind sehr gut umgesetzt, ohne größere Schwachpunkte. Die Inhalte des Projekts sind angemessen umgesetzt. Es gibt Mängel, 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.
  37,5% 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 15% Qualität von Bericht und Begründung Projektdokumentation ist formal hochwertig (Aufbau, Zitate, Formulierung, Rechtschreibung, Layout), passt im Format zum Projekt und liest sich “aus einem Guss”. 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. Projektdokumentation hat einzelne Stilbrüche und Inkonsistenzen. Die einzelnen Aspekte des Projekts sind aber weitgehend konsistent, nachvollziehbar, formal korrekt und verständlich beschrieben. Es gibt in den meisten Fällen sinnvolle Begründungen für Projekt-Entscheidungen. Qualität der Projektdokumentation ist gerade noch akzeptabel, mit vielfachen Stilbrüchen und Inkonsistenzen, aber mit noch erkennbarem “roten Faden”. Die einzelnen Aspekte des Projekts sind in noch akzeptabler Weise konsistent, nachvollziehbar, formal korrekt und verständlich beschrieben. Projektdokumentation fehlt oder ist unzureichend (nicht nachvollziehbar, inkonsistent oder hat erhebliche formale Mängel).

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?

  • Das Format sollte zum Projekt passen. Ein Open-Source-Projekt beispielsweise wird eher in einem Wiki dokumentiert, ein Forschungsprojekt eher in einem wissenschaftlichen Paper, ein Software-Projekt eher in einem technischen Bericht, etc.
  • Einen wichtigen Einfluss hat der Unternehmenskontext. Wird das PP in einem Unternehmen durchgeführt, so ist es sinnvoll, die Dokumentation an die dort üblichen Standards anzupassen. Das kann beispielsweise bedeuten, dass die Dokumentation in englischer Sprache verfasst wird, oder dass sie in einem bestimmten Format (z.B. als technischer Bericht) vorliegen muss.
  • Die Zielgruppe(n) richten sich nach dem Kontext. Mindestens sollte eine Entwickler-Dokumentation verfasst werden, mittels derer andere Entwickler das Projekt weiterführen können. In einem Forschungsprojekt ist es sinnvoll, die Dokumentation so zu verfassen, dass sie auch für andere Forscher verständlich ist. Unter Umständen ist auch eine Endnutzer-Dokumentation sinnvoll.
  • Eine gute Entwickler-Dokumentation enthält mindestens die folgenden Aspekte:
    • Mission & Vision (kurz) - worum gehts.
    • Getting started - Installation und loslegen.
    • Tutorial - kleines Beispiel, das eine möglichst kompletten Durchstich darstellt. Am besten sogar als Example Code.
    • Falls komplex: Architektur-Schaubild
    • Link zur API-Dokumentation, if applicable. Die aber am besten generiert, also z.B. OpenAPI.
    • FAQ mit üblichen Fragen
    • Hinweise zum Melden von Fehlern oder für Contributors
  • Die Dokumentation sollte eine Arbeit von 450h angemessen dokumentieren, d.h. so viel inhaltliche Tiefe aufweisen, dass sich die Menge der investierten Arbeit wiederspiegelt.

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.