gitea-pages/docs/IF_Projekte/Testlandschaft/Projektmanagement/Planen/Prozess---Versionen.md

Prozess - Versionen

Created: 2025-10-27 09:01:31 +0100

Modified: 2025-11-14 14:13:39 +0100

---

Fragen:

• Wie wiederverwendbar ist es?
• Wie viel Sinn und Zweck hat es?
• Wie viele verschiedene einzelne Prozesse hat das Projekt?
• Entkoppelt?
• Genug Traffic damit ein Lernende (Plattformentwickler) dran arbeiten kann?

Hauptprozess Testlandschaft:

• Start → Sensor/API: Reproduzierbare Daten werden automatisch geholt.
• Validierungsprozess: Daten werden automatisch geprüft.
• Transmit: Gültige Daten werden weitergeleitet.
• Logging: Alle Daten (auch ungültige) werden protokolliert.
• Fehleranalyse/Review: Ungültige Daten können überprüft werden, z. B. mit Diagrammen, um Debugging und Fehlererkennung zu üben.

Alles läuftautomatisch, Lernende greifen nur bei derFehleranalyseein.

Version - 1:

In diesem Fall werden Fake-Daten erzeugt. Für den ersten Projekt Aufbau wird eine API automatisch reproduzierbare Fake-Daten generieren.

Schritt 1:

API	Erzeugt automatisch reproduzierbare Fake-Daten.
Datenformat	JSONoder CSV (leicht für Validierung und Loggen)
Daten-Art	Ganzzahlen /Int-Werte Lineare Gleichungen (y = mx + b) Zeitreihen (z.B. Sensormessung prosek.) Fehlerhafte Daten (Ausreisser)
Ziel	Eine API erzeugt automatisiert reproduzierbare Testdaten. Sie simuliert Sensorwerte oder externe API-Responses inklusiv möglicher Fehlerfälle stellt diese Daten über eine Endpunkt bereit, um den Validierungsprozess zu triggern.

Schritt 2:

Validierungsprozess	Automatisiert
Ziel	Nimmt die vom API gelieferten Daten entgegen. Prüft automatisch Gültigkeit und Konsistenz der Daten. Kann Fehler oderUnstimmigkeit erkennen. Gibt ein Validierungs-Status oder Fehlerliste aus (z.B. Falsches Format, Werte aussenhalb erlaubter Bereiche). Gibt ein Validierungs-Status oder ein Fehlerliste aus, die später im Logging oder Review verwendet wird.
Technische – Ziele	Formatprüfung Bereichsprüfung / Grenzen Konsistenzprüfung Ausreisererkennung Logging

Schritt3:

Transmit
Ziel	Nimmt die validierten Daten vom Validierungsprozess. Sendet sie an den nächsten Prozess oder ein Zielsystem (z.B. Dashboards/Analyse,Datenbank) Kann Übertragungsarten nutzen: Übertragung von Fehlerdaten
Übertragungsarten	API-Call Messaging-Queue (Sender und Empfänger) Datei Export

Schritt 4:

Logging	Log-Daten
Ablauf	1) Nimmt alle Daten vom Transmit-Schritt entgegen (gültig + ungültige). 2) Speichert sie in strukturierter Form 3) Protokoliert zusätzlich Metadaten: Zeitstempel, Quelle, Validierungsstatus, Error-Message 4) Macht die Daten für Review/Debugging verfügbar
Log-Struktur	Zeitstempel – Wann wurde der Datensatz erzeugt. Datenquelle – Sensor/API Rohdaten Validierungsstatus Error-Message

Schritt 5:

Fehleranalyse /Review	User-GUI
Ziel	Nimmt die Logs aus Schritt 4 als Input Filter die ungültigen Daten Stellt sie übersichtlich dar Lernende können Fehler erkennen und nachvollziehen, ohne dass sie die Validierung selbst ausführen müssen.