Systems-Engineering

Wir lösen komplexe Probleme zu Ihrer Zufriedenheit.

überblick

Systems-Engineering ist ein Denkansatz, mit dem ich komplexe, unübersichtliche Erscheinungen veranschauliche, ohne sie unzulässig zu vereinfachen. Beziehungen zwischen den Elementen werden erkennbar. Probleme und Lösungen lassen sich leichter ermitteln:

System-Denken: Das Urproblem als Differenz zwischen Soll und Ist System-Denken: Das Urproblem als Differenz zwischen Soll und Ist

Die Fragezeichen bringen zum Ausdruck, dass Ist, Soll und der Weg vom Ist zum Soll ungewiss sein können. Für heutige Engineering-Projekte sind alle drei Fragezeichen relativ stark ausgeprägt. Es ist häufig umstritten, vage oder gar paradox, wie Probleme aufzufassen sind und wie brauchbare Lösungen aussehen, die keine unerwünschten Neben- und Fernwirkungen erzeugen.

Die Aufgabe des System-Engineerings ist diese Ungewissheiten herauszuarbeiten, der Kommunikation des Projektteams zuzuführen und ein geteiltes Verständnis der Beteiligten zu fördern.

Somit initiiert Systems-Engineering individuelle und organisationale Lernprozesse im Projekt und schafft die Basis für die wirksame Steuerung komplexer Vorhaben. Wenn Sie software-intensive Produkte in Projekten mit mehreren Teams entwickeln, dann ist das Systems-Engineering eine erfolgskritische und unverzichtbare Fachdisziplin.

projekte

System-Modell entwickeln

Wir vereinfachen komplexe System-Architekturen, und sichern dadurch Funktionalität und Qualität.

Performance und Ressourcen optimieren

Wir verbessern das Laufzeitverhalten und die Qualität Ihres Produkts.

Systemqualität wirksam verbessern

Wir setzen Qualitätsmerkmale um, die aus dem Zusammenspiel vieler Komponenten entstehen

Kern-Services

  • Qualitäts-Szenarien & technische Ziele
  • Analyse & Zielsteuerung
  • Systemstruktur & Laufzeit & Komplexität
  • Funktions-, Wirk- und Lösungsprinzipien
  • Requirements Engineering
  • Simulation, Sicherheitsanalysen, Tests
  • Performance Verbesserungen
  • Continuous Quality Tracking
  • Projektmanagement-System
  • Systemisch & Kommunikation
  • Hybrides Projekt-Management
  • Zuständigkeiten und Arbeitspakete
  • Dokumentation

projekte

1. System-Modell entwickeln

Sie wollen ein Systemmodell samt Anforderungen entwickeln? Die Varianten Ihres Systems sind nicht mehr überschaubar? Sie wollen die Komplexität des technischen Systems reduzieren?

Beim Systemdenken filtern wir zunächst Informationen, indem wir das System aus verschiedenen Sichtweisen betrachten und hierarchisch ordnen. Welche und wie viele Sichtweisen wir erzeugen, hängt von den Erscheinungen ab, die wir veranschaulichen wollen und für die wir dedizierte Lösungen brauchen. Typisch sind:

Das Bild zeigt die Sichtweisen auf System-Architektur und Software-Architektur bestehend aus Kontext-Sicht, Laufzeit-Sicht, Komponenten-Sicht und Verteilungs-Sicht
Die typischen Sichtweisen auf Architekturen
(Angelehnt an Starke, G. (2015). Effektive Software-Architekturen: Ein praktischer Leitfaden. München: Carl Hanser.)
Hiearchical system architecture with 3 layer from kontext view over system concept to basis software
Hierarchisch geordnete Sichtweisen machen komplexe Zusammenhänge verständlicher.
(Angelehnt an Haberfellner, R., Fricke, E., de Weck, O., & Vössner, S. (2012). Systems Engineering : Grundlagen und Anwendung. Zürich: Orell Füssli.)
Das Bild zeigt eine einfache funktionale Regelstruktur zur Kraftberechnung
Funktionsprinzip eines Kraftreglers
(Eigene Darstellung)
Ausschnit einer Anforderunsspezifikation für Sicherheitskonzepte
Anforderungen beschreiben die zugehörigen Architektur-Elemente
(Eigene Darstellung.)
Das Bild zeigt Sicherheitsmechanismen mit zugehörigem ASIL-Level und Verteilung auf Hardware
Verteilung der ASIL-Funktionen nach ASIL-Level auf Hardware-Komponenten
(Eigene Darstellung)
Das Bild zeigt, dass die wahrgenommene Fertigstellung nicht der tatsächlichen Fertigstellung entspricht
System-Denken löst ein sprachliches Problem für zirkuläre Zusammenhänge. Hier: Rework-Cycle.
(Angelehnt an Taylor, T., & Ford, D. N. (2006). Tipping point failure and robustness in single development projects. System Dynamics Review: The Journal of the System Dynamics Society, 22(1), 51–71.)

          

Mit dem Fokus gewinnen wir nicht nur an Klarheit; Wir erzeugen die Grundlage für weniger Missverständnisse, präzisere Kommunikation und bessere Koordination zwischen den Beteiligten.

Ziele

  • System-Architektur konsistent zum Geschäft
  • Kollektives System-Verständnis etabliert
  • Technische Funktionen umgesetzt
  • Erweiterbarkeit für zukünftige Änderungen

Indikation

  • Tagessatz* (8h): €1050,- bis €1250,-
  • Abrechnung nach Aufwand
  • Reise- und Hotelkosten nach Vereinbarung

Optionen

  • Monatliche Statusberichte
  • Ratenzahlung
  • 100% Verfügbarkeit bei Teilbeauftragungen
  • Beautragung über Engineering-Dienstleister

*zzgl. gesetzlicher MwSt.


2. Performance und Ressourcennutzung optimieren

Ihr technisches System ist zunehmend fehleranfällig? Das dynamische Verhalten Ihres Systems hat zufällig auftretende Abweichungen? Der Ressourcenverbrauch Ihres Systems ist zu hoch?

Technische Probleme sind meist Laufzeitprobleme, dynamisches Verhalten. Funktionen sind nicht nur auszuführen; sie müssen das in einer definierten Zeit und verlässlich tun. Allerdings verstecken Abstraktion und Kapselung nicht nur überfordernde Details. Sie verstecken z.B. auch Entpreller oder Zähler, die zwar die Robustheit der Komponenten steigern; das System als Ganzes aber inkonsistent machen können. Da heutige System zu umfangreich sind, ist eine vollständige Optimierung nicht machbar. Wir können nur taktisch klug vorgehen:

Taktik zur Optimierung der Ressourcennutzung von Embedded Systemen: Die SW muss Flash, HDD, ROM und CPU des Systems voll auslasten
Taktik zur Performance-Optimierung: Solange die Software die Hardware-Ressourcen nicht voll nutzt, liegen die Engpässe im Laufzeitverhalten der Software.
(Eigene Darstellung)
Signalflussanalyse für eine hierarchische System-Architektur
Qualitätsmetriken: Qualität messbar machen.
(Eigene Darstellung)
Sequence-Chart für die Optimierung einer Fault Handling Time Interval Performance
Sequenz-Diagramm für Performance-Optimierung eines Sicherheitsmechanismus
(Eigene Darstellung aus internen Projekten)
Das Bild zeigt ein Dashboard für die Verbesserung von Qualitätsmetriken über mehrere Softwarestände
Realtime Dashboard für die Verbesserung des Fault Handling Time Intervals (FHTI)
(Eigene Darstellung aus internen Projekten)
Das Bild zeigt die zeitliche Entwicklung der Qualitätsmetrik Fault Handling Time Interval über mehrere Softwarestände
Entwicklungsziele sichtbar machen: Entwicklung der Qualitätsmetrik FHTI während einer Taskforce.
(Eigene Darstellung aus internen Projekten)

         

All das dient der Kommunikation: Die Entwickler:innen setzten sorgfältig und mit guten Absichten z.B. die Entprellung um. Jetzt sagen wir ihnen, dass das die Laufzeit des Systems beeinträchtigt. Noch schwieriger wird es, wenn die eine Komponente vom OEM und die andere vom Lieferanten kommt. Können wir das technisch Sinnvollste noch sicherstellen? Wer bezahlt den Bugfix? Etc. ...

Auch hier: Unsere Architektur-Arbeit hängt untrennbar vom Verstehen, der Akzeptanz, der Kommunikation und der Koordination der Beteiligten ab. Für Problem und Lösung! Für gutes Arbeiten müssen wir den ganzen Vorgang als gemeinsamen Lernprozess gestalten.

Ziele

  • Relevante Qualitäts-Metriken ermitteln
  • System-Architektur auf die Metrik optimieren
  • Kontinuierlichen Monitoringprozess etablieren

Indikation

  • Tagessatz* (8h): €1050,- bis €1250,-
  • Abrechnung nach Aufwand
  • Reise- und Hotelkosten nach Vereinbarung

Optionen

  • Monatliche Statusberichte
  • Ratenzahlung
  • 100% Verfügbarkeit bei Teilbeauftragungen
  • Beautragung über Engineering-Dienstleister

*zzgl. gesetzlicher MwSt.


3. Systemqualität wirksam verbessern

Sie müssen die Qualität Ihres Systems steigern? Aber, wo anfangen und wo am besten ansetzen?

Es ist die Königsdisziplin des Systems-Engineerings: Systemqualitäten wie Safety, Security, Performance, Robustheit oder Benutzbarkeit entscheiden, ob Ihr Kunde Ihr Produkt liebt oder ablehnt. Und kein anderes Thema birgt so viel Sprengstoff. Systemqualitäten entstehen nicht durch einzelne Komponenten, sondern aus der Harmonie Vieler. Erfolg oder Scheitern von ganzen Engineering-Projekten hängt von Art und Weise ab, wie Sie hierbei vorgehen.

Die Komplexität technischer Systeme durch Qualitätsmerkmale laut ISO 25010
Bereits eine Handvoll von Systemqualitäten erzeugt eine unüberschaubare Komplexität in Engineering-Projekten.
(Eigene Darstellung mit Bezug auf ISO 25010:2011 System & Sofwtare Quality. Im Internet: www.iso.org )
Das Bild verdeutlich, dass Qualitätsmerkmale und Performance nur aus dem Zusammenspiel von Komponenten entstehen
Qualitätsmerkmale wie Safety, Security, Performance oder Robustheit lassen sich nur durch das Zusammenspiel von Komponenten realisieren
(Eigene Darstellung)
Signalflussanalyse für eine hierarchische System-Architektur

Nicht-steuerbare Emergenz in dynamischen Systemen: Das Ganze ist mehr als die Summme seiner Teile.
(Angelehnt an Egner, H., Ratter, B. M. W., & Dikau, R. (2008). Umwelt als System - System als Umwelt? Systemtheorien auf dem Prüfstand. München: Oekom. Im Internet auf researchgate)

    

Die Arbeit an Systemqualitäten erfordert Change Management: Entwickler:innen wissen häufig noch nicht, was zu tun ist. Viele Änderungen sind neu, komplex und hängen rekursiv mit anderen zusammen. Wir können verlässlich weder (Neben-) Wirkungen von Maßnahmen angeben, noch wie viel Zeit, Budget und Ressourcen wir benötigen. Das fordert auch dem Management einiges ab. Es ist ein Balance-Akt, der sorgfältiges Herantasten und Toleranz für Ungewissheit erfordert.

Klassisches und agiles Projekt-Management taugen hierfür nicht mehr. Beides wurde für Gewissheit entwickelt. Für Ungewissheit braucht es systemisches Change Management. Mit Ihren Entwickler:innen bilden wir ein übergreifendes Team, spüren notwendige Änderungen auf, arbeiten sie präzise aus, binden die Betroffenen proaktiv ein und setzen um. Fortschritt und Fehler arbeite ich verständlich auf und berichte sie an Team und Führung.

Ziele

  • Vision & Roadmap erarbeiten
  • Metriken für Systemqualitäten ermitteln
  • Akzeptanz der Änderungen durch Betroffene
  • Komponenten ändern bis Metriken erfüllt sind
  • Kontinuierlichen Monitoringprozess etablieren

Indikation

  • Tagessatz* (8h): €1050,- bis €1250,-
  • Abrechnung nach Aufwand
  • Reise- und Hotelkosten nach Vereinbarung

Optionen

  • Monatliche Statusberichte
  • Ratenzahlung
  • 100% Verfügbarkeit bei Teilbeauftragungen
  • Beautragung über Engineering-Dienstleister

*zzgl. gesetzlicher MwSt.


Ich bin hier, um zu helfen

FAQ - Häufig gestellte Fragen

Meine Kunden schätzen offene Worte und klare Informationen.

  • Wieso brauche ich individuelle Lernprozesse? Wir sehen die Welt durch die »Fach-Brillen«, die wir präsent haben. Wir sehen also nicht, was diese Fach-Brillen filtern. Für Neues und Innovation fehlen uns noch die Brillen. Die müssen wir erst erarbeiten. Das ist Lernen. Und individuell: Jedes Gehirn ist einzigartig ist und muss sich selbst verändern.
  • Wieso brauche ich kollektive Lernprozesse? Es geht um die Koordination von Fachspezialisten mit unterschiedlichen Fach-Brillen. Für die Zusammenarbeit müssen wir die Welt zumindest stückweise aus der Sicht der Anderen sehen, um notwendige Handlungen zu ergreifen. Das funktioniert nicht automatisch.
  • Wieso brauche ich systemisches Change Management? Lernen, Umlernen und Verlernen ist sehr schwierig, weil es ja bisher gut lief. Wir können das nicht anweisen oder steuern, da jedes Gehirn das für sich allein tun muss. Systemisches Change Management organisiert die Lernprozesse.
  • Was bedeutet »notwendige« und was »schädliche« technische Komplexität? Notwendig: Für wertigere Funktionen vernetzen wir bisher unvernetzte Komponenten. Schädlich: Wenn die System-Software-Architektur unübersichtlich und schwer verständlich ist, d.h. mangelnde Abstraktion, keine hierarchische Ordnung, fehlende Kapselung von Informationen, usw.
  • Kann ich erst Funktionen umsetzen und Qualität später? Das funktioniert nicht. Es gibt keinen Schalter, der Safety, Security, Performance, Robustheit, usw. aktiviert. Sie entstehen automatisch aus dem Zusammenspiel von Komponenten. Änderungen der Systemqualitäten erfordern deren Umbau. Das ist riskant; meist kritisch zu Projektende.
  • Kann ich Systemqualitäten unabhängig voneinander betrachten? Für den Umbau der Architektur müssen die Auswirkungen auf andere Systemqualitäten mitgedacht werden. Um die Architektur verständlich zu machen, haben sich dedizierte Sichtweisen auf Safety, auf Security, auf Performance und weitere relevante Systemqualitäten bewährt.
  • Wie hängt Systems-Engineering mit ISO 26262 und Sicherheitskonzepten zusammen? Letztlich fordert ISO 26262 kompetentes Systems-Engineering ein. Safety ist in diesem Sinne eine von vielen Sichtweisen, auf ein und dieselbe Architektur. Die ISO 26262 ist sehr spezifisch, wie bestimmte Safety-Probleme angegangen werden sollten.
  • Wie hängt Systems-Engineering mit Automotive SPICE® zusammen? Auch Automotive SPICE® fordert kompetentes Systems-Engineering ein. Der Industriestandard ordnet die Aktivitäten in Prozessgebiete und Base Practices. Er hilft aber weder bei der Lösung konkreter Probleme noch beim Umgang mit Komplexität.
  • Brauchen wir Systems-Engineering, wenn wir Agil arbeiten und keine Architektur haben? Es gibt Anwendungen, bei denen man direkt Codieren kann, ohne die Architektur im Detail zu bearbeiten. Weil die Komplexität der Anwendung überschaubar ist und weil man keine teuren physischen Werkzeuge braucht, geht das. »Re-factoring« ist nachgeholte Architektur-Arbeit.

Nächste schritte

Erzählen Sie mir von Ihrem Projekt

Wir lösen komplexe Probleme zu Ihrer Zufriedenheit.