Im Rahmen von Systems Engineering (SE) wird ein System in seiner Gesamtheit betrachtet. Dabei ist das System mehr als nur die Summe seiner Einzelteile, wie z. B. die reinen Software-, Hardware-, Mechanik- oder Optikkomponenten. Grundsätzlich können die Methoden des Systems Engineerings bei Systemen, die mehr als lediglich Software für einen Standardrechner darstellen, zur Anwendung kommen.
Die Betrachtung eines Systems in seiner Gesamtheit bedeutet im Systems Engineering auch, alle Anforderungen an das System über den gesamten Produktlebenszyklus von der Idee bis hin zur Entsorgung zu berücksichtigen. Neben den reinen Anforderungen an das Produkt bzgl. seiner Funktionalität und Qualität (hier spielen z. B. die Aspekte Safety und Security eine große Rolle) kommen zusätzliche Anforderungen z.B. aus den Disziplinen Logistik, Fertigung, Qualitätssicherung, Weiterentwicklung, Pflege, Wartung oder Entsorgung. Hierbei können neben den klassischen Ansätzen des Systems Engineerings, agile Vorgehensweisen wie Scrum, Kanban, das Lean Management oder Rapid Prototyping helfen.
Im Rahmen des Systems Engineerings werden in der Systemanalyse belastbare Anforderungen mit Requirements Engineering-Methoden identifiziert, die Systemarchitektur erstellt, die Teile des Systems zusammengebaut und anschließend, unterstützt durch eine Testabteilung, getestet. Dafür können verschiedene Ansätze angewendet werden. Dazu gehören das Model Based Systems Engineering (MBSE), welches die Grundlage für das Model Driven Systems Engineering (MDSE) legen kann. Zudem gibt es auch domänen- und testgetriebene Ansätze. Bei der Wahl eines Ansatzes müssen jeweils die Rahmenbedingungen des jeweiligen Projektes berücksichtigt werden. Die Betrachtung der Tätigkeiten erfolgt auf unterschiedlichen Architekturebenen, wie System, Subsystem, das aus mehreren Komponenten besteht, oder reinen z.B. Hardware- oder Software-Komponenten. Die unterste Betrachtungsebene wird dabei durch den Teil des Systems gegeben, der an einen internen oder externen Zulieferer weitergegeben wird.
Im Systems Engineering sorgt man dafür, dass aus einer multidisziplinären eine interdisziplinäre Entwicklung wird. Dadurch wird Transparenz geschaffen, die Wissensvermittlung innerhalb des Teams erhöht, die Zusammenarbeit verbessert und Zykluszeiten verkürzt. Dabei ist das Systems Engineering die erste Anlaufstelle für die Projektleitung und teilweise auch in der Rolle der technischen Projektleitung tätig. Neben guten Moderationsfähigkeiten muss man im Systems Engineering über genügend Wissen zur Beurteilung einzelner Entscheidungen auf Komponentenebene verfügen. Des Weiteren sorgt man dafür, dass die an der Entwicklung beteiligten Personen über eine Entscheidungsgrundlage verfügen.
Mehr Wissen zum Thema Systems Engineering finden Sie neben den Informationen auf dieser Seite auch in unserer downloadbaren Broschüre unter "WISSEN for free", den Büchern der SOPHISTen und den Inhouse und Offenen Trainings der SOPHISTen.
Anwendungsgebiete für Systems Engineering sind komplexe Systeme, wie z.B. Smart Ecosystems, Züge und Steuerungen einzelner Aspekte, Kraftfahrzeuge und deren Steuergeräte, Radarsysteme, Gebäudesteuerungen, Heizungsanlagen oder medizinische Behandlungseinheiten. Die Rolle des Systems Engineerings gewinnt gerade bei Smart Ecosystems aufgrund des Zusammenspiels einzelner Teilsysteme zu einem Ganzen immer mehr an Bedeutung. Anwendungsgebiete für Smart Ecosystems sind z.B. Industrie 4.0, Smart Home, Smart Health, Smart Grid, Smart Mobility, Smart Farming oder Smart Rural Areas.
Im Kontext von Systems Engineering ist es wichtig dafür zu motivieren, dass es sich lohnt, möglichst früh im Entwicklungsprozess Aufwand zu investieren, um am Ende Aufwand einsparen zu können. So bringt z.B. eine ausreichende Analyse von Anforderungen ein besseres Verständnis dafür, was ein System später tun soll, und dass die aus der Architektur folgenden Komponenten des Systems korrekt zusammenarbeiten und gemeinsam das von den Kunden gewünschte Verhalten aufweisen. Damit minimiert der frühe Aufwand für eine Analyse und Architektur gleichzeitig das Risiko einer Fehlentwicklung, sowie von ungewollten Überraschungen. Zusätzlich wird sichergestellt, dass frühzeitig klar ist, was realisierbar ist und was es kosten wird. Weiterhin unterstützt das Systems Engineering beispielsweise dabei:
Wie bei jeder Einführung von etwas Neuem ist es wichtig, einen Änderungsprozess zur Erreichung des Einführungsziels zu etablieren.
In der Regel betreibt jedes Unternehmen bereits Systems Engineering auf irgendeine Art und Weise. Dieses Systems Engineering ist jedoch nicht explizit. Mit einem expliziten Systems- ngineering wird sichergestellt, dass Entscheidungen bewusst und zur richtigen Zeit getroffen werden können.
Als Einführungsstrategie von Systems Engineering ist nicht nur die vollständige Einführung eines neuen Prozesses von Beginn an vorstellbar. Vielmehr ist auch eine sukzessive, vorsichtige Einführung möglich, in dem eine Person zunächst nur implizit Verantwortung für Systems Engineering übernimmt und mehr die allwissende Ansprechperson im Projekt spielt. Dadurch wird die Bedeutung einer solchen zentralen Rolle in einem realen Projekt gesehen, so dass ihre Etablierung im Unternehmen leichter motiviert werden kann.
Nicht zuletzt bedeutet die Einführung von Systems Engineering für viele Unternehmen eine umfassende und nachhaltige Veränderung der Entwicklungsprozesse und verlangt zusätzlich eine Weiterentwicklung der Unternehmenskultur. Hier können sich Ansätze des Change Managements und agile Methoden und Denkweisen als hilfreich erweisen.
Im Systems Engineering werden in den Disziplinen Analyse und Architektur die Notationen der Modellierung, wie UML (Unified Modelling Language) und SysML (System Modelling Language), sowie zusätzlich in der Analyse textuelle Beschreibungen als Ergänzung für zumeist nichtfunktionale Anforderungen verwendet. Die in der Analyse verwendeten Diagramme der UML sind z.B. das Klassendiagramm als Informationsmodell, Use-Case- und Aktivitätsdiagramm für die funktionale Perspektive und Zustandsautomaten für die verhaltensorientierte Perspektive. Mit der SysML können neben den Diagrammen der UML auch Blockdiagramme als Informationsmodell verwendet werden. Für die Architektur werden in der UML Komponenten- und Sequenzdiagramme, sowie in der SysML Block-Definition- und Internal Block- und Sequenzdiagramme benutzt. In der Systemintegration werden keine modellbasierten Notationen verwendet. Im Bereich Test gibt es eigene erprobte Notationen, die meistens natürlich-sprachlich oder aber formaler zum Zwecke einer Testautomatisierung sind.
Bei Fragen zu den Trainings, Beratung oder Projektarbeit der SOPHISTen stehen wir Ihnen gerne zur Verfügung: Von der Organisation und Vorbereitung über die Durchführung bis hin zur Nachbereitung. Ihre Ansprechperson hilft Ihnen gerne weiter.
Copyright 2018
Sie benötigen weitere Informationen?
Rufen Sie uns an und lassen Sie sich direkt an den richtigen Kontakt durchstellen.
Tel: +49 (0)9 11 40 90 00
E-Mail: heureka[at]sophist[dot]de
Unsere Bürozeiten sind: Montag bis Donnerstag: Freitag:
08:00 - 18:00 Uhr 08:00 - 17:00 Uhr
Natürlich können Sie auch gerne direkt per E-Mail diverse Abteilungen erreichen:
Rund um das Thema Trainings sowie Projekt- und Beratungstätigkeiten
Rund um unsere Stellenangebote und Ihre Karrierechancen bei SOPHIST
DeineZukunft[at]sophist[dot]de
Zu Events und Marketing sowie unseren Publikationen
Unser Impressum finden Sie hier: