Versuche und Ergebnisse Umstrukturiert

Kapitel/06_evaluation.typ

@@ -6,81 +6,119 @@
 
 #heading(level: 1)[Evaluation (ca. 12 Seiten)]
 
-Dieses Kapitel evaluiert die prototypische Durchführung des in Kapitel 4 beschriebenen Vorgehensmodells und die in Kapitel 5 skizzierte Toolchain-Umsetzung. Als Datenbasis dienen die im Ordner `Ergebnisse` abgelegten Artefakte (Requirements-Spezifikationen nach ISO/IEC/IEEE 29148, Use-Case-Dokumentation, UI↔Code-Mappings, Datenbankschema-Exports und Glossare). Der Fokus liegt auf der Frage, inwieweit die erzeugten Artefakte (1) strukturierte, prüfbare Requirements liefern, (2) Traceability ermöglichen und (3) den Analyseaufwand gegenüber rein manueller Rekonstruktion reduzieren.
+Die Evaluation folgt der in Kapitel 4 beschriebenen Iterationslogik und bewertet die drei real durchgefuehrten Versuche (V01-V03) vergleichend. Ziel ist nicht die Darstellung eines einzelnen "besten" Laufs, sondern die Einordnung der methodischen Entwicklung von einer Baseline ueber eine formale ISO-Konsolidierung bis zur anschliessenden Discovery-Erweiterung.
 
-#heading(level: 2)[Evaluationskriterien und Messgrößen]
+#heading(level: 2)[Evaluationsdesign und Datenbasis]
 
-Die Evaluationskriterien orientieren sich an den im Exposé definierten Messgrößen und an etablierten Qualitätsmerkmalen im Requirements Engineering @iso29148_2018 @ieee830_1998. Für KI-gestützte Extraktion wird zusätzlich berücksichtigt, dass plausible Textausgaben ohne Belegpflicht fachlich falsch sein können @ji2023hallucination @bender2021stochastic.
+Die Auswertung basiert ausschliesslich auf den erzeugten Artefakten in:
 
-Für die Arbeit werden die folgenden Kriterien operationalisiert:
+- `Versuche/Versuch 01/Versuch01.md` und `Versuche/Versuch 01/Requirements.md`,
+- `Versuche/Versuch 02/Versuch02.md` und `Versuche/Versuch 02/Requirements.md`,
+- `Versuche/Versuch 03/Versuch03.md` und `Versuche/Versuch 03/Requirements.md`.
 
-- **Vollständigkeit (relativ zum Scope):** Anteil der dokumentierten Requirements/Use Cases bezogen auf einen definierten Untersuchungsumfang (Module/Prozesse). Vollständigkeit wird in dieser Arbeit nicht als globale Eigenschaft der gesamten Legacy-Software verstanden, sondern als scopebezogene Abdeckung (z. B. pro Modulgruppe). Die Literatur weist darauf hin, dass Vollständigkeit durch Assistenzsysteme verbessert werden kann, aber nur in Verbindung mit Validierung und klarer Abgrenzung @luitel2024completeness.
-- **Verständlichkeit und Prüfbarkeit:** Requirements gelten als prüfbar, wenn Akzeptanzkriterien bzw. Verifikationsansätze aus dem Text ableitbar sind. Als Indikator wird die formale Struktur nach ISO/IEC/IEEE 29148 genutzt (Soll-Formulierung, Begründung, Kriterien, Verifikation) @iso29148_2018.
-- **Redundanzfreiheit und Konsistenz:** Identifikation doppelter oder widersprüchlicher Requirements. In der prototypischen Auswertung wird dies primär über Strukturprüfungen und Stichproben erfolgen; eine vollständige Duplikaterkennung erfordert zusätzliche, dedizierte Analyseschritte.
-- **Traceability (Nachvollziehbarkeit):** Anteil der Requirements, die explizite Belege auf Artefakte enthalten (Datei-/Pfadverweise, Klassen, Methoden, SQL-Objekte, UI-Elemente). Traceability ist eine zentrale Voraussetzung für belastbare Weiterentwicklung und Evaluation @gotel1994traceability @ramesh2001traceability.
-- **Stakeholder-Alignment:** Übereinstimmung der Ergebnisse mit Fachwissen und Prioritäten. Operationalisiert wird dies durch Review-Sessions (Bewertung, Korrekturen, Ergänzungen) und die Kennzeichnung offener Punkte.
-- **Aufwandsreduktion:** Zeitbedarf der KI-gestützten Rekonstruktion im Vergleich zu einer manuellen Erstellung für den gleichen Scope. Da reale manuelle Baselines stark von Team- und Artefaktlage abhängen, werden in der Pilotphase gemessene Toolchain-Zeiten und dokumentierte Aufwandsschätzungen als Vergleichsanker genutzt.
+Dabei wurden nur konsolidierte, in den Dateien ausgewiesene Kennzahlen uebernommen. Fokus der Bewertung:
 
-#heading(level: 2)[Durchführung und Ergebnisse]
+1. Umfang der rekonstruierten Faehigkeiten/Requirements,
+2. Formalisierungsgrad (StRS/SyRS/SwRS vs. reine Use-Case-Discovery),
+3. Traceability- und ISO-29148-Naehe,
+4. methodischer Nutzen der eingesetzten Tooling-Konfiguration.
 
-#heading(level: 3)[Untersuchungsgegenstand und Datenbasis]
+#heading(level: 2)[Quantitative Ergebnisse der Versuchsreihe]
 
-Die prototypische Durchführung basiert auf einer artefaktzentrierten Analyse der Legacy-Software und angrenzender Quellen. In den Ergebnisartefakten wird die Systemgröße unter anderem über folgende Kenngrößen beschrieben:
+#table(
+  columns: (1fr, 1fr, 1fr, 1fr),
+  stroke: 0.4pt,
+  [**Kennzahl**], [**V01**], [**V02**], [**V03**],
+  [Konsolidierte Requirements/Faehigkeiten], [277], [220], [1720],
+  [Formale Requirements (StRS+SyRS+SwRS)], [277], [220], [0],
+  [StRS / SyRS / SwRS], [35 / 75 / 167], [84 / 53 / 83], [0 / 0 / 0],
+  [Explizite Use Cases], [0], [46], [1720 (Use-Case-fokussiert)],
+  [Undokumentierte Use Cases], [n.v.], [n.v.], [1211],
+  [ISO-29148-Compliance], [qualitativ A+], [96,1% (100% mandatory)], [n.v.],
+  [Traceability], [100% laut Doku], [100% bidirektional], [n.v.],
+  [Ergebnisdateien gesamt], [11], [37], [30]
+)
 
-- 34 Projekte und 849 Business-Logic-Klassen,
-- 956 NHibernate-Mappings,
-- 2.145 REST-Endpunkte,
-- 135 WPF-Module (UI-Kontext).
+Ergaenzende Kontextkennzahlen aus den Versuchsdateien:
 
-Diese Größenordnungen sind für die Evaluation relevant, weil sie den Kontextdruck auf Kontextfenster und Retrieval (RAG) erklären und die Notwendigkeit strukturierter Traceability unterstreichen @lewis2020rag.
+- V01: Analyse von 34 C\#-Projekten und 12.507+ Source Files.
+- V02: 14.940 Dateien (13.717 C\#, 1.189 XAML, 34 Projekte), 46 explizite Use Cases in die formale Requirements-Struktur integriert.
+- V03: 150.000+ LoC analysiert, 3.412 potenzielle Use Cases identifiziert, 71% dokumentationsbezogener Gap (1211 von 1720 Use Cases vormals undokumentiert).
 
-#heading(level: 3)[Ablauf der prototypischen Auswertung]
+#heading(level: 2)[Vergleichende Analyse]
 
-Die Durchführung folgt der Logik aus Kapitel 4 (Scope → Artefaktpipeline → Extraktion → Traceability → Review). Für die prototypische Auswertung wurden die folgenden Artefaktgruppen erzeugt:
+#heading(level: 3)[Versuch 01: Formale Baseline ohne Tooling-Erweiterung]
 
-- **Requirements-Spezifikationen nach ISO/IEC/IEEE 29148:** Stakeholder-, System- und Software-Ebene mit Statement/Begründung/Verifikation und Belegangaben.
-- **Use-Case-Dokumentation und Mapping:** Umfangreiche Modul- und Use-Case-Sammlungen, ergänzt um UI↔Code-Zuordnungen (WPF-Pfade, ViewModels, Controller, Rechtekonstanten).
-- **Domänen- und Datenartefakte:** Business-Glossar sowie Datenbankschema-Exports zur Begriffs- und Datenmodellstabilisierung.
-- **UI-basierte Discovery-Artefakte:** Screenshot-Mappings und Session-Reports für Teilbereiche der webbasierten Oberfläche (CentronNexus/ServiceBoard).
+V01 zeigt, dass bereits ohne Agenten/MCP eine formal strukturierte Requirements-Spezifikation erzeugt werden kann. Die Staerke liegt in der klaren Dreiebenenstruktur (StRS/SyRS/SwRS). Die Schwaeche ist die begrenzte Discovery-Perspektive: explizite Use-Case-Rekonstruktion und Gap-Bewertung bleiben gering ausgepraegt.
 
-Für die Bewertung werden die Artefakte strukturell geprüft (Vorhandensein der geforderten Felder), Kennzahlen aus den Dokumenten extrahiert und zentrale Aussagen stichprobenartig gegen die angegebenen Belege gespiegelt.
+#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V01)]
 
-#heading(level: 3)[Quantitative Ergebnisse]
+- **Verwendeter Prompt:** "Please analyze this software project and write a reuqirements specification according to modern standards."
+- **Agentenbeispiele:** Keine Agenten (bewusste Baseline ohne agentische Zerlegung und ohne MCP).
+- **Beispielhafte Ergebnis-Requirements:**
+  - `Versuche/Versuch 01/Ergebnisse/ISO29148_Complete_Requirements_Specification.md`: u. a. `StR-001` (Comprehensive Customer Account Management).
+  - `Versuche/Versuch 01/Ergebnisse/system/SyRS_Complete_Detailed.md`: u. a. `FR-001` (User Authentication System) und `FR-002` (Role-Based Access Control).
+  - `Versuche/Versuch 01/Ergebnisse/software/SwRS_Complete_Detailed.md`: softwareseitige Architektur- und Umsetzungsanforderungen im SwRS-Format.
 
-Die in `Ergebnisse` abgelegten Spezifikationen berichten insgesamt 277 dokumentierte Requirements (35 Stakeholder-, 75 System- und 167 Software-Requirements). In den detaillierten Artefakten liegen die folgenden, direkt prüfbaren Strukturindikatoren vor:
+#heading(level: 3)[Versuch 02: ISO-orientierte Konsolidierung mit Agenten]
 
-- **Stakeholder Requirements (StRS):** 35 Statements mit jeweils Akzeptanzkriterien, Source-Evidence und Verifikationsmethode.
-- **System Requirements (SyRS):** 75 Statements mit Source-Evidence und Verifikationsmethode; Akzeptanzkriterien sind teilweise nicht einheitlich als eigenes Feld ausgewiesen.
-- **Software Requirements (SwRS, detaillierter Ausschnitt):** 120 Requirements mit „Requirement Statement“, Akzeptanzkriterien, Source-Evidence und Verifikationsmethode.
+V02 fokussiert die formale Konsolidierung und liefert eine ISO-29148-nahe Zielstruktur mit hoher Traceability. Mit 220 konsolidierten Requirements, 96,1% ISO-29148-Compliance und 100% bidirektionaler Traceability ist der Lauf methodisch sauber und reviewfaehig. Gleichzeitig zeigte sich die zentrale Grenze dieses Schritts: Die reine ISO-orientierte Ableitung war fuer den Gesamtumfang zu rigide und fuer die Discovery-Breite nicht vollumfaenglich genug.
 
-Für die Use-Case- und Mapping-Ebene werden folgende Umfangs- und Abdeckungszahlen berichtet:
+#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V02)]
 
-- 103 dokumentierte Module (inkl. Submodule) mit 509 Use Cases über 15 Hauptkategorien.
-- Mapping-Status in der Zusammenfassung: ca. 92% vollständig gemappt, ca. 6% teilweise gemappt, ca. 2% mit Klärungsbedarf.
+- **Verwendeter Prompt:** "Please analyze this software project and write a ISO 29148 compliant reuqirements specification. Use Agents wherever possible."
+- **Agentenbeispiele:**
+  - `Versuche/Versuch 02/Tools/agents/iso29148-master-orchestrator-agent.md`
+  - `Versuche/Versuch 02/Tools/agents/iso29148-stakeholder-agent.md`
+  - `Versuche/Versuch 02/Tools/agents/iso29148-system-requirements-agent.md`
+  - `Versuche/Versuch 02/Tools/agents/iso29148-software-requirements-agent`
+- **Beispielhafte Ergebnis-Requirements:**
+  - `Versuche/Versuch 02/Ergenisse/system/SyRS_Complete.md`: u. a. `SyR-001` (Multi-Layer Architecture), `SyR-002` (Dual Data Access Pattern), `SyR-013` (Authentication).
+  - `Versuche/Versuch 02/Ergenisse/software/SwRS_Complete.md`: u. a. `SW-ARCH-001` (6-Layer Architecture), `SW-ARCH-002` (ILogic-Pattern), `SW-FUNC-001` (Account Management).
+  - `Versuche/Versuch 02/Ergenisse/master/ISO29148_Quality_Report.md`: qualitaetssichernde Gesamtbewertung (u. a. 100% Traceability).
 
-Für die UI-basierte Discovery (CentronNexus) wird ein erster, bewusst begrenzter Scope dokumentiert:
+#heading(level: 3)[Versuch 03: Discovery-Erweiterung mit Agenten und MCP]
 
-- 7 erfasste Module bei einem geplanten Umfang von 34 Modulen (20,6% Abdeckung).
-- Dokumentation eines neu identifizierten Features („Quick Ticket Creation“) mit 11 konkreten Use Cases.
+V03 erweitert deshalb die Methodik um MCP-gestuetzte Discovery. Der Lauf vergroessert die funktionale Breite deutlich (1720 konsolidierte Faehigkeiten, davon 1211 vormals undokumentierte Use Cases) und eignet sich besonders fuer Gap-Analysen und Vollstaendigkeitspruefung. Die Kehrseite ist ein geringerer Formalisierungsgrad gegenueber der ISO-Konsolidierung.
 
-Die genannten Zahlen sind als Ergebnis der prototypischen Toolchain-Ausführung zu interpretieren. Für die Arbeit ist dabei nicht nur der Umfang relevant, sondern die konkrete Nachvollziehbarkeit über Belege: In den Requirements-Artefakten sind Source-Evidence-Verweise in großer Zahl vorhanden; in den Mapping-Artefakten werden UI-Elemente konsistent mit ViewModel-Properties, Commands und Modulpfaden verknüpft.
+#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V03)]
 
-#heading(level: 3)[Aufwand und Beobachtungen zur Reproduzierbarkeit]
+- **Verwendeter Prompt:** "Please analyze this software project and write a reuqirements specification according to modern standards. Use Agents and MCP servers wherever possible. Keep superflous texts to a minimum and concentrate on actual requirements."
+- **Agentenbeispiele:**
+  - `Versuche/Versuch 03/Tools/Agents/centron-documentation-writer.md`
+  - `Versuche/Versuch 03/Tools/Agents/nhibernate-query-reviewer.md`
+  - `Versuche/Versuch 03/Tools/Agents/centron-code-reviewer.md`
+  - `Versuche/Versuch 03/Tools/Agents/webservice-developer.md`
+- **MCP-Beispiele:** Serena-MCP (Memory), Windows-MCP (UI-Interaktion), MSSQL-MCP (DB-Schemazugriff).
+- **Beispielhafte extrahierte Use-Case-/Anforderungsartefakte:**
+  - `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES_CENTRON_NEXUS.md`: u. a. Use Cases `1.1.1` (Personalized User Welcome), `1.1.6` (Work Status Alerts), `3.1` (Quick Ticket Creation).
+  - `Versuche/Versuch 03/ERP_DOCUMENTATION/USE_CASES.md`: moduluebergreifende, strukturierte Use-Case-Dokumentation fuer c-entron.NET.
+  - `Versuche/Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`: 1.720+ Use Cases und ca. 71% Dokumentations-Gap als Discovery-Nachweis.
 
-In den Discovery-Artefakten wird für eine UI-Analyse-Session ein Gesamtaufwand von 12 Stunden (4 Stunden Analyse, 8 Stunden Dokumentation) berichtet. Zusätzlich enthalten die Use-Case-Tools Aufwandsschätzungen für einzelne Analysebausteine (z. B. OpenAPI-Analyse, Workflows). Als Ergebnis lässt sich festhalten:
+#heading(level: 2)[Abgleich mit den geplanten Methoden]
 
-- Der prototypische Ansatz liefert in kurzer Zeit umfangreiche, strukturierte Artefakte (Requirements, Mapping, Glossar, Schema).
-- Die Dokumente selbst enthalten bereits wesentliche Elemente für Reproduzierbarkeit (Belegpfade, Artefaktverweise). Nicht durchgängig dokumentiert sind jedoch Promptversionen, Sampling-Parameter und Retrieval-Konfigurationen. Für eine belastbare Reproduzierbarkeit im wissenschaftlichen Sinne ist diese Metadatenebene zu ergänzen (vgl. Kapitel 4.1.3).
+Der Soll-Ist-Abgleich zeigt eine hohe Passung zur geplanten Gesamtmethodik, wenn diese als iterative Kombination aus *Discovery* und *Konsolidierung* verstanden wird:
 
-#heading(level: 2)[Qualitative Bewertung durch Experten]
+- Die Standardrecherche (ISO/IEC/IEEE 29148) wurde fruehzeitig umgesetzt.
+- Ein Baseline-Lauf ohne Spezialisierung wurde durchgefuehrt (V01).
+- Eine strukturierte ISO-Konsolidierung wurde realisiert (V02).
+- Danach wurde die Abdeckung durch MCP-gestuetzte Discovery erweitert (V03), weil der ISO-Lauf allein zu rigide und nicht vollumfaenglich genug war.
 
-Die qualitative Bewertung ist zentral, weil fachliche Korrektheit aus Textqualität allein nicht ableitbar ist und LLM-Ausgaben systemische Fehlermuster aufweisen können @ji2023hallucination @bender2021stochastic. Für die Arbeit ist daher ein Human-in-the-loop-Review vorgesehen, der die Ergebnisse aus der KI-gestützten Extraktion gegen Domänenwissen und Projektziele spiegelt.
+Abweichung zur urspruenglich linearen Planung: Stakeholder-Interviews und flaechendeckende fachliche Reviews wurden in der betrachteten Phase noch nicht vollstaendig abgeschlossen. Die Methodik wird deshalb in der Ergebnisinterpretation als "technisch validierte Vorstufe" einer finalen fachlichen Konsolidierung eingeordnet.
 
-Für die Durchführung sind folgende Bausteine vorgesehen:
+#heading(level: 2)[Bewertung der Forschungsleitfragen auf Basis der aktuellen Evidenz]
 
-- **Stichprobenplan:** Auswahl repräsentativer Module/Prozesse (z. B. Fakturierung, Rechte/Authentifizierung, Datenintegrität) sowie bewusst „randfalllastiger“ Bereiche.
-- **Review-Artefakte:** Requirements mit Belegangaben, Use-Case-Mappings (UI↔Code) und Glossarbegriffe als gemeinsamer Referenzrahmen.
-- **Bewertungsinstrument:** Kurzfragebogen mit Skalen für Verständlichkeit, Prüfbarkeit, fachliche Korrektheit und Priorität; zusätzlich Erfassung von Korrekturen/Ergänzungen als Änderungslog.
-- **Abgleichlogik:** Markierung von (a) bestätigten Requirements, (b) widersprochenen Requirements, (c) Requirements mit unzureichender Evidenz, (d) fehlenden Requirements (Gap-Liste).
+- **F1 (reproduzierbarer LLM-Einsatz):** beantwortbar. Die drei Versuche zeigen, dass reproduzierbare Prozessschritte und klar unterscheidbare Konfigurationen moeglich sind.
+- **F2 (Ableitung aus Code vs. Zusatzquellen):** teilweise beantwortbar. Codebasierte Extraktion funktioniert, video- und interviewbasierte Ergaenzungen sind noch offen.
+- **F3 (Qualitaet aus Expertensicht):** noch nicht abschliessend beantwortbar, da systematische Expertenratings nicht vollstaendig dokumentiert vorliegen.
+- **F4 (Chancen und Grenzen):** beantwortbar. Chancen liegen in Skalierung und Strukturierung; Grenzen in Halluzinationsrisiken, fehlender Vollstaendigkeit ohne Zusatzquellen und hohem Konsolidierungsbedarf.
 
-Zum Zeitpunkt der vorliegenden Fassung liegen in `Ergebnisse` keine dokumentierten Expertenratings oder Interviewprotokolle vor. Die qualitative Bewertung wird daher als nächster Evaluationsschritt in Kapitel 6 ergänzt, sobald Review-Sessions durchgeführt und protokolliert wurden. In der Diskussion (Kapitel 7) ist diese Einschränkung als Limitation der aktuellen Ergebnisevidenz zu berücksichtigen.
+#heading(level: 2)[Limitationen]
+
+Die aktuelle Evidenz ist durch drei Punkte begrenzt:
+
+1. Vollstaendige Video-Transkription und -Auswertung fehlen noch.
+2. Ein methodischer Endabgleich zwischen Video- und Codeperspektive ist noch nicht abgeschlossen.
+3. Die fachliche Endklassifikation aller Use-Case-Cluster (Ja/Nein/Neu/TBD) liegt noch nicht durchgaengig vor.
+
+Diese Limitationen betreffen vor allem die finale Vollstaendigkeitsaussage, nicht jedoch die grundlegende Wirksamkeit der iterativen Methodik.