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.
Die nachfolgende Praxisprojekte biete ich momentan im Rahmen meines Labors oder in Zusammenarbeit mit Partnern an. Klicken Sie auf den Titel-Link für eine detailliertere Beschreibung, oder suchen Sie selbst weiter 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.
| Kriterium | Gewicht | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte |
|---|---|---|---|---|---|
| Qualität der Ergebnisse | 4,75 | Die Inhalte des Projekts sind nicht wirklich akzeptabel umgesetzt. Das Projektziel wurde weitestgehend verfehlt. | 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 angemessen umgesetzt. Es gibt kleinere Mängeln, die aber das Projektziel nicht gefährden. | Die Inhalte des Projekts sind sehr gut umgesetzt, ohne erkennbare Schwachpunkte. |
| Umfang und Engagement | 3,75 | Das Projekt strahlt ein kaum akzeptables Maß an Engagement und Effizienz aus. Der Umfang des Projekts ist weit unterdurchschnittlich. | Im Projekt gibt es wenige Hinweise auf besonderes Engagement und/oder Effizienz. Der Umfang des Projekts lässt Raum für Verbesserung. | Das Projekt spiegelt ein angemesses Maß an Engagement und Effizienz wieder. Der Umfang des Projekts erfüllt die Erwartungen. | Der Studierende hat sehr engagiert und effizient gearbeitet. Der Umfang der Arbeiten übertrifft die Erwartungen an ein solches Projekt deutlich. |
| Impact der Ergebnisse | 1,00 | Das Projekt hat leider so gut wie keine Praxisrelevanz. | Die Projektergebnisse haben eher geringen Einfluß auf den Kontext, in dem es durchgeführt wird (Firma, Forschungsvorhaben etc.). Ergebnisse werden möglicherweise punktuell weiter verwendet. | Die Projektergebnisse haben Einfluß auf den Kontext, in dem es durchgeführt wird (Firma, Forschungsvorhaben etc.). Ein Teil der Ergebnisse wird möglicherweise weiter verwendet. | Die Projektergebnisse haben einen signifikanten Einfluß auf den Kontext, in dem es durchgeführt wird (Firma, Forschungsvorhaben etc.). Die Ergebnisse des Projekts werden in vollem Umfang weiter verwendet. |
| Fachkenntnis | 1,00 | Bei dem/der Studierenden ist kaum Bereitschaft oder Raum dafür zu erkennen, sich in spezielle Gebiete des Projekts einzuarbeiten. | Die/der Studierende zeigt Bereitschaft, sich in spezielle Gebiete des Projekts einzuarbeiten. | Der/die Studierende zeigt in der Projektbearbeitung ein gutes Maß an Sachkenntnis. | Der/die Studierende zeigt in der Projektbearbeitung echtes Expertenwissen, verbunden mit einer Haltung des dauerhaften Lernens. |
Insgesamt sind max. 36 Punkte zu erreichen. Eine 1,0 gibt es ab 33 Punkten, eine 4,0 ab 12 Punkten. Notenstufen dazwischen werden entsprechend interpoliert. 0 Punkte bei ‘Qualität der Ergebnisse’ oder bei ‘Umfang und Engagement’ führen automatisch zu einer 5,0.
Damit Sie sich etwas genauer vorstellen können, was ich unter den einzelnen Notenstufen verstehe, habe ich hier meine Interpretation aufgeschrieben. Nachdem ich ein Projekt nach dem obigen Schema bewertet habe, prüfe ich meinen Eindruck noch einmal gegen dieses “Raster”. Bindend ist also die obige Bewertung, aber die hier genannte Interpretation hilft bei der Einordnung.
| Note | Interpretation |
|---|---|
| 1,0 | Dieses Projekt ist außergewöhnlich sorgfältig und umfassend durchgeführt und dokumentiert. Die Qualität der Arbeit, die Systematik des Vorgehens und die Dokumentation genügen uneingeschränkt professionellen Standards. Wenn man ein solches Projekt in einem professionellen Kontext vorfindet, ist man sehr angetan und möchte die/den Autor/in gern kennenlernen - idealerweise, um sie oder ihn ins eigene Team zu holen. |
| 1,3 | Das Projekt ist sehr gut gemacht. Als Kunde wäre man sehr zufrieden mit dieser Umsetzung. An der einen oder anderen Stelle (bei Umsetzung, Systematik oder Dokumentation) gibt es ein bisschen Luft nach oben, aber in keiner Weise so, dass es das Projektziel / die Codequalität / die Benutzbarkeit etc. einschränkt. |
| 1,7 | Im professionellen Kontext wäre so ein Projekt “solide”. Das Projekt hat im Wesentlichen seine Ziele erreicht, aber einige Schwächen sind vorhanden. Entweder fehlt Sorgfalt, oder Umfang und Tiefe sind eher durchschnittlich, oder das Vorgehen hat Mängel, oder die Dokumentation fällt gegen die Projektqualität stark ab. Eine dieser Schwächen ist deutlich wahrnehmbar, oder zwei davon in jeweils leichter Form. Im professionellen Kontext kann man damit aber gut arbeiten und nimmt die Schwäche(n) in Kauf, weil der Rest sehr gut ist. |
| 2,0 | Das Projekt erfüllt in ordentlicher Weise die Erwartungen - d.h. es brilliert eigentlich in keiner Weise, hat weder ganz gravierende Schwächen noch große Stärken. Vielleicht ist es eine grundsätzlich solide, aber etwas uninspirierte Routinearbeit - vielleicht ist es auch ein sehr guter Ansatz, der aber nicht zu Ende gedacht oder umgesetzt wurde. Im professionellen Kontext wäre man als Kunde mit dem Ergebnis grundsätzlich zufrieden und im Detail leicht genervt. Vermutlich würde man die störenden Punkte sammeln, um über ein Refactoring oder zweite Projektphase nachzudenken. |
| 2,3 | Bei der Beurteilung eines solchen Projekts fallen die Schwächen mehr als die Erfolge ins Auge. Das Projekt setzt die Ziele immer noch angemessen um, aber man ist als Kunde - und wahrscheinlich auch als Umsetzer/in - nicht so richtig zufrieden damit. Immerhin wurde eine lange Zeit daran gearbeitet. In der Retrospektive würden Kunde und Umsetzer ggfs. versuchen, den Kommunikationsprozess zu optimieren. |
| 2,7 | Bei diesem Projekt fangen die Schwächen an, deutlich das Bild zu prägen. Das Projektziel wird immer noch erfüllt, aber mehrere Aspekte - Umfang, Architektur, Codequalität, Robustheit, Benutzbarkeit etc. - liegen deutlich im Argen. Im professionellen Kontext wäre dies ein klarer Refactoring-Kandidat. |
| 3,0 | Bei so einem Projekt wurde entweder dem Kunden nicht ordentlich zugehört, oder nicht (genug) über Technologie und Architektur nachgedacht, oder viel zu früh aufgehört (oder alles zusammen). Ein Projekt, das alle Beteiligten recht unzufrieden zurücklässt. Es ist noch gut genug, um das Projektziel einigermaßen zu erfüllen, aber man würde als Kunde diesem Dienstleister vermutlich keine zweite Chance geben. Hier hat jemand gerade genug gemacht, um so einigermaßen durch die Tür zu kommen, oder es gab eine schwere Krise, oder ein großes Missverständnis am Anfang und danach zu wenig Kommunikation. |
| 4,0 | Ein echtes “Piece of Hackwork”, bei dem im professionellen Kontext der Kunde mindestens einmal drüber schlafen müsste, ob sie/er dieses Projekt akzeptiert. Am Ende akzeptiert man es doch, weil es zu wenig Handhabe gibt, die Annahme (und Bezahlung …) zu verweigern. Aber man plant nicht mit dem entstandenen Ergebnis und schreibt es als Fehlschlag ab. |
| 5,0 | Das Projekt wird gar nicht erst beendet und abgegeben, ist indiskutabel klein, komplett unprofessionell umgesetzt, oder hat nichts mit dem Projektziel zu tun (oder mehrere dieser Aspekte auf einmal). Kurz, es erfüllt in keiner Weise die Ansprüche an eine professionelle Dienstleistung. Als Kunde verweigert man die Annahme. |
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?
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.