125 lines
8.7 KiB
Markdown
125 lines
8.7 KiB
Markdown
# 5. Prototypische Umsetzung
|
|
|
|
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.
|
|
|
|
## 5.1 Architektur des LLM-Agenten
|
|
|
|
### 5.1.1 Architekturüberblick
|
|
|
|
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:
|
|
|
|
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.
|
|
|
|
Retrieval-Augmented Generation ist in dieser Architektur das zentrale Prinzip, um mit begrenzten Kontextfenstern umzugehen und Aussagen an konkrete Belege zu binden (Lewis et al. 2020).
|
|
|
|
### 5.1.2 Ingestion: Artefaktaufbereitung und Chunking
|
|
|
|
Die Ingestion-Schicht übernimmt:
|
|
|
|
* 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.
|
|
|
|
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.
|
|
|
|
### 5.1.3 Retrieval: Kontextauswahl und Ranking
|
|
|
|
Retrieval ist als zweistufiges Verfahren umgesetzt:
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
### 5.1.4 Requirements-Extraktion und Traceability-Datenmodell
|
|
|
|
Die Generation-Schicht erzeugt Requirements nicht als Freitext, sondern als strukturierte Einträge. Ein Eintrag umfasst mindestens:
|
|
|
|
* **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).
|
|
|
|
Traceability ist dabei ein zentrales Designkriterium. Die Literatur beschreibt Traceability als Voraussetzung, um Anforderungen über Lebenszyklen hinweg zu begründen und zu pflegen (Gotel und Finkelstein 1994; Ramesh und Jarke 2001). 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.
|
|
|
|
## 5.2 Toolchain-Integration
|
|
|
|
### 5.2.1 Integration in Repository und Entwicklungsworkflow
|
|
|
|
Die Toolchain-Integration zielt darauf, Analyseergebnisse in vorhandene Arbeitsabläufe zu integrieren. Dazu gehören:
|
|
|
|
* **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.
|
|
|
|
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.
|
|
|
|
### 5.2.2 Einbindung in Wissens- und Ticket-Systeme
|
|
|
|
In Modernisierungsvorhaben sind Ticketsysteme und Wissensbasen zentrale Koordinationspunkte. Der Prototyp ist so konzipiert, dass Requirements:
|
|
|
|
* 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.
|
|
|
|
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.
|
|
|
|
### 5.2.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).
|
|
|
|
## 5.3 Governance, Datenschutz und IP
|
|
|
|
### 5.3.1 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 (Bender et al. 2021). Für die Fallstudie sind insbesondere folgende Risikoklassen relevant:
|
|
|
|
* **Falschaussagen/Halluzinationen:** plausibel klingende, aber unbelegte Requirements (Ji et al. 2023).
|
|
* **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.
|
|
|
|
### 5.3.2 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.
|
|
|
|
### 5.3.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.
|
|
|