125 lines
8.9 KiB
Typst
125 lines
8.9 KiB
Typst
#let __is_thesis = context { query(<__thesis_document>).len() > 0 }
|
|
#if __is_thesis == false [
|
|
#set cite(style: "apa")
|
|
#hide(bibliography("../literatur.bib", style: "apa"))
|
|
]
|
|
|
|
#heading(level: 1)[Evaluation (ca. 12 Seiten)]
|
|
|
|
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)[Evaluationsdesign und Datenbasis]
|
|
|
|
Die Auswertung basiert ausschliesslich auf den erzeugten Artefakten in:
|
|
|
|
- `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`.
|
|
|
|
Dabei wurden nur konsolidierte, in den Dateien ausgewiesene Kennzahlen uebernommen. Fokus der Bewertung:
|
|
|
|
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: 2)[Quantitative Ergebnisse der Versuchsreihe]
|
|
|
|
#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]
|
|
)
|
|
|
|
Ergaenzende Kontextkennzahlen aus den Versuchsdateien:
|
|
|
|
- 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: 2)[Vergleichende Analyse]
|
|
|
|
#heading(level: 3)[Versuch 01: Formale Baseline ohne Tooling-Erweiterung]
|
|
|
|
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.
|
|
|
|
#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V01)]
|
|
|
|
- **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.
|
|
|
|
#heading(level: 3)[Versuch 02: ISO-orientierte Konsolidierung mit Agenten]
|
|
|
|
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.
|
|
|
|
#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V02)]
|
|
|
|
- **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).
|
|
|
|
#heading(level: 3)[Versuch 03: Discovery-Erweiterung mit Agenten und MCP]
|
|
|
|
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.
|
|
|
|
#heading(level: 4)[Prompt, Agenten und Ergebnisbeispiele (V03)]
|
|
|
|
- **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.
|
|
|
|
#heading(level: 2)[Abgleich mit den geplanten Methoden]
|
|
|
|
Der Soll-Ist-Abgleich zeigt eine hohe Passung zur geplanten Gesamtmethodik, wenn diese als iterative Kombination aus *Discovery* und *Konsolidierung* verstanden wird:
|
|
|
|
- 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.
|
|
|
|
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.
|
|
|
|
#heading(level: 2)[Bewertung der Forschungsleitfragen auf Basis der aktuellen Evidenz]
|
|
|
|
- **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.
|
|
|
|
#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.
|