Praktikum FAQ

Was sind SWE-Projekte?

Das Software-Projekt im Rahmen der Vorlesung 'Software Engineering' soll alle Studierenden in die Lage versetzen, ein überschaubares SW-Projekt in all seinen Phasen selbständig durchzuführen. Dabei ist die Gruppengröße auf maximal 5-6 Teilnehmer begrenzt. Jede Gruppe wird von einem Dozenten oder idealerweise einem realen Auftraggeber aus einer Firma oder einem Institut betreut.

Ziel der Projekte ist das systematische Anwenden von Vorgehensweisen des Software Engineering, die vom Erfassen der Anforderungen bis zum systematischen Testen der Software und Dokumentation des gesamten Arbeitsprozesses reichen.

Ist es nicht ungerecht, wenn nur ein Viertel aller Ausbildungsbetriebe ein Projekt durchführen kann?

Erfahrungsgemäß haben nicht alle Ausbildungsfirmen und RWTH-Institute geeignetet Themenstellungen. Falls es tatsächlich mehr Themen als Gruppen geben sollte, wird versucht den Firmen den Vortritt zu lassen, die bisher kein Projekt durchgeführt haben. Außerdem ist die Betreuung durch die Ausbildungsbetriebe nur EINE Option - die Studenten können bei Bedarf auch eigene Themenstellungen vorschlagen, und es gibt auch eine Reihe externer Firmen (ohne eigene MATSE-Ausbildung), die großes Interesse an einer Projektbetreuung haben.

Muss die Arbeit an den SWE-Projekten nicht in der Freizeit stattfinden?

Nein, die Zeit für die Projektarbeit ist Teil der 10 ECTS-Veranstaltung "Software Engineering". Die Arbeit an den Projekten ist daher genauso zu werten wie die Zeit in den Vorlesungen oder Übungen!

In welchem Zeitraum werden die Projekte bearbeitet?

Die Arbeit an den Projekten beginnt Anfang/Mitte Dezember, und endet Ende Februar. Im Anschluss daran findet Ende Februar/Anfang März eine SWE-Projektmesse statt, bei der die Studierenden ihre Ergebnisse der Öffentlichkeit präsentieren.

Werden die Projekte bewertet oder sind sie relevant für eine Klausurzulassung?

Die Ergebnisse der Projekte fließen nicht in die Endnote des Fachs Software-Engineering ein, sind also unbenotet. Allerdings ist die erfolgreiche Arbeit an diesen Projekten Voraussetzung für die Klausurzulassung. Falls sich z.B. einzelne Teammitglieder regelmäßig der Projektarbeit entziehen oder die Projektarbeit behindern, kann das zum Ausschluss von der Klausur führen. Dies kann auch auf ganze Teams zutreffen, wenn im Bearbeitungszeitraum weder ein Endprodukt noch ein nachvollziehbarer Arbeitsprozess zu erkennen ist.

Wie viele Personen sollten in einem Team zusammen arbeiten?

Die Teams sollen auf jeden Fall mindestens 4 Teilnehmer haben, damit ein Arbeiten im Team realitätsnah abgebildet wird. Die maximale Gruppengröße sollte 5-6 Teilnehmer nicht überschreiten, damit die Abstimmung und Koordination in den Teams nicht zu aufwändig wird. In Ausnahmefällen können die Gruppen auch größer sein.

Welche Azubis/Studenten können in einem Team arbeiten?

Falls eine Firma/ein Institut genügend eigene Auszubildende beschäftigt, bietet es sich natürlich an, mit diesen Personen ein Team zu bilden. Da das auf die meisten Ausbildungsbetriebe aber nicht zutrifft, wird es auch immer Teams geben, die aus Auszubildenden mehrerer Betriebe bestehen.

Wann und wo wird die Projektarbeit durchgeführt?

Ab Anfang Dezember stehen die Zeiten für die Vorlesung für die Projektarbeit zur Verfügung (die Vorlesungen werden bis zu diesem Zeitpunkt gedoppelt). Zusätzlich werden nach Rücksprache mit der Ausbildungsabteilung weitere Arbeitszeiten festgelegt. Falls einzelne Teams sich nicht an diesen vereinbarten Zeiten treffen können, sondern diese Zeit für ihre reguläre Arbeit im Ausbildungsbetrieb nutzen, sollte es auch möglich sein, die Projekt-Arbeitsphasen bei Bedarf auf einen anderen Tag zu verlegen.

Aufgrund der angespannten Raumsituation am Rechenzentrum der RWTH können nicht alle Teams die Projektarbeit dort durchführen. Falls daher ein anderer (frei zu wählender) Arbeitsort erforderlich ist, muss jedes Team allerdings dem Dozenten per Email bekanntgeben, wo die Projektarbeit stattfindet, und wie das Team zu diesen Zeiten erreichbar ist (Telefonnummer). Diese Regelung gilt bis zum Ende der Vorlesungszeit, also i.d.R. bis Ende Januar. Wenn ein Team diese Information nicht liefern wird davon ausgegangen, dass sich das Team im Hörsaal des RZ befindet. Die Dozenten werden stichprobenartig die Arbeitsphasen der Teams überprüfen.

Welche Themen werden bearbeitet und wer kann sie vorschlagen?

Idealerweise werden die Themen für die Projekte von Ausbildungsbetrieben oder Instituten gestellt. Aber auch andere, nichtausbildende Firmen, Studenten älterer Semester oder auch die Studenten im 3. Semester können Themenvorschläge einreichen. Ein Themenvorschlag muss dem Dozenten per Email bis Ende November zugeschickt werden, und sollte auf 1-2 Seiten die grobe Projektidee verständlich darstellen. Ein entsprechendes Formblatt findet sich auf der Hompage der Veranstaltung.
Dabei sollte es sich im Falle von 'echten' Firmenprojekten natürlich nicht um kritische Zielprodukte handeln, da ein erfolgreiches Fertigstellen durch die Kürze der Zeit nicht immer garantiert werden kann. Durch 'reale' Aufträge werden die Teilnehmer des Kurses allerdings noch realistischer in eine Entwicklungssituation eingebunden, die ihr späteres Berufsbild gut abbildet.

Liste der Projekte im WS 2010/11

Liste der Projekte im WS 2011/12

Liste der Projekte im WS 2012/13

Welche Programmiersprachen und Technologien können eingesetzt werden?

Die Projekte sollten in der Regel in Java zu implementieren sein, da diese Sprache in den ersten 2 Semester erlernt wurde. In Ausnahmen sind auch andere (objektorientierte) Programmiersprachen möglich, wie z.B. C++ oder C#. Die Projekte können dabei auch zusätzliche Programm-Bibliotheken, Frameworks, GUI-Design etc. beinhalten, da dadurch die auch im späteren Berufsleben wichtige selbständige Einarbeitung in neue Themen unterstützt wird. Allerdings sollten sich die eingesetzten Technologien nicht zu komplex und vielfältig gestalten, da ansonsten wiederum durch die Kürze der Bearbeitungszeit ein Projekterfolg verhindert würde.

Wo werden die Dateien eines Projektes gespeichert?

Jedes Team erhält ein Verzeichnis auf dem SVN-Server der RWTH Aachen (https://svn.rwth-aachen.de/usvn/login/), wo alle Dateien, Besprechungsprotokolle etc. abzulegen sind. Nur die Teammitglieder und ggf. der Betreuer/die Betreuerin des Teams haben Zugriff auf diese Daten. Nach Rücksprache mit dem Dozenten können auch andere Lösungen gefunden werden (z.B. falls firmeninterne SW eingesetzt wird, die der Geheimhaltung unterliegt). Für die Betreuer und den Dozenten muß es aber auf jeden Fall eine Möglichkeit geben, die Arbeit am Quelltext nachvollziehen zu können und Protokolle der Besprechungen zu lesen.

Wem gehört die entwickelte Software?

Die Nutzungs- und Verwertungsrechte der entwickelten Software liegen bei der Firma, die das Thema gestellt hat und das entsprechende Team betreut. Falls eine Firma eine zusätzliche Absicherung benötigt, kann von allen 'fremden' Teammitgliedern (die nicht in der betreuenden Einrichtung arbeiten) eine Abtretungserklärung ausgefüllt und unterschrieben werden. Das Formular findet sich auf der Homepage der Veranstaltung.

Wer betreut die Projektteams und welche Rolle hat der Betreuer?

Jedem Team ist ein Projektbetreuer zugeordnet. Typischerweise ist das eine Person aus dem themenstellenden Betrieb/Institut, ein Student höheren Semesters oder eine andere externe Person. Die Hauptaufgabe des Betreuers ist die 'Auftraggeberrolle', d.h. der Betreuer selber sollte ein klares Bild von der zu entwickelnden Software besitzen. Zusätzlich ist es von Vorteil, wenn der Betreuer typische Arbeitsprozesse der Softwareentwicklung kennt, und sich ggf. auch mit den im Projekt eingesetzten Technologien auskennt, um das Team bei Bedarf zu unterstützen.
Der Betreuer hat daher auch eine Beratungs- und Coachingfunktion für die Projektgruppen. Falls es Probleme bei der Projektdurchführung geben sollte (z.B. wenn ein Team selten oder gar nicht den Kontakt zum Betreuer sucht, oder wenn auf der anderen Seite Betreuer selten oder gar nicht zur Verfügung stehen) können alle Beteiligten sich immer vertrauensvoll an den Dozenten wenden.

Welcher Arbeitsumfang ist bei der Betreuung zu erwarten?
Wie oft treffen sich die Projektgruppen mit ihren Betreuern?

Die Betreuer sollten sich (zumindest in der frühen Phase des Projektes) einmal pro Woche mit dem Team treffen, um den Projektfortschritt und ggf. Probleme und Risiken zu besprechen. Die Treffen müssen schriftlich vom Team dokumentiert werden (ein Beispiel-Template dazu gibt es auf der Homepage der Veranstaltung).

Der zeitliche Umfang dieser Treffen sollte möglichst nicht eine Stunde überschreiten (Konzentration auf die wesentlichen Punkte ohne zu weitschweifige Diskussionen). Eventuelle Fragen der Teams an den Betreuer sollten nach Möglichkeit vorher per Email zusammen mit der Tagesordnung verschickt werden.
Falls die Zeit des Betreuers knapp bemessen ist, kann er/sie z.B. auch eine feste Anzahl von 'Betreuungsgutscheinen' an das Team abgeben, die dann nacheinander eingelöst werden.
Studenten älterer Semester erhalten für die Betreuung 2 ECTS (Tutorentätigkeit).

Muss der Betreuer ein Lastenheft erstellen?

Falls möglich sollte der Betreuer vor Projektbeginn ein Lastenheft erstellen, das möglichst genau (soweit bekannt) die funktionalen und nichtfunktionalen Anforderungen an die SW festhält. Dadurch wird der Projektstart vereinfacht und das Team kann schneller produktiv arbeiten. Alternativ kann so ein Lastenheft auch schrittweise zusammen mit dem Team entwickelt werden, was natürlich auf Kosten der Implementierungs- und Testzeit geht.

Gibt es Treffen aller Betreuer?

Ein gemeinsames Treffen aller Betreuer während der Projektlaufzeit (zusammen mit den Dozenten der Veranstaltung) ist zur Zeit nicht geplant, kann aber bei Bedarf eingerichtet werden.

Welche Arbeitsprodukte werden von den Teams abgegeben?

Die Teams liefern am Ende des Projektes den Quelltext und die Besprechungsprotokolle auf dem SVN-Server ab. Als weitere Pflichtdokumentation ist ein DIN-A0-Poster zu erstellen, das auf einer Formatvorlage basieren muss (siehe Vorlagen auf der Homepage). Das Poster sollte neben der Aufgabenstellung und der Darstellung des Endproduktes (Screenshots etc.) auf jeden Fall auch das Design der SW in einer ansprechenden Form darstellen. Dazu können z.B. unterschiedliche UML-Diagramme eingesetzt werden.
Die Erstellung und Bezahlung der Poster übernimmt das Rechenzentrum der RWTH. Bevor ein Poster in Druck geht, muss es vorher elektronisch an die Dozenten gesendet werden (z.B. als PDF-Datei), die daraufhin grünes Licht für den A0-Druck geben. Da die Erstellung der Poster kann ein paar Tage dauern kann, sollten die Vorlagen spätestens eine Woche vor Projektende bei den Dozenten eingehen, damit sie anschließend beim Druckservice des RZ gedruckt werden können. Die WEB-Seite des Druckservice gibt verschiedene Hinweise zur Erstellung von DIN-A0-Postern und den Programmen, die man dabei einsetzen sollte!

Muss neben dem Poster eine Projekt-Dokumentation erstellt werden?

Eine schriftliche Projekt-Dokumentation ist nicht zwingend erforderlich, wird aber stark empfohlen. Auch der Betreuer kann als Auftraggeber der SW eine schriftliche Dokumentation der SW verlangen. Bei den späteren Projekt-Präsentationen ist es durchaus sinnvoll, neben dem Poster den Besuchern bei Bedarf auch eine schriftliche Dokumentation zu präsentieren, die ggf. ausführlicher Details der SW darstellen kann als das Poster.

Was gehört zur Projekt-Dokumentation?

Die schriftliche Dokumentation ist eine Mischung aus allgemeinen Informationen zum Arbeitsprozess, einem Lastenheft und einem Design-Dokument der Software.
Folgende Elemente sollte die Dokumentation enthalten:

• Beschreibung des verwendeten Vorgehensmodells, ggf. mit Details zur praktischen Umsetzung (z.B. verwendete Kommunikationsstrukturen)
• Allgemeine Beschreibung der Problemstellung und Feststellen des Lieferumfanges
• Anforderungsanalyse (Stakeholder/Ziele, Use Case Diagramm mit textueller Beschreibung der Use Cases, ggf. Verfeinerung mit Aktivitätsdiagrammen, Ableitung konkreter funktionaler und nichtfunktionaler Anforderungen)
• Statisches und dynamisches Design der Software (Klassendiagramme, Sequenzdiagramme der zentralen Funktionalität, ggf. Zustandsdiagramme und eingesetzte Design-Pattern, 4+1-Sichten falls erforderlich)
• Testen der Software und Qualitätssicherung (Durchgeführte blackbox/whitebox-Tests mit Beschreibung, ggf. Angabe von Äquivalenzklassen und entsprechender Test-Datensätze, ggf. Darstellung von gemessenen Metriken, Protokolle von Code-Reviews etc.)
• Abschließende Reflexion über das Projekt, z.B.: Was war gut/schlecht? Welche Arbeitsprozesse haben sich bewährt? Welche Verbesserungsvorschläge gibt es für zukünftige Projekte? etc.

Im Anhang:

• Kopien aller (wöchentlichen) Besprechungsprotokolle, aus denen die diskutierten Themen und vergebenen Aktionspunkte hervorgehen, sowie ein proaktives Risikomanagement.
• Ggf. der Source-Code der selber geschriebenen Teile des Produktes.

Weitere Einzelheiten können mit dem Betreuer abgesprochen werden.

Wann und wo finden die Projekt-Präsentationen im Rahmen der Software-Messe statt?

Ort und Zeit der nächsten Projekt-Präsentationen werden auf der Homepage bekanntgegeben. Für die Präsentationen erhält jede Gruppe einen Tisch (mit Stühlen) zum Aufbau einer praktischen Demonstration der SW, sowie eine Stellwand für ein DIN-A0-Poster. Die Stromversorgung ist sichergestellt, allerdings gibt es in der Regel keine LAN-Kabel in das Hochschulnetz. Internet sollte aber über EduROAM zur Verfügung stehen. Die Projekt-Präsentationen bzw. die Software-Messe ist öffentlich, d.h. alle Ausbildungsbetriebe, SCP-Jahrgänge und weitere interessierte Personen sind herzlich dazu eingeladen!