Zwischenstand 04 und 01

Kapitel/01_einleitung.typ

@@ -11,22 +11,22 @@
 #heading(level: 1)[Einleitung (ca. 8 Seiten)]
 
 #heading(level: 2)[Ausgangssituation und Motivation]
-In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre Produkte neu zu bewerten. Betroffen sind vor allem Systeme die über lange Jahre nur in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und fallen in der technologischen Schuld immer weiter Zurück. Eine technologische Weiterentwicklung ist nicht möglich und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen und Code sind allerdings selten. Das meiste Wissen steckt implizit im Code oder in der Köpfen der verlbeibenden Entwickler.
+In den vergangenen Jahren hat die digitale Transformation mittelständische Softwareanbieter gezwungen, ihre Produkte neu zu bewerten. Betroffen sind vor allem Systeme, die über lange Jahre ausschließlich in Windows-Umgebungen vertrieben wurden. Diese stoßen bei Cloud-, Web- und Mobile-Szenarien an technische sowie organisatorische Grenzen und häufen zunehmend technische Schulden an. Eine technologische Weiterentwicklung wird zusehends schwieriger, und an einer Neuentwicklung führt oft kein Weg vorbei. Dokumentierte Anforderungen oder eine systematische Code-Dokumentation sind allerdings selten. Der Großteil des Wissens steckt implizit im Code oder in den Köpfen der verbleibenden Entwickler.
 
-Die c-entron GmbH in Ulm ist von diesem Szenario voll Betroffen. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist aber eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden erwarten zwischenzeitlich aber plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie z.B. SaaS (Software as a Service). Die bestehende Anwendung ist aber in ihrer Skalierung, Deployment und Abrechnung limitiert. Eine Migration auf eine webbasierte Plattform ist somit zwingend erforderlich. 
+Die c-entron GmbH in Ulm ist von diesem Szenario unmittelbar betroffen. Das Unternehmen betreibt seit über zwanzig Jahren eine Windows-basierte ERP-Suite für IT-Systemhäuser. Die Lösung deckt Auftragsabwicklung, Lager, Fakturierung und Projektabrechnung ab, ist jedoch eng mit der bisherigen Client/Server-Architektur gekoppelt. Kunden erwarten inzwischen plattformunabhängige Oberflächen, Self-Service-Funktionen und flexible Betriebsmodelle wie SaaS (Software as a Service). Die bestehende Anwendung ist in Skalierung, Deployment und Abrechnung jedoch limitiert, sodass eine Migration auf eine webbasierte Plattform zwingend erforderlich wird.
 
-Eine einfache Neuimplementierung auf Basis vorhandener Anfoderungs oder Code Dokumentation ist aber aus oben geschilderten Gründen nicht einfach möglich. Die Herausforderung die sich stellt ist mit möglichst geringem Aufwand eine vollständige Beschreibung für ein vollständiges ERP System zu erarbeiten. Eine Manuelle auswertung des Codes oder Obfläche auf Funktionalitäten ist aufgrund der extremen Komplexität, geschuldet der langjährgien Weiterententwicklung, nur mit sehr hohem Personalaufwand möglich und daher nicht realsierbar.
+Eine Neuimplementierung auf Basis vorhandener Anforderungs- oder Code-Dokumentation ist aus den oben genannten Gründen kaum möglich. Die Herausforderung besteht darin, mit möglichst geringem Aufwand eine vollständige Beschreibung eines komplexen ERP-Systems zu erarbeiten. Eine manuelle Auswertung von Code und Oberflächen auf Funktionalitäten ist angesichts der Komplexität, die aus der langjährigen Weiterentwicklung resultiert, nur mit sehr hohem Personalaufwand möglich und daher nicht realisierbar.
 
-In den letzen Jahren hat sich hierzu nun ein neues Instrumentarium etabliert. Large Language Models wie Chat GPT-5 oder Claude.ai können durch agentische CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Anforderungen erarbeiten und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht. Diese Arbeit adressiert dies und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderunganalyse eingesetzt werden können.
+In den vergangenen Jahren hat sich hierzu ein neues Instrumentarium etabliert. Large Language Models wie ChatGPT-5 oder Claude.ai können in Verbindung mit agentischen CLIs (Codex, Claude Code) große Mengen an Quellcode analysieren, Anforderungen erarbeiten und textuell beschreiben. Damit entsteht die Chance, fehlende Anforderungsdokumentationen zumindest teilweise aus dem Code heraus zu rekonstruieren. Die praktische Nutzung dieses Potenzials ist bislang kaum erforscht. Diese Arbeit setzt an dieser Stelle an und untersucht, wie KI-gestützte Verfahren für eine systematische Anforderungsanalyse eingesetzt werden können.
 
 #heading(level: 2)[Problemstellung]
-Für das ERP Software Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeitintensiv, ressourcenintensiv und anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
+Für das ERP-Software-Produkt der c-entron fehlen strukturierte und dokumentierte Requirements. Die Analyse der bestehenden Codebasis ist zeit- und ressourcenintensiv sowie anfällig für Insel- und Metawissen. Daraus ergeben sich mehrere Risiken:
 
-/ Re-Implementationsfehler: Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Zeitgleich sind Workaround of Symptom einer mangelhaften Erfassung der Anfoderungen bei originalen Implementierung und ein zeichen fehlender Weitsicht.
-/ Technische Schuld: Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind auch nicht bewandt in alten technolgien und es fehlt das Verständnis für historische Zwänge und Zusammenhänge.
-/ Implizites Wissen: Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim design neuer Lösungen ("Das haben wir schon immer so umgestzt").
+/ Re-Implementationsfehler: Edge Cases, Workarounds und kundenindividuelle Anpassungen sind nur im Code sichtbar. Ohne vollständige Erfassung drohen Funktionsverluste nach der Migration. Workarounds sind zugleich Symptom einer mangelhaften Anforderungserfassung in der ursprünglichen Implementierung und Zeichen fehlender Weitsicht.
+/ Technische Schuld: Entwickler investieren viel Zeit in das Verständnis historischer Strukturen, statt aktiv an der neuen Plattform zu arbeiten. Veraltete Muster werden unreflektiert übernommen. Neue Mitarbeiter sind mit den alten Technologien nicht vertraut, und es fehlt ihnen das Verständnis für historische Zwänge und Zusammenhänge.
+/ Implizites Wissen: Domänenwissen liegt bei wenigen langjährigen Mitarbeitenden. Personalwechsel führen zu Wissensverlust und Verzögerungen. Gleichzeitig führt die langjährige Arbeit mit dem bestehenden System zu eingeschränkter Offenheit beim Design neuer Lösungen („Das haben wir schon immer so umgesetzt").
 / Komplexität der Codebasis: Verschachtelte Abhängigkeiten, unterschiedliche Stile und technologiebedingte Zwänge erschweren eine modulare Anforderungsableitung.
-/ Fehlende Traceability: Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind auch generisch und lassen sich nicht einer konkreten Anforderung zuordnen, wie zum Beispiel das anzeigen eine Tabelle. Konkrete Datenflüsse lassen sich hier nur am laufenden System beobachten was die Analyse nochmal um eine Größenordnung Resourcenintensiver macht.
+/ Fehlende Traceability: Ohne Zuordnung zwischen Code und Geschäftsprozess fehlt die Grundlage für Priorisierung, Testkonzeption und spätere Wartung. Große Teile des Codes sind zudem generisch und lassen sich keiner konkreten Anforderung zuordnen, etwa das Anzeigen einer Tabelle. Konkrete Datenflüsse lassen sich nur am laufenden System beobachten, was die Analyse um eine weitere Größenordnung ressourcenintensiver macht.
 
 Eine rein manuelle Rekonstruktion aller Anforderungen wäre wirtschaftlich kaum tragbar. Deshalb soll geprüft werden, ob KI-gestützte Verfahren Requirements so extrahieren können, dass sie als belastbare Basis für die Modernisierung dienen.
 
@@ -36,7 +36,7 @@ Diese Arbeit verfolgt das Ziel, ein vollständiges Vorgehen für KI-gestütztes
 - Entwicklung eines Prozessmodells, das Vorbereitung, Analyse, Validierung und Übergabe strukturiert.
 - Evaluation aktueller LLMs hinsichtlich Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
 - Definition eines Evaluationsrahmens mit quantitativen und qualitativen Kriterien (Vollständigkeit, Verständlichkeit, Redundanzfreiheit, Aufwandseinsparung).
-- Integration von Stakeholder-Wissen durch Interviews, um die Qualität der KI ergebnisse zu bewerten und nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen .
+- Integration von Stakeholder-Wissen durch Interviews, um die Qualität der KI-Ergebnisse zu bewerten und nicht direkt aus dem Code ableitbare Anforderungen zu ergänzen.
 
 
 #heading(level: 2)[Forschungsleitfragen]
@@ -54,7 +54,7 @@ Die Arbeit ist in acht Kapitel gegliedert:
 2. *Theoretische Grundlagen:* Requirements Engineering, Reverse Engineering, Large Language Models sowie Qualitätssicherungskriterien.
 3. *Fallstudie c-entron GmbH:* Unternehmensprofil, Produktarchitektur, Migrationsdruck und Rahmenbedingungen.
 4. *Konzeption und methodisches Vorgehen:* Prozessmodell, Technologieauswahl, Stakeholder-Einbindung und Datenbasis.
-5. *Ergebnisse:* Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements/Use Cases aus den Ergebnisverzeichnissen.
+5. *Ergebnisse:* Vollständige Ergebnisdarstellung der drei Versuche inkl. Artefaktlisten und beispielhafter Requirements / Use Cases aus den Ergebnisverzeichnissen.
 6. *Evaluation:* Vorgehen, Metriken, Ergebnisse und Expertenfeedback.
 7. *Diskussion:* Interpretation der Resultate, Limitationen und Implikationen für Forschung und Praxis.
 8. *Fazit und Ausblick:* Zusammenfassung, Beantwortung der Forschungsfragen und Perspektiven für weitere Arbeiten.

Kapitel/04_konzeption_methodisches_vorgehen.typ

@@ -17,6 +17,56 @@
 
 Dieses Kapitel beschreibt die Methodik, mit der die in Kapitel 1 beschriebenen Ziele und Forschungsleitfragen beantwortet werden sollen. Ausgangspunkt ist das methodische Design. Aus diesem Design leiten sich alle weiteren methodischen Entscheidungen ab. Vorausgegangene Proof-of-Concept-Läufe haben einzelne Aspekte des Vorgehens informell erprobt und das hier dargestellte Vorgehen geprägt, sie sind aber nicht Gegenstand der Auswertung. Die eigentliche Untersuchung wird in den folgenden Abschnitten geplant und in den folgenden Kapiteln durchgeführt und bewertet.
 
+#heading(level: 2)[Werkzeug-Grundlagen: Agentische CLIs, Agenten, MCP und lokale Inferenz]
+
+Bevor das eigentliche Untersuchungsdesign beschrieben wird, werden die zentralen Werkzeug-Begriffe geklärt, an denen die spätere Versuchsreihe variiert. Sie sind nicht nur Hilfsmittel der Durchführung, sondern definieren genau die Stellschrauben, die in den Versuchen V1 bis V3 systematisch hinzugenommen werden. Die folgende Darstellung beschränkt sich auf das für diese Arbeit relevante Maß und ersetzt keine vollständige Werkzeugdokumentation. Das Zusammenspiel der vier Bausteine ist in @abb_werkzeug_grundlagen skizziert.
+
+*Agentische CLIs.* Eine agentische CLI ist ein Kommandozeilen-Werkzeug, in dem ein LLM nicht nur Text generiert, sondern selbständig Dateien liest, Befehle ausführt und Tools aufruft. Im Gegensatz zum klassischen Chat-Prompting bleibt der Anwender nicht der einzige Akteur; die CLI orchestriert mehrere Modellaufrufe und Werkzeuginteraktionen in einer Schleife, bis ein vorgegebenes Ziel erreicht ist. Etablierte Vertreter sind Claude Code von Anthropic @claudecode_quickstart_2026, die Codex-CLI von OpenAI sowie die Qwen Code CLI von Alibaba. Für diese Arbeit ist die agentische CLI die operative Basis. Sie macht LLM-Läufe scriptbar, reproduzierbar und unabhängig von einer interaktiven Chat-Oberfläche.
+
+*Agenten und Agentendateien.* Agenten im hier verwendeten Sinne sind rollenspezialisierte Konfigurationen, die innerhalb einer agentischen CLI als Sub-Prozesse aufgerufen werden. Sie werden typischerweise als Markdown-Dateien mit YAML-Frontmatter abgelegt und enthalten drei Bestandteile: einen Auftrag (was tut der Agent), eine eigene Systemanweisung (wie tut er es) und ein begrenztes Toolset (womit darf er es tun). Die aufrufende CLI startet einen solchen Agenten mit eigenem Kontextfenster, sodass dessen Zwischenergebnisse den Hauptkontext nicht überfluten. In dieser Arbeit tragen Agenten Versuch V2, indem sie die Extraktion auf vier Rollen aufteilen: Stakeholder-Analyse, System-Requirements, Software-Requirements und einen ISO-29148-Orchestrator.
+
+*Model Context Protocol (MCP).* Das Model Context Protocol ist ein 2024 von Anthropic veröffentlichter offener Standard zur Anbindung externer Werkzeuge und Datenquellen an LLM-Clients @mcp_intro_2026 @claudecode_mcp_2026. Ein MCP-Server kapselt eine konkrete Fähigkeit, etwa Symbol-Navigation im Quellcode, lesenden Datenbankzugriff oder GUI-Beobachtung, hinter einer einheitlichen JSON-RPC-Schnittstelle. Ein MCP-Client wie Claude Code entdeckt die angebotenen Werkzeuge zur Laufzeit und ruft sie kontrolliert auf, anstatt dass das LLM Inhalte aus Code oder Datenbank frei rekonstruiert. Für diese Arbeit trägt MCP Versuch V3 und ist gleichzeitig die technische Grundlage der Belegpflicht: Eine extrahierte Anforderung lässt sich nur dann nachvollziehbar auf einen Codebeleg oder einen Datenbankbefund zurückführen, wenn der Zugriff darauf reproduzierbar erfolgt @mcp_servers_repo_2026.
+
+*Lokale Inferenz-Runtimes.* Eine lokale Inferenz-Runtime ist eine Software, die LLMs auf eigener Hardware ausführt und ihre Funktion über einen OpenAI-kompatiblen HTTP-Endpunkt bereitstellt. Stellvertretend wird in dieser Arbeit LM Studio eingesetzt, das Modelle wie Qwen 3.5 Coder in verschiedenen Quantisierungsstufen ausführen kann. Für den hier untersuchten Kontext sind zwei Eigenschaften entscheidend. Erstens entfällt der Cloud-Versand, was bei der kundenbezogenen c-entron-Codebasis aus Datenschutzgründen relevant ist. Zweitens werden Quantisierungsstufe und Sampling-Parameter wie Temperatur, top\_p oder repeat penalty zu reproduzierbarkeitsrelevanten Stellgrößen, die in Versuch V4 zusätzlich zur Modellwahl dokumentiert werden.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let draw-box(x, y, w, h, label) = {
+      rect(
+        (x - w/2, y - h/2),
+        (x + w/2, y + h/2),
+        stroke: black + 0.6pt, fill: luma(240),
+      )
+      content((x, y), text(size: 9pt, weight: "bold")[#label])
+    }
+
+    let draw-arrow(from, to) = {
+      line(from, to, mark: (end: ">"), stroke: black + 0.6pt)
+    }
+
+    let h-half = 0.4
+    let gap = 0.15
+
+    draw-box(0,    5, 2.6, 0.8, "Benutzer")
+    draw-box(0,    3, 7.4, 0.8, "Agentische CLI (Claude Code / Codex / Qwen)")
+    draw-box(-4.6, 1, 3.6, 0.8, "LLM (Cloud / LM Studio)")
+    draw-box(0,    1, 2.8, 0.8, "Agentendateien")
+    draw-box(4.6,  1, 3.6, 0.8, "MCP-Server")
+    draw-box(4.6, -1, 3.6, 0.8, "Codebasis / Datenbank")
+
+    draw-arrow((0,    5 - h-half - gap), (0,    3 + h-half + gap))
+    draw-arrow((0,    3 - h-half - gap), (-4.6, 1 + h-half + gap))
+    draw-arrow((0,    3 - h-half - gap), (0,    1 + h-half + gap))
+    draw-arrow((0,    3 - h-half - gap), (4.6,  1 + h-half + gap))
+    draw-arrow((4.6,  1 - h-half - gap), (4.6, -1 + h-half + gap))
+  }),
+  caption: [Zusammenspiel der vier Werkzeug-Bausteine. Die agentische CLI orchestriert das LLM, ruft rollenspezialisierte Agentendateien als Sub-Prozesse auf und steuert MCP-Server, die kontrolliert auf Codebasis und Datenbank zugreifen.],
+) <abb_werkzeug_grundlagen>
+
+Damit sind die Bausteine benannt, an denen die spätere Versuchsreihe variiert. Versuch V1 nutzt ausschließlich die agentische CLI ohne weitere Bausteine, V2 ergänzt Agentendateien, V3 ergänzt MCP-Server, und V4 prüft die Übertragbarkeit auf alternative Modelle einschließlich lokaler Inferenz. Die Begriffe werden in den folgenden Abschnitten nicht erneut definiert.
+
 #heading(level: 2)[Methodisches Design im Überblick]
 
 Das Vorgehen ist entlang der vier Forschungsleitfragen aus Kapitel 1 strukturiert. Diese werden im Folgenden mit Frage 1 (Steuerung und Reproduzierbarkeit), Frage 2 (KI-Extraktion und Stakeholder-Input), Frage 3 (Qualitätsbewertung) und Frage 4 (Chancen, Grenzen und Risiken) bezeichnet. Aus jeder Leitfrage folgt unmittelbar eine Datenquelle und ein Auswertungsweg. Damit ist sichergestellt, dass die methodischen Bausteine nicht nachträglich auf die Fragen abgebildet werden, sondern aus ihnen hervorgehen.