Im Rahmen des Software-Engineering-Projekts der TU Darmstadt erhielten wir die Aufgabe, über einen Zeitraum von einem Semester hinweg für die Firma REA Elektronik GmbH einen graphischen Konfigurator als Web-App zu entwickeln. Die Software sollte speziell für die Verwendung auf iPads optimiert sein, aber auch auf gängigen Desktop-Browsern (Chrome, Firefox) laufen.

Unser Team Läserkraft setzt sich aus sieben Studenten der TU Darmstadt zusammen, davon sechs im Bachelor Informatik und einer im Master Informatik / ETiT.

Der Bereich REA JET der Firma REA Elektronik GmbH stellt Laserkennzeichnungssysteme zur berührungslosen Beschriftung von verschiedenen Produkten und Oberflächen her. Abhängig von dem jeweiligen Einsatzgebiet muss das Lasersystem unterschiedliche Wellenlängen, Linsen mit verschiedenen Brennweiten, Strahlweg-Optionen etc. beinhalten, wofür entsprechende Komponenten und Zubehör verwendet werden.

Für die Zusammenstellung von Laser-Konfigurationen haben die Vertriebler der Abteilung REA JET bisher ein recht komplex zu benutzendes Dokument, den sogenannten Quick Selection Guide, verwendet, welcher über über eine Graph-ähnliche Darstellung auf 11 DIN-A4-Seiten mögliche Konfigurationsschritte festlegt. Dies umfasst, welche Komponenten ausgewählt werden müssen und welche Abhängigkeiten zwischen den einzelnen Elementen bestehen bzw. welche Kombinationen möglich sind oder welche Komponenten nicht miteinander vereinbar sind.

Da das Erstellen von neuen Konfigurationen per Hand fehler- und zeitanfällig ist, war eine Vereinfachung des Konfigurationsprozesses gewünscht. Im Rahmen des Software-Engineering-Projekts sollte daher eine Web-Anwendung entstehen, die eine Schritt-für-Schritt-Auswahl von Komponenten ermöglicht und die Überprüfung der Validität der ausgewählten Konfiguration auf Basis des Quick Selection Guides automatisiert. Zusätzlich sollte der Zustand der Konfiguration in einer 3D-Ansicht visualisiert werden, um jederzeit einen Überblick über das Lasersystem und dessen Dimensionen in der Produktivumgebung zu erhalten.

Zur Umsetzung dieser Anforderungen wurde eine React-App unter Verwendung von Redux für die Verwaltung des States entwickelt. Mithilfe der JavaScript-Library three.js wird in der Hauptansicht eine 3D-Szene von Laser-Komponenten dargestellt, welche mithilfe von Snappoints an dafür vorgesehenen Stellen miteinander verbunden werden können. Konfigurationselemente lassen sich über ein Menü und eine geführte Navigation nacheinander aus- oder abwählen. Am Ende der Konfiguration lässt sich eine Übersicht der gewählten Elemente anzeigen, um daraus Angebote zu erstellen.

Um jedem Vertriebler die Verwaltung der eigenen Konfigurationen zu ermöglichen, können diese geladen, gespeichert, mithilfe einer zentralen Datenbank synchronisiert und über die jeweilige E-Mail-Adresse dem Autor zugeordnet werden.

»Vorbereitung ist die halbe Miete«

Zu Beginn des Projekts haben wir mehrere Tage dafür aufgewandt uns in alle für das Projekt wichtige Technologien einzuarbeiten. Dadurch hatten alle Teammitglieder mindestens Grundkenntnisse in allen wichtigen Bereichen. Das hat sich im Laufe des Projekts oft ausgezahlt, da sich alle Entwickler in allen Teilbereichen auskannten und die anstehenden User Stories problemlos verteilt werden konnten.

»Storming is real«

Im ersten HDA Teamtraining wurde uns empfohlen für Meetings einen Moderator zu bestimmen, der die Diskussionen leitet. Was für uns zunächst übertrieben erschien, zeigte sich als sehr sinnvolle Maßnahme, durch die unsere Meetings mindestens 10x produktiver wurden. In Meetings mit einer siebenköpfigen Gruppe, in der alle Teammitglieder voller Tatendrang sind und sich einbringen möchten, muss zunächst einfach ein bisschen Struktur herrschen.

»Gut geplant ist halb gewonnen«

Während unseren Meetings haben wir viel Zeit für Planung und Organisation aufgewandt. Was manche vielleicht als unnötigen Overhead abtun, hat sich für uns unglaublich bezahlt gemacht. Im Laufe des Projekts mussten wir oft vom Projektplan abweichen, waren aber auf alle Situationen gut vorbereitet.

»Geteiltes Projekt ist doppeltes Projekt«

Zunächst waren zwei Teams für die Arbeit an unserem Projekt geplant. In der Theorie sollte durch die Aufteilung des Projekts viel Zeit übrig bleiben, sodass bei der Implementierung bessere Codequalität erzielt werden kann. In der Praxis hat sich aber gezeigt, dass bei der Zusammenarbeit von zwei Teams ein erheblicher Overhead entsteht, vor allem bei der Kommunikation für die Termin- und Entscheidungsfindung. Mit zwei Müttern kann man schließlich auch kein Kind in 4,5 Monaten zur Welt bringen.

… get together. Nutzt die SE Räume, um gemeinsam am Projekt zu arbeiten. So weiß jeder, woran die anderen gerade so arbeiten und bei Bedarf können Entscheidungen schnell gemeinsam getroffen werden.

… communicate. Egal ob mit eurem Auftraggeber, der STG oder teamintern. Probleme können nicht gelöst werden, bevor sie angesprochen werden.

.. reviews. In unserem QS-Prozess haben wir festgelegt, dass jede User Story nach der Implementierung von mindestens zwei Reviewern kontrolliert wird. Dadurch konnten wir eigentlich alle Fehler im Code aufdecken, bevor sie im Master gelandet sind.

… reinvent the wheel Öfter mal recherchieren, ob das vorliegende Problem nicht schon durchdacht und gelöst wurde.

… mix personal and professional Der Umgangston im Projekt und vor allem mit dem Auftraggeber kann schon mal rauer werden. Wer am Ende des Projekts noch mit allen Teammitgliedern befreundet sein will, muss lernen Kritik und Diskussionen nicht persönlich zu nehmen.

… sleep. Drink a lot of coffee :-)