87 lines
9.2 KiB
Typst
87 lines
9.2 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)]
|
|
|
|
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.
|
|
|
|
#heading(level: 2)[Evaluationskriterien und Messgrößen]
|
|
|
|
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.
|
|
|
|
Für die Arbeit werden die folgenden Kriterien operationalisiert:
|
|
|
|
- **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.
|
|
|
|
#heading(level: 2)[Durchführung und Ergebnisse]
|
|
|
|
#heading(level: 3)[Untersuchungsgegenstand und Datenbasis]
|
|
|
|
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:
|
|
|
|
- 34 Projekte und 849 Business-Logic-Klassen,
|
|
- 956 NHibernate-Mappings,
|
|
- 2.145 REST-Endpunkte,
|
|
- 135 WPF-Module (UI-Kontext).
|
|
|
|
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.
|
|
|
|
#heading(level: 3)[Ablauf der prototypischen Auswertung]
|
|
|
|
Die Durchführung folgt der Logik aus Kapitel 4 (Scope → Artefaktpipeline → Extraktion → Traceability → Review). Für die prototypische Auswertung wurden die folgenden Artefaktgruppen erzeugt:
|
|
|
|
- **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).
|
|
|
|
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: 3)[Quantitative Ergebnisse]
|
|
|
|
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:
|
|
|
|
- **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.
|
|
|
|
Für die Use-Case- und Mapping-Ebene werden folgende Umfangs- und Abdeckungszahlen berichtet:
|
|
|
|
- 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.
|
|
|
|
Für die UI-basierte Discovery (CentronNexus) wird ein erster, bewusst begrenzter Scope dokumentiert:
|
|
|
|
- 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.
|
|
|
|
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: 3)[Aufwand und Beobachtungen zur Reproduzierbarkeit]
|
|
|
|
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:
|
|
|
|
- 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).
|
|
|
|
#heading(level: 2)[Qualitative Bewertung durch Experten]
|
|
|
|
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.
|
|
|
|
Für die Durchführung sind folgende Bausteine vorgesehen:
|
|
|
|
- **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).
|
|
|
|
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.
|