Ein Prozessmodell und Software-Tool für modellbasierte Systementwicklung, das den gesamten Systemlebenszyklus abdeckt – von der ersten Idee bis zur Entsorgung.
Überblick
Systems Engineering als durchgängiger, nachvollziehbarer Prozess – statt verstreuter Dokumente in unterschiedlichen Werkzeugen.
RePoSyD ist zugleich Prozessmodell und Software-Werkzeug für systems-engineering-basierte Entwicklungsprozesse. Es folgt dem „Single Source of Truth"-Prinzip. So bleiben Anforderungen durchgängig bis zur konkreten Umsetzung nachverfolgbar (Traceability).
Technisch ist RePoSyD eine Single-Page-Application mit RESTful-Webservices und offenen Schnittstellen. Sie läuft wahlweise on-premise oder in der Cloud und ist für verteilte Teams an unterschiedlichen Standorten ausgelegt.
RePoSyD ist Open Source und wird kostenlos bereitgestellt. Auch die Datenformate sind offen – ein Anbieter-Lock-in durch proprietäre Formate entsteht nicht.
Konzeptdarstellung des Systemlebenszyklus, den RePoSyD durchgängig abbildet.
Grundprinzip
Objekte in RePoSyD sind nicht nur verlinkt, sondern über benannte, bidirektionale Beziehungen miteinander verbunden – jede Verknüpfung trägt eine fachliche Bedeutung.
Referenzmodell
System Design und Project Management sind im selben Modell verankert: sechs Ebenen, von der Stakeholder-Sicht bis zum Work Breakdown, konsistent miteinander verknüpft statt in getrennten Werkzeugen gepflegt.
Referenzmodell nachgezeichnet aus der RePoSyD-Präsentation: Operational-, System-Requirements- und Design-Layer bilden das System, Project-Requirements-, Management- und SOW-Layer das Projekt – durchgängig verknüpft über dieselbe Objektstruktur.
Architektur
Alle Standorte arbeiten über den Browser gegen dieselbe Datenbasis – ohne lokale Dateiablagen oder proprietäre Austauschformate.
Verteilte Teams greifen per Browser (SPA) über offene REST-Schnittstellen auf dieselbe Datenbasis zu – der RePoSyD-Server läuft wahlweise on-premise oder in der Cloud; Auswertungen entstehen automatisiert über die Report-Engine.
Prozessmodell
RePoSyD versteht Systems Engineering nicht als starren Ablauf, sondern als Werkzeugkasten: Je nach Projekttyp ist ein anderer Einstiegspunkt sinnvoll, es gibt keinen universellen ersten Schritt. Grundlage ist die pragmatische Anwendung von IEEE 1220, deren Anforderungen selektiv je nach Projekt eingesetzt werden sollen.
Der klassische Prozessablauf nach IEEE 1220: Anforderungsanalyse, Funktionsanalyse und Synthese durchlaufen jeweils Trade-Studies und Bewertungen im Rahmen der Systemanalyse. Die Steuerung überwacht den gesamten iterativen Ablauf vom Prozesseingang bis zum Prozessausgang.
Klärt, worum es im Projekt wirklich geht – Systemgrenzen, Nutzerbedarfe und Risiken werden erfasst.
Definiert die Top-Level-Funktionen des Systems aus Sicht der Nutzer.
Überführt die funktionale Architektur in eine Design-Architektur und deren Zerlegung in Systemelemente.
Bewertet Design-Alternativen mittels Trade-off-Analysen (Kosten, Risiko, Leistung) als Entscheidungsgrundlage für die anderen Prozesselemente.
Steuert Baselines, Änderungen und Entscheidungen über den gesamten Prozess hinweg – die Klammer um alle Prozesselemente.
Stellt sicher, dass alle Anforderungen bis zu Funktionen, Systemen und Komponenten rückverfolgbar sind.
Alle sechs Prozesselemente von IEEE 1220 in hochiterativer Abfolge – ohne festen Startpunkt und ohne starre Reihenfolge. Details im Original-Prozessmodell auf wiki.reposyd.de.
PLM-Backbone
Der PLM-Backbone verbindet die Systeme der Unternehmenssteuerung mit denen der Produktentwicklung. RePoSyD besetzt darin die Ebene für Requirements Engineering, Projektmanagement und Systementwurf – als durchgängige Single Source of Truth zwischen beiden Seiten.
Hinweis: Die acht Systeme stehen exemplarisch für eine typische IT-Landschaft. Je nach Bedarf lassen sich weitere Knoten ergänzen – z. B. ALM für Embedded-Software oder SCM für die Lieferkette – ohne die Grundstruktur (Steuerung links, Entwicklung rechts, RePoSyD als Kern) zu verändern.
Funktionsumfang
Requirements Engineering, Projektmanagement und Systemdesign greifen in RePoSyD ineinander, statt in getrennten Tools gepflegt zu werden.
In der Praxis
Ausschnitte aus der RePoSyD-Anwendung – von der Anforderungsübernahme bis zum automatisierten Report.
Grundlagen
Praxisbeispiel
RePoSyD erzeugt technische Diagramme automatisch aus den gepflegten Modelldaten und macht die zugrunde liegenden Objekte und ihre Verknüpfungen jederzeit einsehbar – hier demonstriert am eigenen Systemkontext.
RePoSyD Service – Systemkontext
RePoSyD Application – Stakeholder
RePoSyD – Systemstruktur
