[Semester 4] Woche 2 - RMMM

[Moritz-Czekalski]

RMMM Tabelle

Category	Risk ID	Risk Description	Probability 1 - 5	Impact 1 - 5	Risk Score	Mitigation Strategy	Indicator	Contingency Plan	Responsible Status	Last modified date
Plannung	Pla1	Nicht alle Anforderungen wurden korrekt analysiert	1	3	3	Sorgfältige Anforderungsanalyse mit mehreren Perspektiven	Lastenheft nicht erfüllt	Kontinuierliche Reevaluation und Anpassung der Anforderungen	Simon Just	28.05.2026
Technik	Tec1	Zentraler Programmteil kann nicht umgesetzt werden	1	5	5	- Die Umsetzbarkeit im Vorhinein analysieren - Verschiedene technische Lösungsansätze betrachten	Entwickler meldet Problem bei der Implementierung	- Andere Technologien verwenden -	Mohid Syed	28.05.2026
	Tec2	Zu hoher Performanceverlust bei komplexen Schaltungen	3	3	9	- Einsatz von Web Workern - Effiziente Datenstrukturen - Incremental Updates	- FPS - Latenz - CPU Auslastung	- Simulation vereinfachen - Chunking - Warnung an Nutzer	Florian Blum	02.05.2026
	Tec3	Browserkompatibilität: Eine verwendete Technologie funktioniert auf einigen Browsern nicht	1	3	3	- Nutzung etablierter Standards - Auf Kompatibilität der verwendeten Technologien achten - Testen in verschiedenen Browsern	Test im Browser schlägt fehl	- verwendete Technologien wechseln - Einschränkung auf unterstützte Browser - Fallback-Modi	Moritz Czekalski	28.05.2026

Größtes technisches Risiko: Performance der Simulation (Tec2)

Was ist das Risiko?

BitFlow ermöglicht die Simulation digitaler Schaltungen direkt im Browser.
Mit steigender Anzahl an Bausteinen und Verbindungen wächst jedoch die Komplexität der Berechnungen stark an.

Die Simulation berechnet Signalzustände und Änderungen durch das gesamte Netzwerk von Komponenten und Verbindungen.
Wenn diese Berechnungen ineffizient sind oder zu häufig ausgeführt werden, kann es zu Verzögerungen im UI kommen.

---

Warum ist es das größte Risiko?

Hohe Systembelastung:
Komplexe Schaltungen führen zu vielen Berechnungen in kurzer Zeit.

Direkter Einfluss auf Usability:
Wenn die Simulation langsam ist, wirkt die gesamte Anwendung unresponsive.

Echtzeitanforderung:
Die Simulation soll in Echtzeit reagieren.

Skalierungsproblem:
Was bei kleinen Schaltungen funktioniert, kann bei größeren Projekten schnell an Grenzen stoßen.

---

Mitigation Strategy

• Einsatz von Web Workern, um die Simulation vom UI-Thread zu trennen
• Verwendung von eventgetriebener Simulation (nur Änderungen berechnen)
• Nutzung effizienter Datenstrukturen für Komponenten und Verbindungen

---

Indicator

Das Risiko wird sichtbar durch:

• Verzögerte Reaktion auf Benutzerinteraktionen
• Hohe CPU-Auslastung im Browser
• Spürbare Latenz bei Signaländerungen

---

Contingency Plan

Falls die Performance nicht ausreicht:

• Vereinfachung der Simulation (z. B. weniger Detailtiefe)
• Verarbeitung in kleineren Einheiten (Chunking)
• Einschränkung der maximalen Schaltungsgröße
• Anzeige von Warnungen für Nutzer bei zu komplexen Schaltungen

---

Projektfortschritt

Seit dem letzten Semester lag unser Fokus hauptsächlich auf der T2000-Arbeit im Rahmen der Praxisphase, wodurch wir an BitFlow nur eingeschränkt weiterarbeiten konnten.
Mit Beginn des 4. Semesters nehmen wir die Entwicklung jedoch wieder aktiv auf.

Für die aktuelle Phase haben wir uns vorgenommen, die grundlegende Funktionalität der Simulation weiter auszubauen.
Im Fokus steht insbesondere die Implementierung von Ein- und Ausgängen sowie die Möglichkeit, erste einfache Schaltungen zu erstellen, die stabil und zuverlässig funktionieren.

Damit legen wir die Basis für die weitere Entwicklung des Systems und können in den kommenden Wochen darauf aufbauend komplexere Features und Optimierungen umsetzen.

[tinow04]

Cooler Ansatz mit den Web Workern und der eventgetriebenen Simulation, das sollte einiges an Performance retten. Eure Risikoanalyse ist super nachvollziehbar. Das Zeitproblem wegen der T2000 fühlen wir zu 100%.

[ultra-ms]

Gute RMMM Tabelle. Ich finde es toll, wie ihr die Kriterien praxisnah formuliert habt.

Zu Tec2: Ihr habt Performance Kriterien, aber keine präzisen Kennzahlen. Wie messt ihr die Werte genau? Und ab wann würdet ihr z.B. eine vereinfachte Simulation einschalten? Unter 30 FPS auf dem Bildschirm, 30Hz Simulationsgeschwindigkeit oder über 100 ms Maus-/Interaktions-Latenz?

Schön, dass es nach der Praxisphase jetzt wieder losgeht, das mit der T2000-Arbeit ist voll nachvollziehbar.
Viel Erfolg beim Neustart!

(Gruppe Hexfields-Studio)

[Moritz-Czekalski]

Danke für dein Feedback und deine Frage!

Der Performanceverlust wird anhand der, in den Anforderungen festgehaltenen Kriterien gemessen. Aber du hast Recht, das hätten wir klarer aufzeigen können!

[Dupl0s]

Ich finde eure RMMM Tabelle sehr gut nachvollziehbar. Probleme wurden genannt und direkt mit einer plausiblen Lösung hinterlegt.
Das Zeitproblem mit dem T2000 fühlen wir aber auch sehr.