Auf der Suche nach einem Entwicklertool für einen Fragebogen

[broucker]

Frage an die Crowd:
Hat jemand von euch bereits Erfahrung mit der Implementierung komplexer Frauenlogik in vergleichbaren Systemen? Wie könnte man dieses Problem effizient lösen, ohne dass das Projekt aus dem Ruder läuft? Jede Idee oder bewährte Methode, die dazu beitragen könnte, diese Herausforderung zu meistern, wäre sehr willkommen. Vielen Dank im Voraus für eure Unterstützung!

Ausgangslage:
Wir betreiben ein umfangreiches Rechtsregister (Basis SQL Server und Client auf Delphi), das zahlreiche Gesetze und Pflichten erfasst. Kunden können bei uns einen Fragebogen ausfüllen, und auf Basis ihrer Antworten wird ein maßgeschneidertes Rechtsregister für den Kunden erstellt. Derzeit arbeiten wir an der Digitalisierung dieses Fragebogens. Ziel ist es, jede Frage im Fragebogen direkt mit den entsprechenden Gesetzes-IDs zu verknüpfen, sodass den Kunden sofort die passenden Gesetze angezeigt werden, sobald sie eine Frage beantwortet haben.

Problembeschreibung:
Ein zentrales Problem, das wir identifiziert haben, besteht darin, dass manche Gesetze mit mehreren Fragen verknüpft sind. Wir haben etwa 1100 Fragen, und die Implementierung einer umfassenden Logik zwischen diesen Fragen würde das Projekt extrem groß und zeitaufwendig machen.
Wir haben jedoch erkannt, dass das System wesentlich effektiver und benutzerfreundlicher wäre, wenn wir eine Logik zur Abfrage mehrerer Bedingungen einbauen könnten. Diese Logik würde es ermöglichen, komplexe Zusammenhänge zwischen den Fragen zu berücksichtigen und die passenden Gesetze präziser zuzuweisen.
Das Hauptproblem ist also die Komplexität und der Umfang der Logik, die erforderlich ist, um eine solche mehrbedingungsbasierte Zuordnung zu realisieren, ohne das Projekt unverhältnismäßig zu vergrößern und zu verzögern.

Jede Anwort ist hilfreich
LG Christian

[Christian Marquardt]

Da es überhaupt nichts mit IDEs zu tun hat->verschoben

Was genau ist "Frauenlogik"?
Was ist genau das Problem, was sich daraus ergibt?
Warum sollte da irgendein Projekt aus dem Ruder laufen?
Was ist genau die Herausforderung?

Delphi ist tot.
Ziel ist es, jede Frage im Fragebogen direkt mit den entsprechenden Gesetzes-IDs zu verknüpfen -> das dürfte doch kein Problem sein
dass manche Gesetze mit mehreren Fragen verknüpft sind. Wir haben etwa 1100 Fragen -> eine winzige Datenmenge sollte jede DB mit einer m:n zwischen Gesetz und Frage hinbekommen
wenn wir eine Logik zur Abfrage mehrerer Bedingungen einbauen könnten -> kann man bestimmt im Programm, per SQL

[Ralf Jansen]

Kann auch kaum folgen.

Was ich verstanden zu glauben habe. Ihr habt 1000 Fragen und 1000 Gesetzte (oder wieviel auch immer) und ihr müßt jetzt diese n-zu-n Beziehung irgendwie darstellen. Und ihr sucht jetzt eine Logik die du Beziehung irgendwie automatisch hinbekommt?
Weil diese Beziehungen zu haben ist das einzige Problem das ich sehe.

Wenn ihr das schon habt scheint was zu tun irgendwie eindeutig. N-zu-n Beziehung sind irgendwie ziemlich normales Handwerkzeug einer relationalen Datenbank.
Naiv ohne Details zu kennen. Eine Tabelle Fragen, eine Tabelle Gesetze, eine Tabelle dazwischen die die Beziehung aufnimmt (Frage zu Gesetz) und Voila man hat eine n-zu-n Beziehung.

Solange unklar ist was genau "komplexe Zusammenhänge" und "mehrbedingungsbasierte Zuordnung" bedeutet kann man kaum helfen. Was ist den da komplex und wo kommen jetzt Bedingungen her (jenseits einer Beziehung zwischen Frage und Gesetz)?

[broucker]

Hi, Danke für die Antworten, es müsste natürlich Fragelogik heißen - habe ich nicht gesehen beim "Drüberlesen"...

Mit der "Beschreibung" die wohl zu ungenau war, wollten wir eher darauf abzielen jemanden zu finden, der vl. eine ähnliche Problematik hatte (Detailreicher Fragebogen) und mit WAS (Tool, Oberfläche, Software...) man sowas umsetzen könnte.


Mit "komplexe Zusammenhänge" war gemeint, dass sich die Fragen wie wir sie bekommen haben etwas unstrukturiert daherkommen: Frage 1,2,3 sind Ja/Nein Frage 4 sind 3 Antwortmöglichkeiten wobei z.Bsp. eine dieser Antworten wiederum
eine Frage DAVOR beeinflussen kann.

Aber ich werde hier nochmal versuchen das besser zu beschreiben - Danke Euch auf jeden Fall fürs Beantworten und Eure Zeit

[broucker]

Unser spezifisches Problem geht jedoch darüber hinaus. Die Komplexität entsteht durch mehrere Bedingungen, die dynamisch bei der Zuordnung berücksichtigt werden müssen. Diese Bedingungen können sich aus verschiedenen Faktoren ergeben, wie z.B. Kombinationen von Antworten auf mehrere Fragen, zeitliche Aspekte, oder spezifische Geschäftsregeln, die sich ändern können.

Hier ein konkretes Beispiel zur Verdeutlichung: Stell dir vor, ein Kunde muss eine Serie von Fragen zu verschiedenen Szenarien beantworten. Abhängig von der Kombination der Antworten können bestimmte Gesetze relevant werden, während andere ausgeschlossen werden. Diese Logik ist nicht statisch und erfordert eine dynamische Evaluierung, was die Implementierung komplex macht.

Wir suchen daher nach einer Methode oder bewährten Praktiken, um diese vielschichtigen Bedingungen effizient und skalierbar in das System zu integrieren, ohne dass das Projekt aus dem Ruder läuft. (Sehr kleines Entwicklerteam)

Konkret: Gibt es vorgefertigte Tools, die wir übersehen haben mit denen wir möglichst wenig selbst ausprogrammieren müssen?

[Christian Marquardt]

Kann da keine Komplexität erkennen.
Man baut einen Frageablauf auf, bestehend aus u.a. Standardvorgänger, Frage, Antworttypen, Antworten, Standardnachfolger.

Der Ablauf enthält zu den Fragen die Typen (Checkbox, Radio, Textfeld). Danach wird die Frage an der Oberfläche zusammengebaut.
Wird eine Antwort eingegeben, wird diese validiert. Ist sie ok, wird der gesamt Frageablauf neu validiert. Ggf. können zu anderen Fragen andere Nachfolger bestimmt werden, Fragen übersprungen oder ggf. nochmals angezeigt werden.

Ja, und irgendjemand muss die Validierung programmieren. Das ist allerdings kein großes Problem. Für moderne Sprachen gibt es Wizards mit denen man das implementieren kann, denke für Delphi nicht mehr

Vorgefertigte Tools werden bei diesen Anforderungen wohl im 5-stelligen Bereich liegen

[Ralf Jansen]

Du hast also einen Baum (oder mehrere?) von Fragen? Und jede mögliche Antwort führt wieder zu genau einer Folgefrage? Und das wiederholt sich bis man eine Wurzel erreicht hat?
Können sich Fragen wiederholen? Also an anderer Stelle in diesem Baum stehen? Wenn ja kann man das umgehen in dem man einfach eine weitere identisch aussehende Frage erfindet? So das zumindest der Identifikator der Frage unterschiedlich ist?
Und Antwort in diesem Baum heißt neben der Folgefrage noch das Gesetzte zu eine Ergebnisliste Liste hinzugefügt bzw. wieder entfernt werden?

Du siehst ich habe leider immer noch mehr Fragen als antworten

Gefühlt musst du in deinen Satz von Fragen und Antworten diese möglichst eindeutig machen wenn die es noch nicht sind damit dein Entscheidungsbaum nicht zu einem Netz entartet das wäre wirklich kompliziert.

Die Zuordnung Antworten zu Gesetzen kann man bestimmt einfach in einer Relation ablegen.
Die Zuordnung Frage zu Antworten und Antworten zu Folgefragen auch. Hier brauch man noch keine wirklichen Baum nur eindeutige Ids.

Den Entscheidungsbaum selbst sehe ich nicht in einer relationalen Struktur. Solche Strukturen die zur Rekursion neigen sind eher ungeeignet um sie auf Tabellen zu mappen und diese dann auch noch sinnvoll,einfach,verstehbar bearbeitbar zu machen.

Ich würde es so machen.
Von eine Applikation ausgehend die diesen Entscheidungsbaum pflegen soll (eine andere als der Eingangs genannte Client) würde ich dort eine Klassenmodel erstellen mit Fragen, Antworten, Gesetzen so wie nötig (primär die Struktur der Ids den Rest kann man sich ja wenn nötig aus der DB hinzuholen) und das in eine besser geeignetes Format serialisieren (Json,Xml,Yaml etc. möglicherweis gibt es da auch was spezielles)
Diese Entscheidungsbaum-Konfiguration wie ich sie jetzt nenne kann man dann ja ruhig wieder in eine Zelle einer Datenbank Tabelle speichern. Simple Key-Value Struktur. Sowas wie Id, Version, Konfiguration(das komplette serialisierte Format)).
Wenn sich neue Fragen,Antworten,Gesetzte dazugesellen würde ich empfehlen die alten Daten in den obige genannten Mappingtabellen nicht zu ändern sondern neue zu erfinden. Heißte neue Frage<->Antworten, Antworten<->Folgefragen, Antworten<->Gesetzte Tabelleneinträge. Gefühlt ist es ein Risiko die vorhandenen zu ändern. Ich stelle mit vor das die Versionierung hier nötig ist. Wenn du alte Einträge änderst machst du alte Konfigurationen kaput. Dein neues Konfigurationtool sollte also also die letzte Konfiguration kopieren dann Knoten in deinem Baum hinzufügen oder entfernen aber keinen vorhandenen einfach nur editieren und als neue Version speichern.

Damit kann sich dann der eigentliche Client die gesamte Konfiguration (die letzte oder wenn nötig irgendeine vorherige) abholen und verwenden und wenn nötig auch noch cachen.

Das eigentliche Problem das überführen eurer Rohdaten in ein geeignetes Format wird aufwendig bleiben (nicht komplex aber aufwendig). Insbesondere das sicherstellen das das was man da überführt hat auch korrekt ist. Mir würde gerade keine bessere QA Strategie einfallen als stumpf alle Wege auszuprobieren auch wenn dieser Entscheidungsbaum 1000 Wurzeln hat. Das wäre aber bei einem fertigen Tool das man dazu kaufen könnte nicht anders. Dieser Aufwand lässt sich kaum durch Toolunterstützung verringern. In Zukunft vielleicht durch eine AI im Moment würde ich denen aber nicht trauen.