Wirtschaftsinformatik in der Praxis

Willkommen zurück!

In diesem Abschnitt möchte ich euch etwas über die Tätigkeiten während meiner Zeit am IRP erzählen. Der erste große Aufgabenbereich, an dem ich gearbeitet habe, war die Simulation des Roboters zum Laufen zu bringen. Dies ist in nahezu jedem Robotikprojekt der erste Schritt, da reale Roboterhardware sehr teuer ist und schwerwiegende Fehler zunächst in der Simulation erkannt und behoben werden sollten. Da ich das Projekt von meinem Vorgänger, der ins Auslandssemester ging, übernommen habe, war bereits ein großer Teil erarbeitet. Jedoch gab es noch einige Bugs, die behoben werden mussten. Die hat einige Zeit in Anspruch genommen und benötigt eine große Frustrationstoleranz, konnte jedoch am Ende gelöst werden. Während er Arbeit habe ich mich regelmäßig mit meiner Betreuerin getroffen oder ihre kleine update berichte geschrieben, um gemeinsam die nächsten Schritte und Ansatz abzusprechen. Das hat auch immer gut funktioniert und war immer ein gutes Feedback zum aktuellen stand. In dem Zustand des Projekts konnte der Arm seine ursprüngliche Position halten, indem durch den Control Loop die Kräfte von den Motoren ausgeübt wurden, die benötigt werden, um der Gravitation standzuhalten. Andererseits würde der Roboter in sich zusammenfallen. Grundsätzlich gibt es verschiedene Methoden, um Roboter zu steuern, neben Drehmoment, kann man kann auch z.B. die Position oder Geschwindigkeit der Motoren steuern, dies hängt von der gewünschten Anwendung ab.

Der zweite große Abschnitt begann mit der Ankunft der Roboterhardware. Der Roboterarm und die Hand wurden geliefert, und damit begann die Inbetriebnahme. In diesem Schritt war es notwendig, die mitgelieferte Dokumentation und Software gründlich zu prüfen und mit den von uns entwickelten Komponenten abzugleichen. Der Fokus lag insbesondere auf den Hardwareinterfaces – also den Schnittstellen, über die Bewegungsbefehle an den Roboter gesendet und Sensordaten gelesen werden können. Während dieser Zeit habe ich zusammen mit Jing gearbeitet, die ebenfalls als Hiwi angestellt war und, damit beschäftigt war code zu erstellen, um die Hand des Roboters auf einem Franka Roboter montieren zu können und unabhängig von dem Rest des Roboters steuern zu können.

Ein weiterer wichtiger Schritt war der Wechsel der verwendeten Bibliothek zur Berechnung der physikalischen Größen des Robotermodells: Anstelle von Orocos KDL (Kinematics and Dynamics Library) wurde nun Pinocchio eingesetzt. Dieser Wechsel war notwendig, da Pinocchio eine bessere Integration mit unserer Softwarearchitektur ermöglichte und effizientere Berechnungen der Kinematik und Dynamik lieferte – insbesondere für die spätere Kraftregelung und Trajektorienplanung. Dieser Wechsel jedoch auch einige Zeit in Anspruch genommen. Grundsätzlich gab es auch noch andere Tätigkeiten, die nicht so spannend sind wie z.B. Trägheitsmatrizen aus den CAD-Dateien des Roboters zu berechnen, um diese dann im mathematischen Model zu benutzen zu können. Da sich inzwischen jedoch meine Zeit am Institut dem Ende nahte, habe ich die letzten Wochen für die Dokumentation für einen späteren Nachfolger genutzt.

Hallo zusammen!

Ich bin Alexander und habe neun Monate als Hilfskraft in der Forschung am Institut für Robotik und Prozessinformatik der TU Braunschweig gearbeitet. Ich studiere Wirtschaftsinformatik im Master und habe zuvor bereits in der Lehre gearbeitet, sowohl während dem Bachelor als auch am Anfang vom Master. Die Projekte am IRP reichen von medizinischer Robotik über Robot Control bis hin zu Machine Learning in der Robotik, Leitung ist aktuell noch Professor Steil jedoch wird sich das bald ändern.

Dass ich überhaupt in der Robotik gelandet bin, war eher ein Zufall: Im ersten Semester meines Masterstudiums habe ich aus Interesse eine Robotik Vorlesung besucht, weil andere Veranstaltungen, die mich interessiert haben, nicht stattfanden. Dann hat sich zuerst eine Hiwi Stelle im Robotik Praktikum für das Sommer Semester 2024 ergeben. Passend zum Ende des Semesters wurde eine Stelle in der Forschung frei, die sehr gut zu meinen Interessenschwerpunkten passte, davon werde ich euch im Folgenden berichten.

Das Projekt, an dem ich gearbeitet habe, hatte das Ziel, einen Roboterarm mit einer humanoiden Hand so zu steuern, dass er in einem menschlichen Umfeld kollaborativ arbeiten kann. Die vorgesehene Tätigkeit war das Putzen von Oberflächen. Für Menschen ist diese Aufgabe zwar trivial (abgesehen von der körperlichen Anstrengung), doch für einen Roboter ist sie ziemlich komplex. Die Roboterhand muss sich an unterschiedliche, teils sehr komplexe Oberflächen anpassen können. Dafür wurde ein Experiment durchgeführt, bei dem mit Hilfe von Motion Capture menschliche Handbewegungen aufgezeichnet wurden. Diese Bewegungen sollten dann mithilfe von Machine Learning auf die Roboterhand übertragen werden. Mit diesem Teil des Projekts war meine Betreuerin beschäftigt. Kurze Info zum genutzten Roboter, dieser wurde von einem Start-up aus Braunschweig entwickelt und produziert, auf der Seite vom IRP könnt ihr mehr dazu finden.

Meine Aufgabe war es, am Controller des Roboterarms zu arbeiten, also an der Komponente, die die Hand zur gewünschten Position bewegt. Die Herausforderung besteht dabei darin, dass der Arm Kollisionen mit der Umgebung erkennen muss, um Schäden zu vermeiden und keine Personen zu gefährden. Gleichzeitig muss der Arm aber auch mit einer bestimmten Kraft gegen die zu reinigende Oberfläche drücken können – so wie es ein Mensch intuitiv macht.

Dafür wird eine Kontrollmethode namens „Hybrid Force-Motion Control“ verwendet. Ohne zu sehr ins Detail zu gehen: Es handelt sich um ein quadratisches Optimierungsproblem, das basierend auf dem aktuellen Roboterzustand die nötigen Drehkräfte für die Motoren berechnet, um die Hand entlang einer definierten Trajektorie zu bewegen. Dabei werden die 2 Fälle Bewegung mit Kontakt zu einer Oberfläche und ohne Kontakt unterschieden. Man benötigt auf jeden Fall Kenntnisse in Mathematik und Physik für die Formulierung des Problems.

Meine Anfangszeit war geprägt von der Einarbeitung in die bestehende Codebasis sowie in einige theoretische Grundlagen, die über die Inhalte meiner bisherigen Vorlesungen hinausgingen. Außerdem musste ich verschiedene Libraries lernen, die ich zuvor noch nicht kannte. Die gesamte Entwicklung erfolgte in C++ und wurde mit der Simulationssoftware Gazebo getestet. Um die einzelnen Software- und Hardwarekomponenten miteinander zu verbinden, wurde das Robot Operating System (ROS) verwendet.

Das wars erstmal zum Einstieg, wir sehen uns im Nächsten Blockeintrag.

Hallo nochmal,

im letzten Blog-Beitrag werde ich ein letztes Fazit über meine Erfahrungen als Werkstudent im Bereich IT-Consulting bei NewYorker ziehen. Insgesamt würde ich die Stelle weiterempfehlen. Von Anfang an habe ich mich im Team gut aufgehoben gefühlt. Der Umgang untereinander war offen und hilfsbereit. Fragen zu stellen oder bei Unsicherheiten Unterstützung zu bekommen, war jederzeit möglich. Gerade im agilen Arbeitsumfeld und in einem großen Unternehmen wie NewYorker ist das extrem hilfreich.

Hey zusammen,

in diesem Teil erzähle ich euch was ich seit Dezember 2024 als Werkstudent für Tätigkeiten habe.

Grundsätzlich arbeiten wir im Team nach Scrum, was bedeutet, dass wir täglich um 9 Uhr ein kurzes Daily haben und einmal wöchentlich ein längeres Weekly, in dem wir den Fortschritt, Herausforderungen und nächste Schritte besprechen. Diese regelmäßigen Meetings helfen dabei, transparent zu arbeiten und alle Teammitglieder auf dem gleichen Stand zu halten.

Ein Projekt, das ich von Anfang an mitgestalten durfte, war der Aufbau eines komplett neuen unternehmensinternen Wikis auf Basis von SharePoint. Dabei ging es nicht nur darum, Inhalte zu sammeln, sondern das ganze Wiki inhaltlich und strukturell aufzubauen, also Seiten sinnvoll zu gliedern, Inhalte aufzubereiten und dafür zu sorgen, dass Informationen für alle Teams innerhalb meiner Abteilung schnell verfügbar sind. Das hat mir gezeigt, wie wichtig gutes Wissensmanagement in größeren Organisationen ist. Ein weiteres spannendes Thema war die Arbeit mit Jira Forms: Gemeinsam mit dem Team habe ich an einem zentralen Anforderungsformular gearbeitet, das im Hintergrund automatisch Jira Epics erstellt. Ziel war es, Anfragen strukturiert zu erfassen und direkt in konkrete Arbeitspakete zu überführen, wodurch eine klare Verbindung von Business-Anforderungen zur IT-Umsetzung zu schaffen. Neben diesen Projekten habe ich regelmäßig Präsentationen vorbereitet und gehalten, was mir geholfen hat, komplexe Themen klar zu strukturieren und verständlich rüberzubringen. Außerdem unterstütze ich das Team bei verschiedenen organisatorischen und IT-bezogenen Aufgaben im im Daily-Business, wie z.B. die Pflege interner Tools bis zur Abstimmung zwischen Fachbereichen. Zuletzt war ich auch in Tests und Einführung neuer Systeme eingebunden, die im Rahmen unserer digitalen Prozessoptimierung im Lager eingesetzt werden. Das war besonders spannend, weil ich dabei auch mal ganz praktisch mit neuen Tools arbeiten konnte, bevor sie im Unternehmen endgültig live gehen.

In nächstem Blogeintrag werde ich euch über mein finales Fazit erzählen.

Hallo zusammen ein letztes Mal,

In diesem Beitrag möchte ich auf die finale Umsetzung des automatisierten Mapping-Prozesses und mein Fazit über meine Arbeit am DLR eingehen.

Nachdem die vorbereitenden Schritte abgeschlossen waren und somit die einzelnen Puzzleteile für den Gesamtprozess bereit waren, begann die eigentliche Automatisierungsarbeit. Hierbei ist mir immer wieder aufgefallen, dass man nicht alle Teile eines Prozesses verstehen muss, um ein Projekt voranzubringen. Inzwischen habe ich verstanden, mit was für Daten ich arbeite, wo diese herkommen und wo diese danach hingehen. Aber ich musste mich an keiner Stelle des Projektes mit den komplexen Berechnungen auseinandersetzen, die zu den Daten führen oder diese am Ende weiter verwenden. Ich konnte mit meinem Wissen über den Aufbau der Daten und den Umgang mit diesen das Projekt voranbringen.

Die Ausgangslage für das Mapping waren berechnete Datensätze in einem FEM-Solver-Format, ein Mapping-Tool mit Konsolenschnittstelle, und eine Definition, wie die Ergebnisdaten aussehen sollen. Für VP hatte ich einen Reader für die Daten, Funktionen zur Transformation von diesen, eine Schnittstelle zu dem Mapper und Extrahieren der Ergebnisse in Python implementiert. Die einzelnen Teile konnten nun alle in Reihe geschaltet werden, um beliebig große Datensätze automatisiert auf das Zielnetz zu mappen.

Die große Herausforderung für mich bestand in der Einarbeitung in ein umfangreiches, bestehendes Tool, welches sich noch in Entwicklung befindet. Dies ist aber auch ein großer Vorteil für mich, da ich es selbst an neue Anforderungen des Projektes anpassen kann und so aktiv an der Weiterentwicklung des Tools mitarbeite. Herausfordernd war zudem, bei den vielen einzelnen Schritten über den langen Prozess den Überblick zu behalten und entstandene Fehler zu finden. Entsprechend war es wichtig, immer wieder zwischendurch den implementierten Code zu testen und in den Austausch mit dem Team zu treten. Nur so konnten überhaupt Fehler im Detail gefunden werden. Während meiner Arbeit konnte ich auf einige Aspekte des Studiums zurückgreifen, wie strukturierte Datenverarbeitung, saubere Schnittstellendefinition, Dokumentation und Testen von Code.

Für mich war und ist es eine super Entscheidung gewesen, von meiner HiWi-Tätigkeit an den DLR zu wechseln. Ich konnte meine Fähigkeiten aus dem Studium in der Softwareentwicklung an einem echten Projekt anwenden und konnte sie sogar noch ausbauen. Zudem bekomme ich einen tiefen Einblick in die Arbeitsweisen und Prozesse einer großen Forschungseinrichtung. Dieser Teilabschnitt war für mich besonders positiv, da ich das Projekt von Anfang bis Ende begleitet habe. So konnte ich sehen, dass und wie die Ergebnisse des Projektes und meiner Arbeit tatsächlich Anwendung finden.

Damit endet mein Einblick in die Arbeit als Softwareentwickler am DLR. Ich hoffe, ich konnte einen interessanten Einblick in meine Tätigkeit in einem doch sehr fachfremden Feld geben. Vielleicht konnte ich auch etwas die Angst vor solchen Jobmöglichkeiten nehmen.

Viele Grüße

Felix

Hallo zusammen,

in diesem Beitrag möchte ich auf den Start am DLR und meine eigentlichen Tätigkeiten eingehen.

Ich wurde eingestellt, um die interne Softwareentwicklung des Projektes voranzutreiben. Dabei bin ich als Wirtschaftsinformatiker in ein Ingenieur-Umfeld eingestiegen. Ich war also sehr fachfremd. Ich hatte vieles von dem, womit ich während meiner Arbeit zu tun hatte, wenn überhaupt, nur einmal vorher gehört, aber mich nie damit beschäftigt. Aber dies wurde auch nicht erwartet. Ich war schließlich für die Softwareentwicklung zuständig und nicht für die Berechnung von Finite-Elemente-Methoden.

Das Projekt, an dem ich hauptsächlich gearbeitet habe, wurde in Python implementiert. Die erste Zeit verbrachte ich mit der Einarbeitung in die neue Umgebung beziehungsweise Software. Der Einfachheit halber werde ich diese im folgenden VP nennen. Dies war ein Tool, welches Abteilungsintern entwickelt wurde und die Arbeit mit den Ergebnissen verschiedener FEM-Solver, welche am Markt erhältlich sind, erleichtern soll. FEM-Solver hatte ich zuvor schon gehört, aber nie damit gearbeitet. Dies war nicht weiter problematisch, da ich lediglich mit den Ergebnisdaten zu tun hatte und keine komplexen Berechnungen verstehen oder ausführen musste. Als erster Schritt sollte das Tool um eine Möglichkeit ergänzt werden, einzelne Daten aus den Ergebnisdateien auszulesen. Dies sollte eine Datenverarbeitung unabhängig von dem Programm ermöglichen, mit welchem diese erstellt wurden. Somit kann das Sammeln von Daten aus verschiedenen Ergebnissen automatisiert werden, ohne sich durch eine GUI klicken zu müssen. 

Nach Abschluss dessen hatte ich einen guten Überblick über die Datenstrukturen, mit denen ich arbeiten werde. Aber auch über mein Team. Ich wusste nun, wen ich wofür fragen konnte und wer wofür zuständig war. Hierbei erlebte ich große Hilfsbereitschaft und mir wurde ein super Einstieg in das Team ermöglicht.

Als Nächstes fanden vorbereitende Schritte für die Automatisierung eines Mapping-Prozesses statt. Ziel war es, Daten als Randbedingung für eine Folge-Berechnung automatisiert zusammen zu sammeln und im geforderten Format bereitzustellen. Teil dieses Prozesses war ein externes Mapping-Tool, um Messdaten von verschiedenen Ausgangsnetzen auf ein Zielnetz zu übertragen. Dies geschieht, damit im Folgeschritt immer das gleiche Netz verwendet werden kann. Dazu habe ich mich in das Mapping-Tool eingearbeitet und geplant, was notwendig ist, um dieses in den Ablauf automatisiert zu integrieren. Um die Daten korrekt aus den Ergebnissen extrahieren zu können, mussten neue Funktionalitäten für VP geschrieben werden. Dies beinhaltet das Einlesen verschiedener Datensätze und die Transformation der Daten in das benötigte Format des Mappers.

Nachdem diese Vorbereitung abgeschlossen war, konnte das Zusammenstellen des automatisierten Mapping-Prozesses beginnen. Darauf und auf mein Fazit über meine Zeit am DLR werde ich im nächsten Beitrag eingehen.

Viele Grüße

Felix

Hallo zusammen,
ich bin Felix und studiere in meinem letzten Semester Wirtschaftsinformatik. Ich arbeite seit etwa einem Jahr als studentische Hilfskraft am Deutschen Zentrum für Luft- und Raumfahrt (DLR). Innerhalb meines Projektes kümmere ich mich um die Weiterentwicklung der internen Software. In diesem Beitrag werde ich das DLR an sich und meinen Weg zum DLR vorstellen.
Das DLR ist eine der größten Forschungseinrichtungen Europas im Bereich Luftfahrt, Raumfahrt, Energie und Verkehr. Das DLR beschäftigt etwa 11.000 Mitarbeitende an über 30 Standorten in Deutschland. Ähnlich wie unsere Uni ist das DLR in verschiedene Institute mit ihren jeweiligen Forschungsschwerpunkten gegliedert. Am DLR sind dies insgesamt 55 Institute über alle Standorte hinweg. Der Hauptsitz befindet sich in Köln. Über die Grenzen Deutschlands hinweg betreibt der DLR Büros in Brüssel, Paris, Tokio und Washington, D.C. Für mich war aufgrund seiner Nähe der Standort hier in Braunschweig interessant. An diesem bin ich nun auch beschäftigt. Dieser liegt am Flughafen im Nordosten Braunschweigs. Mit etwa 1250 Mitarbeitenden ist dies der drittgrößte Standort Deutschlands. Forschungsschwerpunkte in Braunschweig sind unter anderem Fahr- und Flugsimulatoren, Luftverkehrssimulationsanlagen, Windkanäle und Werkstoffprüfstände.

Ich selbst arbeite in einem Projekt des Instituts für Systemleichtbau. Kernkompetenz des Instituts ist die Forschung an und das Herstellen von extrem leichten und filigranen Strukturen aus Faserverbundstoffen, z.B. Carbon. Diese Werkstoffe werden viel in der Luft- und Raumfahrt eingesetzt. In meinem Projekt geht es um die effizientere Herstellung solcher Stoffe.
Mein Weg zum DLR führte mich tatsächlich über die Bonding-Firmenkontaktmesse, welche jährlich hier an der Uni stattfindet. Ich war dort auf der Suche nach einer Stelle im Bereich Softwareentwicklung hier in der Region. Am Stand des DLR wurde mir eine Initiativbewerbung in diesem Bereich empfohlen, da solche Stellen an sich nicht ausgeschrieben werden. Jedoch ist inzwischen in sehr vielen Abteilungen Programmieren und auch Softwareentwicklung Alltag geworden. Etwa eine Woche nach meiner Bewerbung bekam ich eine Rückmeldung und eine Einladung zu einem Gespräch mit meinem jetzigen Chef. Dieses wurde ohne HR-Abteilung geführt. Ich hatte direkt das Gefühl, dass mir auf Augenhöhe begegnet wurde. In dem Gespräch ging es eher darum, in welche Richtung sich die Tätigkeit entwickeln würde und ob ich mir dies vorstellen könnte. Nach dem Gespräch wurde mir die Stelle angeboten, wobei flexibel auf mich eingegangen wurde, da ich zu der Zeit noch als HiWi an der Uni beschäftigt war und nicht direkt starten konnte. Ich empfand den Bewerbungsprozess am DLR sehr positiv und er konnte mir eventuelle Ängste vor künftigen Bewerbungsprozessen nehmen.

Im nächsten Beitrag werde ich auf meine Zeit am DLR eingehen.

Viele Grüße
Felix

Hallo zusammen,

mein Name ist Hieu und studiere Wirtschaftsinformatik im Master an der TU Braunschweig. Seit fast einem Jahr arbeite ich nun als Werkstudent bei der NEW YORKER Information Services International GmbH in Braunschweig. 

Zunächst möchte ich etwas über NewYorker und der IT erzählen und vorstellen. 

New Yorker ist ein deutsches Bekleidungsunternehmen mit Hauptsitz in Braunschweig. Gegründet wurde es 1971, und seitdem expandiert das Unternehmen kontinuierlich ins Ausland. Heute betreibt New Yorker über 1.200 Filialen in 47 Ländern und beschäftigt mehr als 23.000 Mitarbeitende. Die IT von New Yorker hat ihren Sitz in der Unternehmenszentrale in Braunschweig. Von hier aus werden sämtliche IT-Aktivitäten gesteuert, die das Unternehmen weltweit betreffen. Ob Stores, Logistik, Finance oder HR, alle Bereiche sind auf eine funktionierende IT angewiesen, und die Koordination dafür läuft zentral aus Braunschweig. Die NewYorker IT versteht sich dabei als eine Art interner Dienstleister. Das bedeutet, dass die Fachbereiche im Unternehmen mit ihren Anforderungen zu uns kommen und wir als IT versuchen, passende Lösungen zu finden und umzusetzen. 

Während meiner Werkstudententätigkeit bin ich im IT-Consulting mit dem Schwerpunkt Projekt- und Requirements-Management eingesetzt. Von hier aus erhalte ich Einblicke, wie Anforderungen aus den Fachbereichen aufgenommen, strukturiert und in Projekten umgesetzt werden. In den folgenden Blogeinträgen möchte ich etwas genauer zu meiner Werkstudentenstelle erzählen. Dazu werde ich im nächsten Beitrag auf meine konkreten Aufgaben eingehen und im letzten ein kurzes Fazit ziehen.

Hallo ein letztes Mal zurück,

In diesem Part möchte ich ein wenig das Arbeitsumfeld beim GAMS vorstellen.

Für mich, der davor nur in Großkonzernen gearbeitet hat war es zunächst ein kleiner Kulturschock in umgebauten Wohnungen zu arbeiten und mein eigenes Gerät für die Arbeit zu verwenden. Im Allgemeinen war die Firma sehr flexibel in den Bereichen Urlaub, Arbeitszeiten, oder Arbeitsplatz. Normalerweise arbeitet ich einen Tag von Zuhause und einen Tag direkt im Büro, aber auch mehrere Wochen Homeoffice waren kein Problem. Das Arbeitsklima war meist angenehm.
Auch meine Einarbeitung fing sehr gut and, mir wurde direkt am ersten Arbeitstag anhand eines kurzen Beispiels erklärt, warum mathematische Optimierung wichtig ist. Die meisten Personen im Unternehmen wurden mir zudem auch vorgestellt, allerdings hätte mir genauer gesagt werden können, wer für welche Aufgaben verantwortlich ist, da ich später häufig wichtige Personen erfragen musste. Außerdem war die Einarbeitung in die Hauseigene Software relativ schwierig, da ich nur die frei online zur Verfügung stehenden Mittel hatte. So war die Dokumentation häufig ungenau, veraltet oder Schlicht nicht existent. Auch die Vernetzung zu anderen Angestellten, zu denen ich nicht direkt Kontakt hatte ereignete sich häufig als schwierig. Dies war insbesondere der Fall in einem späteren Projektabschnitt. Hier lernte ich erst nach Wochen, dass ein Experte für die Software Angestellt war, allerdings ausschließlich im Home-Office arbeitete.

Abschließend würde ich meine Zeit bei GAMS als gut bezeichnen, da ich das Arbeitsumfeld angenehm und flexible war die Arbeit stellenweise das richtige Maß an Forderung hatte und ich viel neues gelernt hatte. Dies trifft nicht nur auf die spezifische Software, sondern auch das Allgemeine das Erstellen dieser im Team zu.

– Florian Graf

Hallo und willkommen zurück,

für den zweiten Teil meines Praxisberichts. In diesem Teil werde ich meine Aufgaben genauer Vorstellen, dabei möchte ich mich auf zwei größere Projekte fokussieren und besondere Herausforderungen hervorheben. Zusätzlich möchte ich noch ein wenig über das Arbeitsumfeld sprechen.

Meine erste größere Aufgabe war es mich in ein bereits laufendes Projekt einzuarbeiten. Hierbei ging es um das Erstellen eines Optimierungsprogramms für die Schichtplanung in einem Krankenhaus. Die Aufgabe bestand darin, das bereits angefangene Modell zu erweitern. Dabei gab es mehrere Herausforderungen zu überwinden. Zu nächst einmal kannte ich mich noch nicht mit der Modellierungssprache aus, weshalb es schwierig war mich in den Code einzuarbeiten, zusätzlich war es eine der ersten Male, dass ich ein wirklich relativ langen Code verstehen musste, welcher von einer anderen Person geschrieben wurde. In diesem Projekt musste ich unter anderem: Code von einer Programmiersprache in eine andere „übersetzen“, kurze Skripte schreiben, um Dateien aufzubereiten, Anforderungen aus einem fremdem Fachgebiet interpretieren, umsetzen und untere anderem realistisch abändern und mir sinnvolle Skalen, Diagrammarten und Kennzahlen für Grafiken überlegen.

Mein zweites größeren Projekt sollte ich ein Beispiel für ein Optimierungsprogramm von einer Freeware in die GAMS-Sprache übersetzen. Hier bestand die erste Herausforderung darin überhaupt ein sinnvolles Konstrukt für ein Optimierungsproblem zu finden. Bei Rücksprache mit meiner Chefin lernte ich außerdem, dass für sich aussagekräftiger Code bei einem größeren Code-Projekt eine große Bedeutung spielt. Zudem musste ich auch die Beschreibung von Optimierungsproblemen von natürlicher in Code-basierte Sprache und Formeln umsetzen und vice verca.

Allgemein fand ich das Aufgabenprofil relativ abwechslungsreich, auch wenn einem natürliche einige Aufgaben mehr Spaß machen als andere.
In meinem nächsten Bericht gebe ich noch einen kurzen Überblick über die Arbeitsweisen bei GAMS.