Infos für Auftraggeber:innen

Änderungen

  • 2026-08-11 Initiale Version für 2026

  • 2026-08-24 Projekteinreichungen aktiv

  • 2026-09-19 Bewertungsinformationen in das Dokument integriert

  • 2026-09-23 Sprechstunde ergänzt

  • 2026-09-23 Dauer der Sprechstunde ergänzt

Alle Mitarbeiter:innen der TU Darmstadt können Softwareprojekte einreichen, die von Studierendenteams der Informatik (5. Semester) im Rahmen des Moduls Teamprojekt Softwareentwicklung (TPSE), ehem. Bachelor-Praktikum (BP), bearbeitet werden.

Kontakt Email
Sprechstunde Montag den 28.09 um 13:00

  • bis mindestens 13:30 Uhr, bei Bedarf auch länger

  • Zoom

  • Für abweichende Termine am Montag bitte vorher kurz per Mail Kontakt aufnehmen.

Projekteinreichungen

  • Online Formular

  • Einreichungen können jederzeit aktualisiert werden.

  • Falls das Tool Sie nicht als Mitarbeiter:in erkennt, melden Sie sich bitte per E-Mail.

  • Zur Anmeldung ist zunächst nur ein Projekttitel erforderlich.

Timeline

Was ist das TPSE?

Das Teamprojekt Softwareentwicklung (TPSE) ist ein 9 CP-Praktikum für Bachelorstudierende der Informatik im 5. Semester, das jedes Wintersemester angeboten wird. Gegenstand des TPSE ist das Erlernen und Erleben der systematischen Durchführung eines realen Softwareprojekts in einem Team von 4 bis 5 Personen. Jedes Team wird dabei zusätzlich von einem Studierenden höheren Semesters als Teambegleitung (TB) unterstützt.

Was bietet das TPSE?

Mitarbeiter:innen der TU Darmstadt können Projekte anbieten, die von den Studierenden gewählt und bearbeitet werden. Die entstehende Software soll einen Nutzen für Forschung, Lehre oder universitären Alltag haben. Die Nutzung der Software sollte angestrebt werden, die Eignung der Software kann aber nicht garantiert werden, da das TPSE eine Lehrveranstaltung ist.

Ihre Aufgaben

Ressourcen die sie bereitstellen müssen

Alle Studierenden sind typischerweise bereits mit Computer und üblicher Entwicklungsumgebung (IDE) ausgestattet.

Sollte Ihr Projekt Ressourcen erfordern, die darüber hinausgehen, müssen Sie diese dem Team zur Verfügung stellen. Das könnte sein:

Verwertung der Software

Bei dem TPSE handelt es sich um ein Pflichtpraktikum. Es gelten deswegen im Hinblick auf die wissenschaftliche bzw. kommerzielle Verwertung dieselben Regeln, wie sie auch im Falle von Praktika etc. gelten. Soll die erstellte Arbeit nach Abschluss in einer bestimmten Art und Weise wissenschaftlich bzw. kommerziell verwertet werden, so ist dies bei der Themenvorstellung zu erwähnen und im Rahmen des ersten Treffens noch einmal unmittelbar mit den Gruppen abzustimmen. Vonseiten der Veranstalter:innen gibt es keine Vorgaben. Den Veranstalter:innen muss jedoch ggf. Einsicht in den Code gewährt werden, wenn es zu Problemen im Rahmen der Notenfindung kommt.

Wie kann ich mir den Softwareentwicklungsprozess vorstellen?

Eine der größten Herausforderungen bei der Softwareentwicklung ist es, dass die Entwickler genau verstehen, was die Auftraggeber benötigen. Der hier gezeigte Cartoon von Alex Gorbatchev illustriert die Schwierigkeit, sowohl Anforderungen zu kommunizieren als auch herauszufinden, was sie überhaupt sind.

In der Softwareentwicklung hat sich das agile Vorgehensmodell bewährt, um die Entwicklung von unpassender Software zu vermeiden. In unserem Ansatz bedeutet das, dass sich das Entwicklerteam alle zwei Wochen mit den Auftraggebern trifft, um gemeinsam die Anforderungen zu erarbeiten und zu verfeinern. Ab dem zweiten bis dritten Treffen wird bereits laufende Software präsentiert. Diese frühen Versionen der Software haben zwar noch begrenzte Funktionen, helfen jedoch den Auftraggebern, ihre Anforderungen besser zu verstehen und klar zu kommunizieren.

Scheuen Sie sich deshalb nicht, Themen anzubieten, bei denen Ihnen noch nicht ganz klar ist, wie die Lösung aussehen könnte. Sie müssen nur eine gute Lösung von einer schlechten unterscheiden können, wenn Sie sie sehen.

Beachten Sie bitte auch, dass es notwendig sein kann, den Umfang des Projektes während des Semesters daran anzupassen, wie gut das Team vorankommt. Ihre Aufgabe ist es, zu priorisieren, an welchen Funktionalitäten (sogenannten „User Stories“) das Team als Nächstes arbeiten soll, während das Team Ihnen eine grobe Einschätzung bietet, wie viel Aufwand jedes Feature erfordert.

Geeignete Projekte

Wichtig: Es geht für die Studierenden um Softwareentwicklung, nicht etwa Forschungsprojekte, die Implementierung beinhalten. Das reine Training von KI Modellen bspw. ist kein Softwareentwicklungsprojekt.

Werbefolien

Die „Werbefolien“ sind ein PDF mit 3 bis 6 Slides, in denen das Projekt kurz umrissen wird, damit die Studierendenteams schnell einen Eindruck bekommen können, ob das Projekt für sie geeignet ist.

Die Folien werden den Teams online zur Verfügung gestellt. Sie werden die Folien NICHT präsentieren.

Bitte machen Sie sich keine unnötige Arbeit beim Gestalten der Folien. Es geht darum, einen Eindruck für die Projektinhalte zu vermitteln, nicht darum, die Teams zu beeindrucken.

Wie Sie das Projekt beschreiben, bleibt Ihnen überlassen. Wir empfehlen jedoch:

Beispielfolien

Anmerkung: Die Beispielfolien enthalten noch keine klar ausgewiesene Slide für die Rahmenanforderungen, da wir diese erst seit WS2024 explizit vorgeben.

Positive Punkte der Beispielfolien:

Rahmenanforderungen

Wenn Sie schon vorher wissen, dass bestimmte Rahmenanforderungen von den Teams erfüllt werden müssen, dann müssen Sie diese bereits auf den Werbeslides nennen. Darunter fällt z. B.:

Es ist möglich, dass Ihr Projekt keine solchen Rahmenanforderungen hat. In diesem Fall notieren Sie dies bitte einfach auf der letzten Slide.

Sie sollten diese Anforderungen auch nach der Gruppenzuteilung noch einmal direkt mit der Gruppe diskutieren.

Es ist auch möglich, dass sich Rahmenanforderungen erst nach der Gruppenzuteilung ergeben. In diesem Fall liegt es an Ihnen, mit der Gruppe gemeinsam eine Lösung zu finden, die für alle akzeptabel ist.

Fragen und Antworten

Hat mein Projekt einen geeigneten Umfang?

Es ist immer schwierig, den Umfang von Softwareprojekten einzuschätzen. Deshalb kann es typischerweise notwendig werden, den Projektumfang ad hoc anzupassen, je nachdem wie gut das Team vorankommt. Dies kann in beide Richtungen gehen. Wenn das Team nicht gut vorankommt, sollte trotzdem versucht werden, ein Teilproblem vollständig zu lösen, anstelle von halbfertiger Software, die keinen praktischen Nutzen hat. Für den Fall, dass ein Team gut vorankommt, ist es wünschenswert, dass das Projekt sinnvoll erweitert wird, um die Bearbeitungszeit zu füllen.

Der vorgesehene Arbeitsumfang für die Studierenden gliedert sich wie folgt:

Im TPSE ist ein iterativer Prozess vorgesehen, in dem in Zwei-Wochen-Abschnitten die nächsten Schritte priorisiert und Teilergebnisse besprochen werden, um sicherzustellen, dass die Entwicklung auch in die richtige Richtung geht.

Dafür ist es vorteilhaft, eine grobe Projektvision davon zu haben, was Sie gerne hätten. Denn dann kann das Team Vorschläge machen, wie sich das in kleinere Bestandteile zerlegen lässt, die Sie dann priorisieren können.

Kann im Rahmen des Projektes ein existierendes Projekt erweitert werden?

Selbstverständlich können auch bestehende Projekte erweitert werden. Berücksichtigen Sie jedoch, dass die bereits existierende Codebase einer Einarbeitung des Teams bedarf, die entsprechend mehr Zeit in Anspruch nimmt.

Entscheidend ist, dass sich klare „User Stories“ herausarbeiten lassen, deren Erfolg sich prüfen lässt.

Qualitätsmerkmale wie die Wartbarkeit des Codes sind „nicht-funktionale“ Anforderungen – diese sicherzustellen ist auch Teil des Projektes, kann aber nicht die einzige Aufgabe sein.

Wie gestalte ich mein Projekt attraktiv für Studierende, damit diese das Projekt auch wählen?

Zur Bewerbung Ihres Projekts fertigen Sie als AG einen kurzen Foliensatz an. Diese Folien werden den Studierenden zur Verfügung gestellt und können gerne auch noch Links auf weitere Informationen enthalten. Dabei erscheint Ihr Projekt umso attraktiver, je verständlicher, spezifischer und bildhafter Sie das Projekt beschreiben können. Eine geringere Komplexität und nicht zu großer Umfang helfen dabei auch. Auch hilft es, die Relevanz des Projekts zu verdeutlichen. Nennen Sie auch gerne die expliziten Vorteile, die die Studierenden von Ihrem Projekt haben.

Aufgrund der hohen Anzahl an Themen (wir rechnen mit ca. 100) ist außerdem die Wahl eines geeigneten und interessant klingenden Titels wichtig.

Als Tipp: Für viele Teams ist es attraktiv, wenn das Team die eingesetzten Technologien selber wählen kann, da dann bestehende Kenntnisse genutzt werden können.

Kann im Rahmen des Projektes geforscht werden?

Forschungsfragen fallen in dieser Form nicht in das TPSE, da sie zu wenig Softwareentwicklungsarbeit enthalten.

Was aber durchaus denkbar wäre, ist ein Auftrag, bei dem das Team eine Plattform für die Auswertung von Daten erstellt. Dies könnte z. B. beinhalten:

Was nicht vom Team durchgeführt werden sollte, sind Aufgaben wie:

Kurzum: Das Team soll Software entwickeln, die für Sie als AG am Ende des TPSE weiterhin nützlich ist (oder zumindest nützlich sein könnte), ohne dass das Team weitere Aufgaben übernimmt.

Was ist, wenn ich noch nicht genau weiß, was ich will?

Es ist normal, mit dem Team zu diskutieren und zu entscheiden, wie effektive Lösungen für Ihre Probleme aussehen könnten. Dazu gehört, abzuwägen, was für Sie wichtig ist und was das Team zügig entwickeln kann. Wenn absehbar ist, wer die User der zu entstehenden Software sein werden, lassen Sie das Team mit diesen sprechen, um die spezifischen Bedürfnisse zu erfassen und so eine zugeschnittene Lösung zu entwickeln.

Bedenken Sie: Damit Teams Ihren Projektvorschlag wählen, ist es sehr hilfreich, konkrete Beispiele zu liefern, was eine Softwarelösung können soll. Machen Sie aber auch klar, dass dies nur Beispiele sind und Anpassungen während des Entwicklungsprozesses möglich sein werden, je nach o. g. Feststellungen.

Welche Vorkenntnisse kann ich von dem Team erwarten?

Das Team besteht typischerweise aus Bachelor-Studierenden im 5. Semester. Das Grundstudium selbst lehrt Softwareentwicklung in Java, Python, sowie vereinzelt andere Programmiersprachen.

Es ist gut möglich, dass Teams sehr wenig Vorerfahrung mitbringen und sich zu Beginn des Projektes erst einarbeiten müssen.

Gleichzeitig ist das Selbststudium ein Skill, der von den Studierenden abverlangt werden kann. Und es gibt immer wieder Teams mit verschiedensten Hintergründen, die sich ergänzen können.

Falls Ihr Auftrag Vorwissen erfordert (oder sehr davon profitiert), raten wir deshalb, dies in der Projektbeschreibung anzumerken, damit Teams den Auftrag entsprechend wählen oder vermeiden können.

Können auch Unternehmen als Auftraggeber:innen teilnehmen?

Aus Gründen der Verantwortlichkeit bei der Benotung und des Datenschutzes müssen Auftraggeber:innen Angehörige der TU Darmstadt sein. Für Unternehmen steht das Software Engineering Project (SEP) zur Verfügung, ein ähnliches, jedoch umfangreicheres Projekt. Dort wird die Verantwortung durch das Lehrpersonal kostengünstig übernommen.

Benotung durch AGs

Die Benotung im Teamprojekt Softwareentwicklung ist schwierig in ein exaktes Schema zu fassen, da jedes Projekt und jedes Team unterschiedlich ist. Wichtig ist, dass der gesamte Prozess und nicht das Endergebnis bewertet wird. Auch wichtig ist, dass die Bewertung für das Team nicht überraschend ist, Probleme sollten vorher kommuniziert werden.

Wir bitten sie das Team auf einer Skala von 0 bis 100 zu bewerten. Dabei entspricht 49 Punkte oder weniger einem „5.0 nicht bestanden“.

Berücksichtigen Sie bei der Bewertung bitte folgende Punkte.

Wenn sie bei den meisten (sagen wir 9 von 11, etwa 80%) der obigen Punkte mit „Ja/Gut“ Antworten würden sind 100 Punkte als Bewertung angemessen.

Falls das Team regelmäßig an den Meetings teilgenommen hat, auch wenn nicht immer gut vorbereitet, und Anforderungen bearbeitet hat, sodass am Ende zumindest minimale nutzbare Software entstanden ist, sollte das Team nicht durchfallen (50+ Punkte).

Für Ergebnisse dazwischen überlassen wir die genaue Gewichtung der obigen Punkte ihnen. Gewichten sie ihre Bewertung danach, was sie dem Team als besonders wichtig kommuniziert haben. Ganz grob könnte jeder der 11 obigen Kriterien etwa 5 Punkte mehr in der Bewertung sein, ausgehend von 55 Punkten für die ausreichende Teilnahme am Projekt.

Typisches Beispiel für 100 Punkte wäre: Das Team hat bei jedem Treffen Fortschritt gezeigt. Anforderungen mit Akzeptanzkriterien entsprechen ihren wünschen. Es gibt zwar nicht erfüllte Anforderungen, aber die Grundfunktionalität der Software ist vorhanden, und das Team hat einen klaren Plan gehabt wie man den ursprünglichen Plan was umgesetzt wird an die Realität anpassen kann.

Typische Beispiele für Teams die durchfallen (weniger als 50 Punkte):

Berücksichtigen Sie bei der Bewertung auch gerne, wenn das Projekt besonders schwer oder einfach war, falls sie dies Beurteilen können (z.B. durch vorherige Erfahrungen mit ähnlichen Studierendenprojekten). Berücksichtigen Sie dabei aber bitte auch, dass es für die Studierenden oft viel schwieriger ist sich in unbekannte Projekte einzuarbeiten als Sie das erwarten würden. Wenn sie sich eine „Standard Webanwendung“ gewünscht haben, aber das Team keine Vorerfahrung mit Webanwendung hat, soll dies nicht übermäßig als Nachteil ausgelegt werden. Wohingegen natürlich schon erwartet werden kann, dass das Team die reichlich vorhandene Dokumentation zu solchen Anwendungen im Internet nutzt, und sich in das Thema einarbeitet.

FAQ für Auftraggeber:innen

TUCaN

Sie müssen keine Noten in TUCaN eintragen: Wir schicken am Ende des Semesters eine Abfrage für die Bepunktung.

Aufgabenverteilung: AGs, TBs, und Team

Ihre Aufgaben sind oben unter „Ihre Aufgaben“ zusammengefasst: regelmäßige Treffen (alle 2 Wochen), gemeinsames Erarbeiten von Anforderungen, Bereitstellen benötigter Ressourcen und die abschließende Bewertung. Die Teambegleitung begleitet das Team, ist Ansprechperson für Probleme und berichtet der Orga – Details im Handbuch für Teambegleitungen.

Als Auftraggeber:in entwickeln Sie nicht mit und sind auch nicht für die Prozessplanung verantwortlich – die Teams sollen lernen, eigenständig zu arbeiten. Vorschläge, Empfehlungen und Erklärungen sind gerne gesehen, Vorgaben aber eher nicht.

Die Qualitätssicherung übernimmt das Team: Vorgegeben sind Tests, Code Reviews und Pair Programming (siehe Qualitätssicherung). Weitere Maßnahmen sollten Sie mit dem Team diskutieren, wenn Sie es wünschen.

Lizenzen

Das ist mit dem Team abzustimmen (Thema beim ersten Treffen, siehe auch oben „Verwertung der Software“). Als Entscheidungshilfe: choosealicense.com.

Ganz allgemein gilt an der TU Darmstadt, dass Studierende die Rechte an ihrem eigenen Code behalten. Im Rahmen des Projekts gehen wir davon aus, dass Sie als Auftraggeber:in zusätzlich Nutzungsrechte an der Software erhalten. Für die Weiterentwicklung ergibt es aber Sinn, eine Softwarelizenz zu wählen.

Dokumentationssprache

Das Spezifikationsdokument und die Projektdokumentation sollen – falls nicht anders vom AG gewünscht – auf Englisch verfasst sein.

Nur TU Angehörige als Auftraggeber:innen

Aus Gründen der Verantwortlichkeit bei der Benotung und des Datenschutzes müssen Auftraggeber:innen Angehörige der TU Darmstadt sein.

Für Ausnahmen kontaktieren Sie uns bitte per E-Mail.