Nicht nur die eingeladenen Speaker haben ein hervorragendes Wissen, auch jeder Teilnehmer ist ein Experte auf seinem Gebiet und der gemeinsame Austausch auf Augenhöhe ist für alle ein großer Gewinn. Der Open-Space ist dafür ein sehr schönes Format. Auf den vergangenen MESCONF-Konferenzen wurden diese Sessions von den Teilnehmern immer wieder als besonders lohnenswert hervorgehoben.

Wir erklären Ihnen vor Ort, wie das Format funktioniert. Jeder hat dort die Möglichkeit ein Thema vorzuschlagen. Sie haben jetzt schon ein Thema? Schicken Sie Ihren Vorschlag an: tim.weilkiens@oose.de

Unsere Themen bisher:

Andreas Willert – Modelle als Digitales Lastenheft
In wie weit eignen sich Modelle um rein textbasierte Lastenhefte und Pflichtenhefte zu ergänzen oder zu ersetzen?
Was ist der Nutzen? (Frühzeitige Verifikation, Bessere Traceability …)
Wie ist der reifegrad in der praktischen Anwendung? Gibt es funktionierende Austauschformate für Modelle, z.B. wie ReqIF für Reqirements?

Phil Alder
Als Systems Engineer kämpfe ich oft mit 3 Tools gleichzeitig: DOORs für die Requirements, Rhapssody/EA für die Systemmodellierung und Eclipse/VS für die Quellverwaltung.
Nein, meistens kommt noch ein 4. Tool wie JIRA oder Redmine für das Bugtracking und die Planung hinzu. Geht das nicht irgendwie besser und voll integriert?


Alexander Huwaldt
Modellgetriebene Dokumentation in embedded Projekten

Auch das Projektmanagement bei der Entwicklung eingebetteter Systeme wird, vor allem bei schweren Softwareprozessen, oft durch das Vorlegen von Dokumentationen getriggert. Sind
Meilensteine erreicht manifestiert sich das in Dokumenten. Für das Controlling der Projekte stellen die in Word und Excel verfassten Darlegungen die Projektwahrheit dar. Tatsächlich sind solche Dokumente oft alles andere als ein echtes Abbild der Projektrealität.

Modellgetriebene Projekte bieten die Möglichkeit Dokumentationen aus dem Repository zu erstellen. Dabei gibt es nur eine Quelle und das ist immer das Modell (single source of truth).

Alexander Schneider
Abgrenzung zwischen Informal, Semi-Formal und Formal In Standards wie der ISO 26262 werden je nach Safety Integrity Level verschiedene Notationen empfohlen, bzw. verlangt. Unter Informal und Formal kann man sich noch etwas vorstellen. Aber was bedeutet Semi-Formal? Irgend etwas dazwischen, aber wo genau liegen die Grenzen? Und kann eine Modellierungssprache Formal sein, auch wenn sie nicht rein Mathematisch ist?

Michael Brahm
Im Rahmen unserer Systems Enginnering Arbeit sind viele verschiedenen Aspekte des Gesamtsystems abzubilden, wie etwa: Mechanische & Strukturmodelle, Verkabelung, Massenbudgets, Funktionale Anforderungen und Beschreibungen, Thermalmodelle und Beschreibungen, Beschreibung der verfügbaren Telemetriedaten, Beschreibung der Kommunikationsschnittstellen der Hardware, Beschreibung von Echtzeiteigenschaften, …

Für die meisten dieser Aspekte werden separate Datenformate und teilweise Modelle verwendet, obwohl es zwischen diesen Aspekten
durchaus Abhängigkeiten gibt. Ich wäre sehr daran interessiert zu erfahren wie andere Firmen die Komplexität solcher System handhaben und eventuell sogar in
einem gemeinsamen Modell oder einer gemeinsamen Datenbasis abbilden.

Rebecca Reuter & Jürgen Mottok
Eignung eines Lehrinstruments für die Modellierung mit der UML


Martin Bussas
Erfassung von Vitalitätsparametern und Klassifizierung des kognitiven Zustands durch maschinelles Lernen – VitaB