Vorgehen
Jedes Team hat bereits seine eigene Arbeitsweise. Meine Aufgabe ist es, ihr eine gemeinsame Struktur zu geben, die das, was die Mission braucht, mit dem verbindet, was im Team entworfen und getestet wird, ohne die Arbeit auszubremsen.
Klarheit zuerst: Jedes Team sollte wissen, worauf es ankommt, warum es darauf ankommt und wie wir es nachweisen.
01 · Meine Methode
Jeder Schritt baut auf dem vorherigen auf, damit das Team den Prozess annimmt, statt dass er ihm aufgezwungen wird.
Zuerst verschaffe ich mir ein Bild davon, wie das Team heute arbeitet: welche Tools es nutzt, wo seine Daten liegen, wie Entscheidungen fallen und wo Dinge verloren gehen. Kein neuer Prozess, bevor ich den bestehenden verstanden habe.
Ein Prozess, der zur Realität des Teams passt, nicht zum Lehrbuch.
Gemeinsam mit der Leitung und den technischen Leads übersetze ich die Mission in Erfolgskriterien, Measures of Effectiveness (MoEs) und Technical Performance Measures (TPMs). Sie werden zum Bezugspunkt für jede spätere Entscheidung.
Eine gemeinsame Antwort auf die Frage: Wie sieht Erfolg aus?
Wo das Team bereits Tools im Einsatz hat, etwa Jira, Confluence oder Jama, setze ich dort an und richte sie an bewährten Systems-Engineering-Praktiken aus, statt direkt neue einzuführen. Die Struktur wächst nur so weit, wie das Team sie braucht.
Struktur ohne Reibung und ohne neues Tool, das man erst lernen muss.
Stakeholder-Bedürfnisse fließen hinunter in System-, Subsystem- und Komponentenanforderungen, und jede Anforderung ist mit der Architektur, dem Design und dem Test verknüpft, der sie verifiziert.
Die Auswirkung einer Änderung lässt sich nachverfolgen statt schätzen.
Ich lege fest, wie jede Anforderung nachgewiesen wird (Test, Analyse, Inspektion oder Review), und entwerfe die AIT-Abfolge, solange das Design noch flexibel ist, damit die Testanforderungen es mitgestalten können.
Keine Überraschungen bei der Integration; Testhardware und Prüfstände werden rechtzeitig eingeplant.
Die Teams verantworten ihre Anforderungen und Daten; ich halte sie konsistent und leicht zugänglich. Leitfäden, Coaching, Reviews und TPM-Tracking halten den Prozess lebendig, und er wächst mit der Reife des Programms.
Ein Prozess, den das Team weiter nutzt, weil er ihm hilft.
02 · Das V-Modell
Dieses Rückgrat baue ich in jedem Programm auf, entlang des V-Modells. Wählen Sie einen Schritt, um zu sehen, welche Frage er beantwortet.
Der gesamte Prozess ist iterativ: Jeder Schritt greift auf seine Nachbarn zurück, während das System reift. Integration und Tests laufen von unten nach oben, von der Komponenten- über die Subsystem- bis zur Systemebene; jede Ebene wird gegen ihr Gegenstück links verifiziert, und die Ergebnisse fließen in die TPMs und Entscheidungen zurück.
MissionWofür ist die Mission da, und was gilt als Erfolg?
MoEs & TPMsWoran misst der Kunde den Erfolg (MoEs), und nähert sich das Design diesem Ziel (TPMs)? Beide werden aus der Mission abgeleitet und laufend verfolgt, nicht erst am Ende geprüft.
Systemanforderungen & -architekturWas muss das System leisten, wie gut, wer verantwortet jede Anforderung, und wie funktioniert das System?
Die Architektur bleibt designunabhängig; Designdetails kommen auf Subsystem- und Komponentenebene hinzu. Anforderungen sind auf jeder Ebene mit Modellelementen verknüpft, sodass Lücken früh sichtbar werden; Testfälle werden aus den Szenarien abgeleitet.
Subsystem-Anforderungen & DesignWas muss jedes mechanische, Hardware- und Software-Subsystem leisten, und wie wird es ausgelegt?
KomponentenentwicklungWas braucht jede Komponente genau, um gebaut, programmiert oder beschafft zu werden?
Implementierung & FertigungHardware bauen, Software schreiben und Teile fertigen, gemäß dem Design.
Komponentenintegration & TestsErfüllt jede Komponente nach Bau und Integration ihre Anforderungen?
Subsystemintegration & TestsArbeiten die Komponenten über ihre Schnittstellen so zusammen, wie es jedes Subsystem verlangt?
Systemintegration & TestsErfüllt das integrierte System jede Systemanforderung und jeden TPM-Zielwert?
ValidierungLeistet das System, was Mission und Kunde tatsächlich brauchen?
Konfiguration & TraceabilityIst jede Anforderung, jedes Modellelement und jedes Testergebnis unter Konfigurationskontrolle und von der Mission bis zum Nachweis rückverfolgbar?
03 · Über die TRLs
Ein Forschungsteam, das die Physik erkundet, und ein Team, das Flughardware qualifiziert, brauchen vom Systems Engineering Unterschiedliches. Ich passe die Formalität an die Reife der Arbeit an, nicht umgekehrt.
Freiraum zum Experimentieren und schnellen Lernen, mit sichtbar gemachten Unbekannten.
Anforderungen einfrieren, bevor die Physik verstanden ist.
Sich auf ein Design festlegen und Zielkonflikte offenlegen.
Den kontrollierten Nachweis, dass das System jede Anforderung erfüllt.
04 · Fallbeispiele
Niedriger TRL Safran Passenger Innovations
Eine Metasurface-Antenne, die geringere Kosten, weniger Gewicht und weniger Leistungsaufnahme versprach, hatte sich am Boden bewährt, war aber nie in Richtung Luftfahrt entwickelt worden. Die Frage war, ob sie Teil eines bestehenden luftgestützten SATCOM-Produkts werden kann.
Eine klare, belegte Reifebewertung: Die Technologie war für die Luftfahrt noch nicht bereit. Die Arbeit wurde pausiert; Anforderungen, Risiken und Erkenntnisse sind dokumentiert und können wieder aufgenommen werden, sobald die Technologie reifer ist.
Ein gut begründetes „noch nicht“ ist ein gültiges Ergebnis von Systems Engineering.
Zum Projekt →
Mittlerer TRL Dcubed · laufend
Ein multidisziplinäres Team baut eine In-Space-Manufacturing-Mission, die es so noch nicht gab. Mit zunehmender Reife des Designs brauchte das Team eine klare Verbindung zwischen alltäglichen Engineering-Entscheidungen und dem, was die Mission erreichen muss.
Die Anforderungen sind jetzt auf TPMs und MoEs zurückführbar, sodass Design-Trade-offs an dem gemessen werden, was die Mission tatsächlich braucht. Die Nachverfolgung ist einfacher, und die Ingenieure nutzen SE-Methoden zunehmend in ihrer täglichen Arbeit.
Hoher TRL Safran Passenger Innovations
Ein luftgestütztes Ka/Ku-Band-SATCOM-System mit über 4.000 Anforderungen über Hardware, Software und HF, geprüft mit Kunden und externen Partnern. Um diese Reviews abzuschließen, musste für jede einzelne Anforderung gezeigt werden, wie sie verifiziert wurde. Das Softwareteam arbeitete in Jira, außerhalb der SE-Toolkette.
Die Verifikationsabdeckung wurde auf einen Blick sichtbar: Für jede Anforderung konnten Team und Kunde sehen, wie sie verifiziert wurde und was noch offen war. Reviews mit Kunden ließen sich auf Basis klarer Nachweise abschließen, und das Softwareteam konnte die Vollständigkeit seiner Arbeit bestätigen. Externe Stakeholder gaben direktes positives Feedback, das SE-Team wuchs von 3 auf 13 Personen, und das Management nahm Polarion in die Toolkette auf.
Klare Verifikationsabdeckung macht aus einem Kundenreview eine Prüfung statt einer Diskussion.
Zum Projekt →