Informationen zu den SWT-Projekten

Das Software-Projekt im Rahmen der Vorlesung 'Softwaretechnik' (SWT) soll alle Studierenden in die Lage versetzen, ein überschaubares SW-Projekt in all seinen Phasen selbständig durchzuführen. Dabei ist es wichtig, dass die Studierenden in Gruppen und nicht alleine arbeiten. Die Gruppengröße variiert (aufgrund der unterschiedlichen Studierendenzahlen) je nach Standort:

• Aachen: 4-6 Teilnehmer pro Gruppe (idealerweise 4-5 Teilnehmer)
• Jülich: 2-4 Teilnehmer pro Gruppe (idealerweise 3 Teilnehmer)
• Köln: 2-4 Teilnehmer pro Gruppe (idealerweise 2-3 Teilnehmer)

Jede Gruppe wird von einem 'realen' Auftraggeber aus einer Firma oder einem Institut betreut. Ziel der Projekte ist das systematische Anwenden von Vorgehensweisen der Softwaretechnik, die vom Erfassen der Anforderungen bis zum systematischen Testen der Software und Dokumentation des gesamten Arbeitsprozesses reichen.

Erfahrungsgemäß haben nicht alle Ausbildungsfirmen und Institute geeignetet Themenstellungen. Falls es tatsächlich mehr Themen als Gruppen geben sollte, wird versucht den Firmen den Vortritt zu lassen, die in den letzten Jahren noch 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 selber als Auftraggeber fungieren.

Nein, die Zeit für die Projektarbeit ist Teil der 9 ECTS-Veranstaltung "Softwaretechnik". Die 9 ECTS bedeuten ca. 270 Arbeitsstunden pro Studierendem, und diese Zeit kann nur durch Vorlesungen und Übungen (incl. Vor- und Nachbereitungszeit) nicht erreicht werden. Die Arbeit an den Projekten ist daher genauso zu werten wie die Zeit in den Vorlesungen oder Übungen!

Die Arbeit an den Projekten beginnt Anfang/Mitte Dezember, und endet kurz vor der Softwaretechnik-Messe, die in der Regel Anfang März stattfindet. Dort können die Studierenden ihre Ergebnisse der Öffentlichkeit mit Hilfe eines Posters und praktischer Demonstrationen präsentieren.

Die Ergebnisse der Projekte fließen nicht in die Endnote des Fachs Softwaretechnik 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.

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. Bei der Beantragung eines Projektes kann ein Auftraggeber bereits Teammitglieder festlegen (z.B. eigene Auszubildende).

Ab Anfang Dezember stehen die Zeiten für die Vorlesung für die Projektarbeit zur Verfügung. Die Vorlesungen werden bis zu diesem Zeitpunkt mit einem größeren Umfang durchgeführt, damit im Mittel ein Vorlesungsumfang von V2 sichergestellt ist. 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 in den Ausbildungsstandorten können nicht alle Teams die Projektarbeit am Standort 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 liefert wird davon ausgegangen, dass sich das Team am Ausbildungsstandort befindet. Die Dozenten werden stichprobenartig die Arbeitsphasen der Teams überprüfen.

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 Kurs selber 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 bei den Informationen zu den SWT-Projekten.
Dabei sollte es sich im Falle von 'echten' Firmenprojekten natürlich nicht um 'kritische' Produkte 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 gut motiviert und noch realistischer in eine Entwicklungssituation eingebunden, die ihr späteres Berufsbild gut abbildet.

Die Projekte sollten in der Regel in Java zu implementieren sein, da diese Sprache in den ersten 2 Semestern 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.

Jedes Team erstellt in der Regel ein Verzeichnis auf dem Gitlab-Server der FH Aachen (https://git.fh-aachen.de), 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 die Dozenten muß es aber auf jeden Fall eine Möglichkeit geben, die Arbeit am Quelltext nachvollziehen zu können und Protokolle der Besprechungen einzusehen.

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 bei den Informationen zu den SWT-Projekten.

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.

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 wird zur Verfügung gestellt). 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) im Rahmen der allgemeinen Kompetenzen.

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.

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.

Die Teams liefern am Ende des Projektes den Quelltext und die Besprechungsprotokolle auf dem Git-Server ab. Als weitere Pflichtdokumentation ist ein DIN-A0-Poster zu erstellen, das auf einer Formatvorlage basieren muss (eine Vorlage kann heruntergeladen werden). 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 der Poster übernimmt i.d.R. der Ausbildungsstandort. 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 ein paar Tage dauern kann, sollten die Vorlagen spätestens eine Woche vor Projektende bei den Dozenten eingehen, damit sie anschließend gedruckt werden können.

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ührlichere Details der SW darstellen kann als das Poster.

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.

Ort und Zeit der nächsten Softwaretechnik-Messe werden in ILIAS 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. Internet sollte aber in der Regel über eduroam zur Verfügung stehen. Die Projekt-Präsentationen bzw. die Softwaretechnik-Messe ist öffentlich, d.h. alle Ausbildungsbetriebe, MATSE/AMI-Jahrgänge und weitere interessierte Personen sind herzlich dazu eingeladen!