Wat is het verschil tussen een systems engineering plan en een V-model?

Ein Systemtechnikplan und das V-Modell sind zwei grundlegend unterschiedliche Dinge: Der Systems Engineering Plan (SEP) ist ein Managementdokument, das beschreibt Wie Systemtechnik innerhalb eines Projekts wird ausgeführt, während das V-Modell eine Prozessgrafik ist, die die logische Reihenfolge von Entwicklung und Verifizierung visualisiert. Das SEP ist das Was und wie, das V-Modell ist das wann und in welcher Reihenfolge. In diesem Artikel beantworten wir die am häufigsten gestellten Fragen zu beiden Konzepten und zeigen, wie sie sich in der Praxis ergänzen.

Was beschreibt ein System-Engineering-Plan genau?

Ein Systems-Engineering-Plan ist ein projektspezifisches Managementdokument, das festlegt, wie Systems Engineering innerhalb eines bestimmten Projekts oder Programms angewendet wird. Es beschreibt den Ansatz, die Rollen, die Verantwortlichkeiten, die zu verwendenden Methoden und die Werkzeuge, die das Projektteam zur Verwaltung von Anforderungen, zur Strukturierung des Designs und zur Durchführung der Verifizierung einsetzt.

Konkret enthält ein SEP normalerweise die folgenden Elemente:

Der Umfang und die Ziele der Systementwicklungsaktivitäten
Die angewandte Methodik und die Frameworks, wie INCOSE oder die Leitlinie SE
Die Rollen und Verantwortlichkeiten innerhalb des Teams
Der Arbeitsablauf für Anforderungsmanagement und Rückverfolgbarkeit
Der Ansatz für Verifizierung und Validierung
Die Werkzeuge und Systeme, die eingesetzt werden
Die Verknüpfung mit Projektplanung und Meilensteinen

Das SEP ist somit kein theoretisches Modell, sondern ein lebendiges Dokument, das während des Projekts auf dem neuesten Stand gehalten wird. Es ist die Verbindung zwischen der Unternehmensstrategie und der täglichen Ausführung von System-Engineering-Aktivitäten. Ohne ein SEP fehlt die gemeinsame Grundlage, auf der ein Team seine Arbeit abstimmen kann, was in der Praxis zu inkonsistenten Vorgehensweisen und einem Verlust der Rückverfolgbarkeit führt.

Was beschreibt das V-Modell genau?

Das V-Modell ist ein Prozessmodell, das den Entwicklungszyklus eines Systems als V-Form darstellt. Die linke Seite des V beschreibt den Abbau von Systemanforderungen zu Untersystemen und Komponenten, die rechte Seite beschreibt die dazugehörigen Verifikations- und Validierungsschritte, die in umgekehrter Reihenfolge durchgeführt werden. Jede Ebene auf der linken Seite hat einen direkt entsprechenden Testschritt auf der rechten Seite.

Die Stärke des V-Modells liegt in der expliziten Verknüpfung von Spezifikation und Verifizierung. In dem Moment, in dem Sie eine Anforderung auf Systemebene definieren, legen Sie gleichzeitig fest, wie Sie diese Anforderung später verifizieren werden. Dies verhindert die klassische Falle, bei der Verifikationskriterien erst am Ende eines Projekts erdacht werden, wenn Änderungen teuer und zeitaufwendig sind.

Das V-Modell ist breit anwendbar und wird in der niederländischen Praxis häufig im Bauwesen, im maritimen Sektor und im öffentlichen Sektor eingesetzt. Es bietet eine erkennbare Struktur, die Projektteams, Auftraggeber und Auditoren gemeinsam verstehen können, unabhängig vom spezifischen Projektinhalt.

Was ist der grundlegende Unterschied zwischen beiden?

Der grundlegende Unterschied ist, dass das V-Modell ein Universelles Prozessmodell ist ein Systems Engineering Plan eine projektspezifisches Verwaltungsdokument. Das V-Modell beschreibt die logische Reihenfolge von Aktivitäten, die in praktisch jedem Systems-Engineering-Projekt wiederkehren. Das SEP beschreibt, wie Ihr Team in Ihrem Projekt diese Aktivitäten konkret ausführt.

Eine nützliche Analogie: Das V-Modell ist die Straßenkarte des Prozesses, das SEP ist der Reiseplan des Teams. Die Straßenkarte ist für alle gleich, aber jedes Team erstellt seinen eigenen Plan auf der Grundlage, wer mitreist, welche Ressourcen zur Verfügung stehen und welche Umstände gelten.

Daraus ergibt sich auch ein praktischer Unterschied in der Anwendung:

Das V-Modell benutzt man, um den Prozess zu strukturieren und mit allen Beteiligten zu kommunizieren
Das SEP wird verwendet, um Vereinbarungen festzuhalten, Verantwortlichkeiten zuzuweisen und Arbeitsweisen zu sichern.
Das V-Modell ändert sich kaum pro Projekt; das SEP ist immer projektspezifisch
Das V-Modell ist ein visuelles Werkzeug; das SEP ist ein formelles Dokument.

Kan een SEP en das V-Modell zusammen benutzt werden?

Ja, und in der Praxis sollten sie zusammen verwendet werden. Ein guter Systems-Engineering-Plan verweist ausdrücklich auf das V-Modell als angewandtes Prozessmodell und beschreibt dann, wie die Projektorganisation die Schritte dieses Modells konkret ausfüllt. Das V-Modell gibt die Struktur, das SEP gibt die Ausarbeitung.

In der Praxis funktioniert dies wie folgt: Das SEP beschreibt beispielsweise, dass die Verifizierung durch Inspektionen, Analysen und Tests erfolgt, und legt fest, wer dafür verantwortlich ist und zu welchem Zeitpunkt im Projekt. Das V-Modell macht sichtbar, auf welcher Ebene in der Systemhierarchie dieser Verifizierungsschritt angesiedelt ist. Zusammen bilden sie ein schlüssiges Ganzes, das sowohl die Methode als auch die Ausführung abdeckt.

Es ist ein häufiger Fehler, das V-Modell als Ersatz für ein SEP zu betrachten. Organisationen, die nur das V-Modell anwenden, ohne ein entsprechendes SEP, verfügen über eine Prozessstruktur, ihnen fehlen jedoch die projektspezifischen Vereinbarungen, die notwendig sind, damit diese Struktur tatsächlich funktioniert.

Wann genügt das V-Modell und wann benötigen Sie eine SEP?

Das V-Modell reicht als Kommunikationsmittel in frühen Projektphasen oder bei einfachen Projekten, bei denen die Vorgehensweise bereits allgemein bekannt und geteilt ist. Sobald ein Projekt mehrere Parteien, komplexe Anforderungsstrukturen oder formale Übertragungsverpflichtungen hat, ist ein vollständig ausgearbeiteter Systems-Engineering-Plan unerlässlich.

Ein paar Richtlinien für die Praxis:

V-Modell ausreichend interne Projekte mit einem kleinen, erfahrenen Team, das die gleiche Arbeitsweise teilt und bei dem keine formelle Rechenschaftspflicht gegenüber einem Auftraggeber erforderlich ist
SEP notwendig: Projekte mit mehreren Vertragsparteien, Projekte, bei denen ein Auftraggeber die nachweisbare Anwendung von Systems Engineering fordert, oder Projekte, bei denen die Wissensvermittlung am Ende eine formelle Verpflichtung darstellt
SEP dringend empfohlen: Projekte, bei denen sich die Anforderungsstruktur regelmäßig ändert, bei denen die Rückverfolgbarkeit von der Anforderung bis zum Beweis später auditiert wird oder bei denen neue Teammitglieder schnell eingearbeitet werden müssen

In der niederländischen Infrastruktur- und Wasserwirtschaft ist ein SEP bei größeren Projekten praktisch immer eine vertragliche Verpflichtung. Auch im maritimen Sektor und im öffentlichen Sektor wird zunehmend ein nachweisbarer Systems-Engineering-Ansatz gefordert, wobei die SEP der zentrale Nachweis dafür ist, dass dieser Ansatz tatsächlich eingerichtet ist.

Welche Werkzeuge unterstützen ein SEP und das V-Modell in der Praxis?

Die am häufigsten verwendeten Werkzeuge für das System-Engineering sind spezialisierte Plattformen für Anforderungsmanagement, Modellierung und Rückverfolgbarkeit. In der Praxis stoßen Teams jedoch oft auf teure oder komplexe Werkzeuge wie IBM DOORS oder Cameo Systems Modeler, die nicht immer mit dem Umfang oder dem Budget des Projekts übereinstimmen.

Ein SEP stellt Anforderungen an das von einem Team gewählte Werkzeug: Die Werkzeuge müssen Rückverfolgbarkeit unterstützen, die Zusammenarbeit erleichtern und zur Verifizierungsstruktur passen, die das V-Modell vorschreibt. Das bedeutet in der Praxis, dass man eine Umgebung benötigt, in der Anforderungen definiert, mit Entwurfselementen verknüpft und Verifizierungsnachweise registriert werden können.

Met Datastorms bieden wij een no-code informatieplatform waarmee systems engineers precies dit kunnen doen: eisen definiëren, traceability vastleggen, verificatiematrices genereren en de samenhang tussen systemen en deelsystemen bewaken gedurende de hele projectlevenscyclus. Het platform is gebouwd vanuit jarenlange praktijkervaring in de Nederlandse infra-, water- en maakindustrie, sluit aan op bestaande werkwijzen en integreert via een uitgebreide API met tools die al in gebruik zijn. Zo ondersteunt het zowel de uitvoering van het SEP als de verificatiestructuur van het V-model, zonder de complexiteit of de kosten van traditionele MBSE-tooling. Wil je zelf ervaren hoe het platform werkt? Vraag een proeflicentie aan en ontdek wat Datastorms voor jouw project kan betekenen.

Häufig gestellte Fragen

Wie fange ich an, einen System-Engineering-Plan zu erstellen, wenn ich keine Erfahrung damit habe?

Ein guter Ausgangspunkt ist die Konsultation bestehender Rahmenwerke wie dem INCOSE Systems Engineering Handbook oder der Nederlandse Leidraad SE, die beide Vorlagen und Richtlinien für die Einrichtung eines SEP bieten. Beginnen Sie mit den Kernkomponenten: Geltungsbereich, Rollen und Verantwortlichkeiten sowie der Vorgehensweise für Anforderungsmanagement und Verifizierung. Ergänzen Sie das Dokument schrittweise, während das Projekt fortschreitet – ein SEP muss nicht auf einmal vollständig sein, sollte aber von Anfang an aktuell gehalten werden.

Was sind die häufigsten Fehler bei der Anwendung des V-Modells in der Praxis?

Der am häufigsten gemachte Fehler ist die Behandlung des V-Modells als einen strengen Wasserfall: Teams durchlaufen die linke Seite vollständig, bevor sie über die rechte Seite nachdenken, während die Verifizierungskriterien gerade gleichzeitig mit den Anforderungen definiert werden müssen. Ein weiterer häufiger Fehler ist die Anwendung des V-Modells auf nur eine Systemebene, während das Modell dazu gedacht ist, die vollständige Hierarchie vom System bis zur Komponente zu strukturieren. Stellen Sie daher sicher, dass jede Anforderungsebene einen entsprechenden Verifizierungsschritt hat, noch bevor das Design beginnt.

Wie detailliert muss ein SEP für ein mittelgroßes Projekt sein?

Een SEP voor een middelgroot project hoeft niet omvangrijk te zijn, maar moet wel volledig zijn op de punten die voor dat project kritiek zijn: duidelijke rollen, een beschreven aanpak voor traceability en een vastgelegde verificatiestrategie. Een document van tien tot twintig pagina’s is voor de meeste middelgrote projecten voldoende, mits het concreet en projectspecifiek is in plaats van generiek en theoretisch. Vermijd de valkuil van een te uitgebreid SEP dat vervolgens niet wordt onderhouden — een beknopt maar levend document heeft meer waarde dan een uitgebreid document dat na de kick-off in de la verdwijnt.

Kann ich das V-Modell mit agilen oder iterativen Arbeitsmethoden kombinieren?

Ja, het V-model en agile werkwijzen sluiten elkaar niet uit, mits je het V-model toepast op het juiste abstractieniveau. Op systeemniveau biedt het V-model de overkoepelende verificatiestructuur, terwijl op component- of softwareniveau iteratieve sprints kunnen worden toegepast. In de praktijk wordt dit vaak aangeduid als ‘V-model in het groot, agile in het klein’, waarbij het SEP beschrijft hoe beide werkwijzen binnen het project op elkaar worden afgestemd en waar de formele verificatiemomenten liggen.

Wer ist für die Verwaltung und Aktualisierung des SEP während eines Projekts verantwortlich?

Die Verantwortung für das SEP liegt in der Regel beim Systemingenieur oder dem leitenden Systemingenieur des Projekts, aber das Dokument ist eine gemeinsame Verantwortung des gesamten Projektteams. In der Praxis ist es ratsam, im SEP selbst festzulegen, wer das Dokument verwaltet, zu welchen Zeitpunkten es überarbeitet wird – beispielsweise bei Meilensteinen oder bei wesentlichen Umfangsänderungen – und wie Änderungen an alle Beteiligten kommuniziert werden. Ohne einen benannten Eigentümer und einen klaren Überarbeitungsprozess veraltet ein SEP schnell und verliert seine Wertigkeit als Leitdokument.

Wie stelle ich eine gute Rückverfolgbarkeit zwischen Anforderungen, Design und Verifizierung sicher, ohne in der Bürokratie zu ertrinken?

Der Schlüssel liegt darin, die Rückverfolgbarkeit von Anfang an als einen strukturierten Prozess einzurichten, nicht als eine nachträgliche Aktivität. Verwenden Sie ein Werkzeug oder eine Plattform, die die Rückverfolgbarkeit automatisch anhand der Verknüpfungen verfolgt, die Sie zwischen Anforderungen, Designelementen und Verifizierungsnachweisen herstellen, damit Sie keine separate Dokumentation führen müssen. Stellen Sie außerdem sicher, dass das SEP den erforderlichen Grad der Rückverfolgbarkeit beschreibt – nicht jede Anforderung erfordert die gleiche Tiefe – und verwenden Sie ein konsistentes Format für die Anforderungsidentifizierung, damit die Verknüpfungen während des gesamten Projektlebenszyklus eindeutig und nachvollziehbar bleiben.

Was ist der Unterschied zwischen Verifizierung und Validierung im V-Modell und warum ist diese Unterscheidung wichtig?

Verificatie beantwoordt de vraag ‘hebben we het systeem goed gebouwd?’ — met andere woorden: voldoet het systeem aan de gespecificeerde eisen? Validatie beantwoordt de vraag ‘hebben we het goede systeem gebouwd?’ — voldoet het systeem aan de werkelijke behoefte van de gebruiker of opdrachtgever? In het V-model vindt verificatie plaats op elk niveau van de hiërarchie, terwijl validatie plaatsvindt op het hoogste niveau, aan het einde van de rechterzijde van de V. Het onderscheid is cruciaal omdat een systeem technisch correct kan voldoen aan alle eisen, maar toch niet aansluiten bij wat de opdrachtgever daadwerkelijk nodig heeft — een risico dat alleen door expliciete validatie wordt ondervangen.

Was ist der Unterschied zwischen einem System-Engineering-Plan und einem V-Modell?