Nachvollziehbarer Referenzprototyp
Excel 365 mit standardisierten Arbeitsblättern, zentraler Konfiguration und automatisierten Testläufen über Instrumente und Oszillatoren.
TECHNOLOGIE
Die Technik soll die Fachlogik prüfbar machen – nicht verdecken.
Der heutige Forschungsstand ist in einem nachvollziehbaren Excel-Prototyp dokumentiert. Version 2 soll die fachlichen Regeln in eine testbare Softwarearchitektur überführen. Dabei ist nicht der Name einer Programmiersprache das Produktmerkmal, sondern die Fähigkeit, Berechnungen unabhängig zu reproduzieren, Daten sauber zu verwalten und Änderungen kontrolliert zu versionieren.
GRUNDPRINZIP
Von einem transparenten Forschungsprototyp zu einer belastbaren Softwarekette
Excel ist im heutigen Stand kein Makel, sondern die dokumentierte Referenz, in der Berechnungen und Testwege zellengenau nachvollzogen werden können. Der nächste Schritt besteht darin, diese Logik unabhängig neu zu implementieren und automatisch gegen den Referenzstand zu prüfen. Erst wenn beide Rechenwege unter identischen Daten und Regeln übereinstimmen, ist die Portierung fachlich belastbar.
Unabhängige Reimplementierung
Der gleiche Rechenweg wird in einem testbaren Softwarekern nachgebildet. Abweichungen werden nicht „wegkalibriert“, sondern einzeln erklärt und behoben.
Modulare Produktarchitektur
Datenhaltung, Rechenkern, Tests, Oberfläche, API, Reporting und Dokumentation werden als getrennte, klar beschriebene Schichten aufgebaut.
ZIELARCHITEKTUR
Sechs technische Aufgaben statt eines einzigen großen Programms
Die konkrete Werkzeugwahl kann sich im Entwicklungsprozess ändern. Entscheidend sind die Funktionen, die jede Schicht zuverlässig erfüllen muss.
Datenhaltung
Historische Tages- und Intraday-Daten, Metadaten, Datenherkunft, Qualitätsmerkmale und Teststände werden strukturiert gespeichert.
Rechenkern
Decision Core, Filter und Ausführungsregeln werden als klar abgegrenzte, automatisiert testbare Funktionen umgesetzt.
Testumgebung
Reproduktion, Regressionstests, Kontrollgruppen, Belastungstests und spätere Vorwärtsprüfungen werden wiederholbar automatisiert.
Benutzeroberfläche
Konfiguration, Teststeuerung, Analyse und Hilfetexte sollen ohne Eingriff in den Rechenkern bedienbar sein.
Schnittstellen
API-fähige Modulgrenzen sollen Daten, Ergebnisse oder Risikozustände an vorhandene institutionelle Infrastruktur übergeben können.
Nachweis & Betrieb
Versionen, Testprotokolle, Fehler, Warnungen, Datenherkunft und technische Dokumentation werden dauerhaft mitgeführt.
REPRODUZIERBARKEIT
Die erste technische Aufgabe ist nicht „mehr Funktionen“, sondern derselbe Rechenweg.
Eine Neuimplementierung ist erst dann vertrauenswürdig, wenn sie den vorhandenen Referenzstand mit identischen Daten und Parametern reproduziert. Das verhindert, dass beim Übergang in eine neue Technologie unbemerkt Regeln verändert oder Ergebnisse anders interpretiert werden.
Dieses Verfahren schafft außerdem eine belastbare Basis für spätere Erweiterungen: Neue Stops, Kostenmodelle oder APS-Funktionen können erst dann sinnvoll bewertet werden, wenn klar ist, dass der unveränderte Ausgangszustand korrekt nachgebildet wurde.
1Referenzdaten und Regeln einfrieren
↓
2unabhängig neu implementieren
↓
3Ergebnisse automatisiert vergleichen
↓
4jede Abweichung erklären
↓
5erst danach neue Funktionen ergänzen
KI-ASSISTENZ
KI kann erklären und unterstützen – sie soll den Kern nicht autonom verändern.
Im Zielbild kann künstliche Intelligenz insbesondere bei der Suche in Dokumentation, beim Erklären von Ergebnissen, bei Qualitätsprüfungen, der Entwicklerunterstützung oder einer späteren Benutzerhilfe eingesetzt werden. Die fachlichen Kernregeln bleiben jedoch versioniert und kontrolliert.
Damit wird KI nicht zum undurchsichtigen Entscheider. Eine Markt- oder Risikoregel muss weiterhin fachlich beschrieben, getestet und freigegeben werden können.
KI-Transparenz auf dieser Website →Sinnvolle KI-Aufgaben
- Dokumentation durchsuchen und erklären
- Testberichte zusammenfassen
- Plausibilitäts- und Qualitätsprüfungen unterstützen
- Entwicklung und Fehlersuche beschleunigen
Nicht vorgesehen
- unbeaufsichtigte Änderung der Kernregeln
- Blackbox-Entscheidungen ohne nachvollziehbare Ursache
- automatische Performanceversprechen
- Ersetzung der fachlichen Freigabe
TECHNOLOGIEWAHL
Python, PostgreSQL und eine Weboberfläche sind Arbeitsrichtungen – keine Glaubenssätze.
Für Version 2 ist derzeit ein Python-basierter Rechenkern mit relationaler Datenhaltung, Analyseoberfläche und API-fähigen Grenzen vorgesehen. Diese Werkzeuge passen zu Reproduzierbarkeit, Testautomatisierung und späterer Integration. Sie sind aber nicht als unveränderliche Käuferanforderung festgeschrieben. Wenn ein institutioneller Partner andere Betriebs-, Sicherheits- oder Infrastrukturvorgaben hat, muss die Architektur diese Anforderungen berücksichtigen können.
Die Fachlogik hat Vorrang vor dem Werkzeug: Die technische Plattform darf austauschbar sein. Nicht austauschbar sind die fachlichen Definitionen, Daten- und Testregeln sowie die Anforderung, Ergebnisse nachvollziehbar reproduzieren zu können.
WEITER