Versuche und Ergebnisse Umstrukturiert

2026-02-19 20:16:26 +01:00
parent a5d2f5490c
commit 9b95958eeb
108 changed files with 1427 additions and 7786 deletions
--- a/Kapitel/05_prototypische_umsetzung.typ
+++ b/Kapitel/05_prototypische_umsetzung.typ
@@ -4,126 +4,174 @@
  #hide(bibliography("../literatur.bib", style: "apa"))
 ]

-#heading(level: 1)[Prototypische Umsetzung (ca. 10 Seiten)]
+#heading(level: 1)[Ergebnisse (ca. 10 Seiten)]

-Dieses Kapitel beschreibt die prototypische Umsetzung des in Kapitel 4 definierten Vorgehens. Ziel ist ein Workflow, der (1) Code- und Projektartefakte analysiert, (2) daraus strukturierte Requirements ableitet, (3) Belege und Unsicherheiten explizit erfasst und (4) die Ergebnisse so bereitstellt, dass sie in eine Migration überführt werden können. Die Umsetzung wird nicht als „vollautomatische Requirements-Generierung“ verstanden, sondern als Assistenzsystem mit klaren Kontrollpunkten.
+Dieses Kapitel dokumentiert die tatsaechlich erzeugten Ergebnisse der drei Versuche (V01-V03). Neben den Kennzahlen werden die Ergebnisartefakte aus den jeweiligen Ergebnisverzeichnissen strukturiert aufgelistet und durch exemplarische Requirements bzw. Use Cases belegt.

-#heading(level: 2)[Architektur des LLM-Agenten]
+#heading(level: 2)[Ergebnisueberblick]

-#heading(level: 3)[Architekturüberblick]
+#table(
+  columns: (1fr, 1fr, 1fr, 1fr),
+  stroke: 0.4pt,
+  [**Kennzahl**], [**V01**], [**V02**], [**V03**],
+  [Konsolidierte Anforderungen/Faehigkeiten], [277], [220], [1720],
+  [Formale Anforderungen (StRS+SyRS+SwRS)], [277], [220], [0],
+  [Explizite Use Cases], [0], [46], [1720],
+  [Undokumentierte Use Cases], [n.v.], [n.v.], [1211],
+  [ISO-29148-Compliance], [qualitativ A+], [96,1%], [n.v.],
+  [Traceability], [100% laut Doku], [100% bidirektional], [n.v.],
+  [Ergebnisdateien gesamt], [11], [37], [30]
+)

-Der Prototyp folgt einer Pipeline-Architektur, die Analyse, Retrieval und Generierung entkoppelt. Damit wird die Komplexität kontrollierbar und einzelne Komponenten können iterativ verbessert werden. Der Agent ist in vier Schichten gegliedert:
+#heading(level: 2)[V01 Ergebnisse (Baseline)]

-1. **Ingestion-Schicht:** Sammeln und Vorverarbeiten von Artefakten.
-2. **Retrieval-Schicht:** Auswahl relevanter Kontexte (RAG) zur Skalierung über große Repositories.
-3. **Reasoning-/Generation-Schicht:** LLM-gestützte Ableitung und Strukturierung der Requirements.
-4. **Traceability- und Output-Schicht:** Persistenz, Belege, Review-Export.
+#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 01/Ergebnisse`]

-Retrieval-Augmented Generation ist in dieser Architektur das zentrale Prinzip, um mit begrenzten Kontextfenstern umzugehen und Aussagen an konkrete Belege zu binden @lewis2020rag.
+- `Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.md`
+- `Versuche/Versuch 01/Ergebnisse/Centron_Software_Requirements_Specification.pdf`
+- `Versuche/Versuch 01/Ergebnisse/complete-iso29148-requirements-specification.md`
+- `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`
+- `Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.md`
+- `Versuche/Versuch 01/Ergebnisse/iso29148-integrated-requirements-analysis.pdf`
+- `Versuche/Versuch 01/Ergebnisse/nhibernate-orm-analysis.md`
+- `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md`
+- `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.pdf`
+- `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md`
+- `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.pdf`

-#heading(level: 3)[Ingestion: Artefaktaufbereitung und Chunking]
+#heading(level: 3)[Beispielhafte Requirements aus den Ergebnisdateien]

-Die Ingestion-Schicht übernimmt:
+```text
+StR-001: Comprehensive Customer Account Management
+Statement: The system shall provide comprehensive customer account management capabilities...
+(Quelle: ISO29148_Complete_Requirements_Specification.md)
+```

- Erfassung von Quellcode, Konfigurationen, UI-Strings, SQL-Artefakten und Projektdokumenten,
- Normalisierung von Encodings und Metadaten (Pfad, Modul, Änderungsdatum),
- Segmentierung in semantische Einheiten (z. B. Klasse/Methode, SQL-Statement, Konfigblock),
- Ablage in einem Index, der später Retrieval ermöglicht.
+```text
+FR-001: User Authentication System
+Requirement: The system shall provide secure user authentication...
+(Quelle: system/SyRS_Complete_Detailed.md)
+```

-Die Segmentierung verfolgt ein Ziel: Kontext soll klein genug sein, um präzise zu sein, aber groß genug, um Regeln nicht aus dem Zusammenhang zu reißen. Für Legacy-Code bedeutet dies typischerweise, dass neben einer Regelstelle auch angrenzende Strukturen (z. B. Statusenum, Datenobjektdefinition) berücksichtigt werden müssen.
+#heading(level: 2)[V02 Ergebnisse (ISO-Konsolidierung mit Agenten)]

-#heading(level: 3)[Retrieval: Kontextauswahl und Ranking]
+#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 02/Ergenisse`]

-Retrieval ist als zweistufiges Verfahren umgesetzt:
+- `Versuche/Versuch 02/Ergenisse/COMPLETE_REQUIREMENTS_SPECIFICATION.md`
+- `Versuche/Versuch 02/Ergenisse/COMPLETE_REQUIREMENTS_SPECIFICATION.pdf`
+- `Versuche/Versuch 02/Ergenisse/README.md`
+- `Versuche/Versuch 02/Ergenisse/TABLE_FORMATTING_STATUS.md`
+- `Versuche/Versuch 02/Ergenisse/.execution_state/baseline_metrics.json`
+- `Versuche/Versuch 02/Ergenisse/.execution_state/directory_setup.txt`
+- `Versuche/Versuch 02/Ergenisse/.execution_state/milestone_state.json`
+- `Versuche/Versuch 02/Ergenisse/.execution_state/project_structure.json`
+- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Executive_Summary.md`
+- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Master_Requirements.md`
+- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Quality_Report.md`
+- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Traceability_Master.csv`
+- `Versuche/Versuch 02/Ergenisse/master/ISO29148_Validation_Checklist.md`
+- `Versuche/Versuch 02/Ergenisse/software/Analysis_Complete.md`
+- `Versuche/Versuch 02/Ergenisse/software/Business_Rules.md`
+- `Versuche/Versuch 02/Ergenisse/software/Integration_Patterns.md`
+- `Versuche/Versuch 02/Ergenisse/software/Pattern_Catalog.csv`
+- `Versuche/Versuch 02/Ergenisse/software/Performance_Patterns.md`
+- `Versuche/Versuch 02/Ergenisse/software/Security_Patterns.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_Algorithms.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_CodeCatalog.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_DataModel.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_TestSpecification.md`
+- `Versuche/Versuch 02/Ergenisse/software/SwRS_Traceability.csv`
+- `Versuche/Versuch 02/Ergenisse/software/Validation_Rules.md`
+- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Complete.md`
+- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Diagrams.md`
+- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Evidence.md`
+- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Summary.md`
+- `Versuche/Versuch 02/Ergenisse/stakeholder/StRS_Traceability.csv`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_API_Specification.yaml`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_Architecture.md`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_Interfaces.md`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_Summary.md`
+- `Versuche/Versuch 02/Ergenisse/system/SyRS_Traceability.csv`

-1. **Kandidatensuche:** Identifier, Domänenterminologie, Datenobjekte, UI-Labels und Query-Fragmente erzeugen eine erste Trefferliste.
-2. **Ranking und Kontextbündelung:** Treffer werden nach Nähe zum Untersuchungsziel (z. B. „Fakturierung“, „Berechtigung“) sortiert und als Kontextpakete zusammengeführt.
+#heading(level: 3)[Beispielhafte Requirements aus den Ergebnisdateien]

-Damit wird vermieden, dass LLMs ohne ausreichende Belege „auffüllen“. Gleichzeitig bleibt das System flexibel: Neue Untersuchungsfragen können durch andere Retrieval-Queries adressiert werden, ohne dass die gesamte Pipeline angepasst werden muss.
+```text
+SyR-001: The system SHALL implement a multi-layered architecture with clear separation of concerns.
+(Quelle: Ergenisse/system/SyRS_Complete.md)
+```

-#heading(level: 3)[Requirements-Extraktion und Traceability-Datenmodell]
+```text
+SyR-013: The system SHALL provide secure user authentication with multi-factor authentication support.
+(Quelle: Ergenisse/system/SyRS_Complete.md)
+```

-Die Generation-Schicht erzeugt Requirements nicht als Freitext, sondern als strukturierte Einträge. Ein Eintrag umfasst mindestens:
+```text
+SW-ARCH-001: The software SHALL implement a 6-layer architecture pattern.
+(Quelle: Ergenisse/software/SwRS_Complete.md)
+```

- **Requirement-Text** (präzise, testbar),
- **Akzeptanzkriterien** (Prüfidee, Mess- oder Beobachtbarkeit),
- **Belege** (Dateipfade, Funktionen, SQL-Statements, UI-Strings),
- **Unsicherheit** (Markierung fehlender Evidenz oder konkurrierender Interpretationen),
- **Tags** (Domänenbereich, Datenobjekte, Risiko).
+#heading(level: 2)[V03 Ergebnisse (Discovery-Erweiterung mit Agenten und MCP)]

-Traceability ist dabei ein zentrales Designkriterium. Die Literatur beschreibt Traceability als Voraussetzung, um Anforderungen über Lebenszyklen hinweg zu begründen und zu pflegen @gotel1994traceability @ramesh2001traceability. Für den Prototyp bedeutet dies: Der Agent darf Requirements nicht „aus dem Nichts“ formulieren, sondern muss die Verbindung zu den Artefakten als Primäroutput liefern.
+#heading(level: 3)[Ergebnisdateien in `Versuche/Versuch 03/ERP_DOCUMENTATION`]

-#heading(level: 2)[Toolchain-Integration]
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/ANALYSIS_SUMMARY.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR_MIT_DB_MAPPING.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/BUSINESS_GLOSSAR.pdf`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/COMPLETE_DATABASE_SCHEMA.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/DOCUMENTATION_INDEX.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/EXPORT_COMPLETE_SCHEMA.sql`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/README_USE_CASE_ANALYSIS.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/README.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_ANALYSIS_SUMMARY.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_MAPPING_COMPLETE.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/SCREENSHOT_PROJECT_INDEX.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/SSMS_DB_SCHEMA.sql`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_REST_API.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_WORKFLOWS.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASE_ANALYSIS_README.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASE_MAPPING.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS_DE.pdf`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.pdf`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_CONTROLLERS.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_GUI_MAPPING.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_IMPLEMENTATION_GUIDE.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW_XAML_TEMPLATES.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_NEW.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`
+- `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.pdf`

-#heading(level: 3)[Integration in Repository und Entwicklungsworkflow]
+#heading(level: 3)[Beispielhafte Use Cases aus den Ergebnisdateien]

-Die Toolchain-Integration zielt darauf, Analyseergebnisse in vorhandene Arbeitsabläufe zu integrieren. Dazu gehören:
+```text
+1.1.1 Personalized User Welcome
+Purpose: Display personalized greeting with user name and context-aware dashboard content.
+(Quelle: ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md)
+```

- **Repository-Integration:** Analyse auf einem definierten Stand (Commit/Tag), um Reproduzierbarkeit sicherzustellen.
- **Versionierung von Prompts und Konfigurationen:** Prompt-Templates, Retrieval-Parameter und Modellversionen werden dokumentiert, damit Ergebnisse nachvollziehbar bleiben.
- **Ergebnisablage:** Requirements werden in einem Format abgelegt, das Reviews ermöglicht (z. B. Markdown, Tabellenexport) und später in Tickets oder Spezifikationen überführt werden kann.
+```text
+1.1.6 Work Status Alerts
+Purpose: Alert users to missing or incomplete work time entries.
+(Quelle: ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md)
+```

-Reproduzierbarkeit ist in diesem Kontext nicht nur ein wissenschaftliches Kriterium, sondern eine praktische Voraussetzung: Ohne klare Zuordnung zu einem Code-Stand entsteht bei späteren Änderungen ein nicht auflösbarer Interpretationskonflikt.
+```text
+Key Finding: 1,720+ use cases discovered; current documentation gap: 71%.
+(Quelle: ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md)
+```

-#heading(level: 3)[Einbindung in Wissens- und Ticket-Systeme]
+#heading(level: 2)[Ergebnisfazit]

-In Modernisierungsvorhaben sind Ticketsysteme und Wissensbasen zentrale Koordinationspunkte. Der Prototyp ist so konzipiert, dass Requirements:
+Die Ergebnislage zeigt drei komplementaere Stufen:

- als Backlog-Einträge überführt werden können,
- mit Belegen verlinkt sind (Pfad + Stelle),
- Review-Kommentare aufnehmen können,
- als konsolidierte Spezifikation exportierbar bleiben.
+- **V01** liefert eine belastbare formale Baseline.
+- **V02** liefert die staerkste ISO-29148-konforme Konsolidierung mit hoher Traceability.
+- **V03** liefert die groesste funktionale Breite und identifiziert den groessten Dokumentations-Gap.

-Die Integration ist bewusst „leichtgewichtig“ gehalten: Ziel ist nicht, ein neues Requirements-Tool zu ersetzen, sondern die Lücke der fehlenden Legacy-Spezifikation zu schließen und die Migration mit belegbaren Requirements zu stabilisieren.
-
-#heading(level: 3)[Logging, Nachvollziehbarkeit und Qualitätsmetriken]
-
-Da LLMs nicht deterministisch sind, wird Logging als Qualitätsinstrument verstanden. Pro Analysezyklus werden mindestens gespeichert:
-
- Scope-Definition,
- verwendete Artefaktlisten und Retrieval-Treffer,
- Promptversion und Modellparameter,
- Rohoutput des Modells,
- konsolidierter Requirement-Eintrag und Review-Status.
-
-Diese Daten erlauben es, Fehlerquellen zu identifizieren (z. B. falscher Kontext, widersprüchliche Belege) und den Prozess iterativ zu verbessern. Gleichzeitig muss Logging gegen Datenschutz- und IP-Risiken abgewogen werden (siehe 5.3).
-
-#heading(level: 2)[Governance, Datenschutz und IP]
-
-#heading(level: 3)[Risiko- und Maßnahmenmodell]
-
-Der Einsatz von LLMs im Kontext von Quellcode berührt Governance-Fragen. In der Literatur wird betont, dass große Sprachmodelle systemische Risiken wie Bias, Fehlverhalten und fehlende Transparenz aufweisen können @bender2021stochastic. Für die Fallstudie sind insbesondere folgende Risikoklassen relevant:
-
- **Falschaussagen/Halluzinationen:** plausibel klingende, aber unbelegte Requirements @ji2023hallucination.
- **Datenabfluss:** unbeabsichtigte Preisgabe von Quellcode oder Betriebsinformationen.
- **IP- und Lizenzrisiken:** unklare Rechte bei Weiterverarbeitung, Speicherung oder externem Modellbetrieb.
- **Compliance:** Anforderungen aus Datenschutz oder Sicherheit, die in der Zielplattform nachweisbar erfüllt werden müssen.
-
-Das Maßnahmenmodell kombiniert technische, organisatorische und prozessuale Kontrollen:
-
- Belegpflicht und Review,
- Minimierung des Kontexts (Need-to-know),
- Zugriffskontrollen auf Indizes und Logs,
- Trennung von sensiblen Artefakten (z. B. Secrets) aus dem Analyseumfang.
-
-#heading(level: 3)[Datenschutzorientierte Konfiguration und Datenminimierung]
-
-Datenschutzanforderungen werden im Prototyp durch Datenminimierung operationalisiert. Praktisch bedeutet dies:
-
- Keine Analyse von Artefakten, die Zugangsdaten oder personenbezogene Inhalte enthalten.
- Begrenzte Promptkontexte: nur die für die Fragestellung relevanten Codeausschnitte.
- Reduzierte Speicherung: Prompt-Logs werden, wenn erforderlich, nur mit Hashes/Metadaten gespeichert, nicht als vollständige Inhalte.
-
-Für den praktischen Einsatz ist zudem zu klären, ob Modelle lokal (On-Premise) oder als Cloud-Service betrieben werden. Diese Arbeit bewertet den Prototyp so, dass beide Betriebsformen abbildbar bleiben. Die konkrete Wahl ist eine Governance-Entscheidung, die von Schutzbedarf, Kosten und Betriebsaufwand abhängt.
-
-#heading(level: 3)[IP, Verantwortlichkeit und Human-in-the-loop]
-
-Der Prototyp ist so gestaltet, dass fachliche Verantwortung nicht an das Modell delegiert wird. LLMs liefern Vorschläge, Strukturierung und Zusammenfassungen, aber keine autoritativen Spezifikationsentscheidungen. Diese Trennung ist notwendig, weil die Qualität der Ergebnisse von Kontext, Prompt und Modellverhalten abhängt und sich ohne Review nicht verlässlich absichern lässt.
-
-Für Requirements-Artefakte gelten daher folgende Prinzipien:
-
- **LLM-Output ist ein Zwischenartefakt:** erst Review und Konsolidierung erzeugen „gültige“ Requirements.
- **Verantwortung liegt beim Projektteam:** insbesondere für Abnahmen und Architekturentscheidungen.
- **Transparenz durch Belege:** damit Entscheidungen nachvollziehbar bleiben und in der Migration überprüfbar sind.
-
-Damit ist die prototypische Umsetzung nicht als Ersatz für Requirements Engineering zu verstehen, sondern als skalierbares Werkzeug, das fehlende Legacy-Dokumentation durch belegbare, reviewbare Artefakte ergänzt.
+Damit liegt eine vollstaendige empirische Grundlage fuer die anschliessende Evaluation (Kapitel 6) vor: formal-strukturierte Requirements (V01/V02) plus breite Discovery-Evidenz (V03).