Gowler/Masterarbeit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

04_einmal durch

Browse Source
This commit is contained in:
christoph.schwoerer
2026-05-30 10:11:37 +02:00
parent 43a32779d8
commit 776bd785e3
11 changed files with 188 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
Kapitel/02_theoretischer_hintergrund/02_02_large_language_models.typ
View File

@@ -1,6 +1,8 @@
#import "@preview/cetz:0.4.2"
#import "@preview/cetz-plot:0.1.3": plot
#set text(lang: "de")
#heading(level: 2)[Large Language Models im Software Engineering]
#heading(level: 3)[Künstliche Intelligenz, Machine Learning und Einordnung von LLMs]
@@ -254,12 +256,12 @@ Die Literatur legt nahe, dass LLMs im Software Engineering dann robust eingesetz
Diese Kontrollen adressieren nicht alle Risiken, reduzieren aber die typischen Fehlerklassen (Halluzination, Überinterpretation, fehlende Konsistenz) und schaffen die Grundlage für eine belastbare Evaluation.
#heading(level: 3)[Qualitätsbewertung und Messgrößen im Requirements-Kontext]
#heading(level: 3)[Qualitätsbewertung und Messgrößen im Requirements-Kontext] <sec_re_qualitaet>
Die Qualität von LLM-Ergebnissen wird in vielen Arbeiten mit allgemeinen Textmetriken oder aufgabenspezifischen Benchmarks bewertet. Für die Requirements-Extraktion aus Code reichen solche Metriken nicht aus, da es hier weniger um sprachliche Ähnlichkeit geht, sondern um fachliche Korrektheit, Prüfbarkeit und Nachvollziehbarkeit @hemmat2025directions @marques2024chatgptre. Eine sinnvolle Bewertung orientiert sich daher an RE-Kriterien und unterscheidet drei Dimensionen:
/ Statement-Qualität: Ist ein Requirement eindeutig, vollständig im Satzbau, frei von nicht belegten Annahmen und mit Akzeptanzkriterium bzw. Prüfidee versehen?
/ Set-Qualität: Ist die Menge der Requirements konsistent, nicht redundant und deckt die relevanten Prozesse und Varianten ab, ohne sich in Detailfällen zu verlieren?
/ Set-Qualität (Vollständigkeit): Deckt die Menge der Requirements alle relevanten Prozesse und Varianten vollständig ab, ist sie in sich konsistent und frei von Doubletten? Die Vollständigkeit ist dabei die zentrale Eigenschaft, weil ein fehlendes Requirement im Migrationskontext zu Funktionsverlust führen kann, während Inkonsistenzen oder Doubletten in einem Review nachträglich aufgelöst werden können.
/ Traceability-Qualität: Sind Belege reproduzierbar auffindbar (z. B. Dateipfad, Methode, SQL-Query), und lässt sich die Ableitung von „Beleg → Requirement" nachvollziehen?
Für Legacy-Migrationen ist zudem die Fehlerkostenperspektive entscheidend. Ein fehlendes Requirement kann zu Funktionsverlust führen, ein falsches Requirement kann zu fehlerhaften Designentscheidungen führen, und ein unpräzises Requirement verursacht Review- und Nacharbeit. Daraus folgt eine pragmatische Bewertung: Requirements mit hoher Migrationskritikalität (z. B. Sicherheitsregeln, Abrechnungslogik, Berechtigungen) sollten strengere Evidenzanforderungen und intensivere Reviews erhalten als periphere Funktionen. Dieses Prinzip ist kompatibel mit der risikobasierten Priorisierung von Qualitätsanforderungen @glinz2008quality und lässt sich auf Funktionsanforderungen übertragen.