04_init neu

Kapitel/04_konzeption_methodisches_vorgehen.typ

@@ -0,0 +1,221 @@
+#import "@preview/cetz:0.4.2"
+
+#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)[Konzeption und methodisches Vorgehen (ca. 12 Seiten)]
+
+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)[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.
+
+#figure(
+  cetz.canvas({
+    import cetz.draw: *
+
+    let stages = (
+      (y:  4.0, label: "Codebasis",      q: none),
+      (y:  2.0, label: "KI-Extraktion",  q: (num: "Frage 1", text: "Welche Steuerungsmechanismen und Kontrollpunkte sind notwendig, um LLMs reproduzierbar einzusetzen?")),
+      (y:  0.0, label: "Strukturierung", q: (num: "Frage 2", text: "Welche Anforderungen lassen sich aus Code extrahieren, welche müssen über Interviews ergänzt werden?")),
+      (y: -2.0, label: "Validierung",    q: (num: "Frage 3", text: "Wie beurteilen Fachexperten Vollständigkeit, Verständlichkeit und Nützlichkeit der KI-Ergebnisse?")),
+      (y: -4.0, label: "Bewertung",      q: (num: "Frage 4", text: "Welche Effizienzgewinne, Limitierungen und Risiken sind realistisch und müssen adressiert werden?")),
+    )
+
+    let box-half-w = 1.5
+    let box-half-h = 0.4
+    let stage-x = -5.0
+    let arrow-gap = 0.1
+
+    for s in stages {
+      rect(
+        (stage-x - box-half-w, s.y - box-half-h),
+        (stage-x + box-half-w, s.y + box-half-h),
+        stroke: black + 0.6pt, fill: luma(240),
+      )
+      content((stage-x, s.y), text(size: 9pt, weight: "bold")[#s.label])
+    }
+
+    for i in range(stages.len() - 1) {
+      let s1 = stages.at(i)
+      let s2 = stages.at(i + 1)
+      line(
+        (stage-x, s1.y - box-half-h - arrow-gap),
+        (stage-x, s2.y + box-half-h + arrow-gap),
+        mark: (end: ">"),
+        stroke: black + 0.6pt,
+      )
+    }
+
+    let q-x = stage-x + box-half-w + 0.6
+    for s in stages {
+      if s.q != none {
+        content(
+          (q-x, s.y),
+          anchor: "west",
+          box(
+            width: 9cm,
+            text(size: 9pt)[*#s.q.num:* #s.q.text],
+          ),
+        )
+      }
+    }
+  }),
+  caption: [Methodisches Design im Überblick. Die vertikale Sequenz zeigt den Ablauf von der Codebasis bis zur Bewertung. Pro Phase ist die zugeordnete Forschungsleitfrage angeben.],
+) <abb_forschungsdesign>
+
+Der untersuchte Prozess folgt einer durchgehenden Kette von der Codebasis bis zur belastbaren Anforderung. Auf der Codebasis setzt eine KI-gestützte Extraktion auf. Die Ergebnisse werden in eine konsistente Spezifikationsform überführt und durch Fachexperten validiert. Die abschließende Bewertung erfolgt entlang vordefinierter Qualitätsdimensionen.
+
+Aus diesem Ablauf ergeben sich drei methodische Bausteine, die in den folgenden Abschnitten ausgearbeitet werden. Erstens die *kontrollierte Tooling-Ablation*. Es ist eine Versuchsreihe vorgesehen, die auf derselben Codebasis und mit demselben Grundprompt arbeitet und sich gezielt nur in einzelnen Werkzeugkomponenten unterscheidet. Die konkrete Anzahl und Zuschnitt der Versuche werden im Untersuchungsdesign festgelegt. Zweitens die *strukturierte Stakeholder-Validierung*. Jede extrahierte Anforderung soll durch Domänenexperten geprüft, anhand einer Likert-Skala bewertet und durch halbstrukturierte Interviews ergänzt werden. Drittens die *RE-Qualitätsbewertung*. Die Bewertungskriterien werden vor der Durchführung definiert, sodass eine nachträgliche Kriterienwahl ausgeschlossen ist.
+
+#heading(level: 2)[Bezugsrahmen: Der RRE-Prozess als Untersuchungsgegenstand]
+
+Das in dieser Arbeit untersuchte Vorgehen folgt der in Kapitel 2 hergeleiteten siebenstufigen Methodenkette für Reverse Requirements Engineering. Die Schritte bauen aufeinander auf und decken den Weg von der ersten Abgrenzung des Untersuchungsgegenstands bis zur Validierung der gewonnenen Anforderungen ab.
+
+1. *Scope und Domänenabgrenzung:* Auswahl relevanter Module, Datenobjekte und Prozesse.
+2. *Artefakterhebung:* Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen und Change-Historie.
+3. *Technische Analyse:* Struktur- und Abhängigkeitsanalyse sowie Identifikation von Kernkomponenten, Regeln und Integrationspunkten.
+4. *Semantische Interpretation:* Ableitung fachlicher Aussagen aus technischen Implementierungen.
+5. *Formalisierung:* Überführung in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. *Traceability-Anreicherung:* Verknüpfung jedes Requirements mit Artefaktbelegen.
+7. *Validierung:* Review durch Fachexperten und Abgleich mit Laufzeitverhalten oder Tickets.
+
+In dieser Arbeit werden lediglich Schritt 1 und Schritt 7 manuell durchgeführt. Die dazwischenliegenden Schritte 2 bis 6 sollen KI-gestützt automatisiert werden. Damit verschiebt sich der Untersuchungsschwerpunkt nicht auf die Anforderungsbeschreibung als solche, sondern auf die zuverlässige Erzeugung dieser Beschreibung durch ein LLM.
+
+Damit das Vorgehen belastbar bleibt, sind in jeder Iteration vier Eigenschaften sicherzustellen:
+
+- *Belegpflicht:* Jede extrahierte Anforderung muss auf ein konkretes Artefakt wie eine Datei, ein Modul, ein Datenobjekt oder einen UI-Text zurückführbar sein.
+- *Explizite Hypothesenmarkierung:* Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, werden als Hypothesen markiert und gesondert validiert.
+- *Segmentierung und Kontextsteuerung:* Da Artefakte über die Codebasis verteilt sind, wird der dem LLM jeweils präsentierte Kontext bewusst eingeschränkt, um Überinterpretation zu reduzieren.
+- *Human-in-the-loop:* Die fachliche Validierung durch Domänenexperten ist nicht optional. Plausibel formulierte LLM-Ausgaben sind kein hinreichender Beweis für sachliche Korrektheit.
+
+Mit der Festlegung der Schrittfolge, der Aufteilung zwischen Mensch und KI sowie den vier Pflicht-Eigenschaften ist der Bezugsrahmen geklärt, in dem die folgenden Abschnitte ihre Detailfragen verorten.
+
+#heading(level: 2)[Werkzeugbasis: Auswahl des LLM]
+
+Die Wahl des konkret eingesetzten LLM bestimmt maßgeblich, welche Steuerungsmechanismen praktisch umgesetzt werden können und wie reproduzierbar die Ergebnisse erzeugt werden. Aus diesem Grund wird die Werkzeugauswahl nicht implizit vorausgesetzt, sondern entlang der fünf Kriterien aus der Zielsetzung begründet. Diese Kriterien sind Kontextfenster, Codeverständnis, Steuerbarkeit, Kosten und Datenschutz.
+
+In die Vorauswahl gehen vier aktuell verfügbare Optionen ein. Anthropic Claude wird über die CLI-Variante Claude Code eingebunden, die agentisches Arbeiten und MCP-Integration nativ unterstützt. OpenAI bietet mit GPT-5 und der Codex-CLI eine vergleichbare agentische Schnittstelle. Auf lokaler Seite kommen das offen verfügbare Qwen sowie Kimi infrage, beide mit der Möglichkeit zur Ausführung ohne Cloud-Versand.
+
+#figure(
+  table(
+    columns: (1.4fr, 1fr, 1fr, 1fr, 1fr),
+    align: (left, center, center, center, center),
+    stroke: 0.4pt,
+    [*Kriterium*], [*Claude (Claude Code)*], [*GPT-5 (Codex)*], [*Qwen (lokal)*], [*Kimi (lokal)*],
+    [Kontextfenster], [bis 1 M Tokens], [bis 400 k Tokens], [bis 128 k Tokens], [bis 200 k Tokens],
+    [Codeverständnis], [hoch], [hoch], [mittel], [mittel],
+    [Steuerbarkeit (Agenten, MCP)], [nativ], [über Codex-CLI], [eingeschränkt], [eingeschränkt],
+    [Kosten], [API-Abrechnung], [API-Abrechnung], [Eigenbetrieb], [Eigenbetrieb],
+    [Datenschutz], [Cloud-Versand], [Cloud-Versand], [On-Premise], [On-Premise],
+  ),
+  caption: [Vergleich der LLM-Optionen entlang der fünf Auswahlkriterien.],
+) <tab_llm_vergleich>
+
+Für diese Arbeit fällt die Entscheidung auf Claude Code als primäres Werkzeug. Ausschlaggebend sind das große Kontextfenster, die native Unterstützung von Agenten und MCP-Servern sowie eine offen dokumentierte CLI für reproduzierbare Aufrufe. Die kostenseitigen und datenschutzrechtlichen Nachteile gegenüber lokalen Modellen werden durch gezielte Konfigurationsmaßnahmen adressiert. Qwen und Kimi werden für einen optionalen LLM-Querschnitt offengehalten, sind aber nicht das primäre Werkzeug.
+
+#heading(level: 2)[Untersuchungsdesign: Tooling-Ablation als kontrollierte Variation]
+
+Das Untersuchungsdesign folgt einer Ablation-Logik. Ausgehend von einer Baseline werden in jedem weiteren Versuch zusätzliche Werkzeugkomponenten hinzugefügt, sodass der Effekt jeder Komponente isoliert beobachtbar ist. Alle Versuche arbeiten auf derselben Codebasis und mit demselben Grundprompt. Variiert wird ausschließlich die Werkzeugkonfiguration. Drei Versuche bilden den Kern der Reihe, ein vierter Versuch ist optional vorgesehen.
+
+*Versuch 1 (Baseline, Prompt-only).* Reine Prompt-Steuerung ohne Agentendateien und ohne externe Tools. Die Hypothese lautet, dass eine formal strukturierte Anforderungsmenge bereits ohne Spezialisierung erreichbar ist, allerdings mit begrenzter Discovery-Breite und ohne dynamische Code- oder Datenbeobachtung.
+
+*Versuch 2 (Spezialisierung über Agenten).* Wie Versuch 1, ergänzt um rollenspezialisierte Agentendateien für Stakeholder-Analyse, System-Requirements, Software-Requirements und einen ISO-29148-Orchestrator. Die Hypothese lautet, dass Spezialisierung die Strukturierungstiefe und die Normkonformität erhöht, ohne die Discovery-Breite signifikant zu vergrößern.
+
+*Versuch 3 (Toolzugriff über MCP-Server).* Wie Versuch 2, ergänzt um strukturierten Tool-Zugriff über MCP. Vorgesehen sind drei Server für Symbol-Navigation auf Code-Ebene, für Datenbank-Inspektion auf Schema- und Datensatzebene sowie optional für GUI-Beobachtung. Die Hypothese lautet, dass strukturierter Tool-Zugriff die Discovery-Breite vergrößert und zuvor undokumentierte Use Cases sichtbar macht, allerdings zu Lasten erhöhter Steuerungskomplexität.
+
+*Versuch 4 (optional, LLM-Querschnitt).* Die in den ersten drei Versuchen wirksamste Konfiguration wird auf einem zweiten Modell wiederholt, beispielsweise auf einem lokal betriebenen Qwen oder Kimi. Ziel ist eine Einschätzung, in welchem Maße die in Versuch 1 bis 3 beobachteten Effekte modellabhängig oder werkzeugabhängig sind.
+
+#figure(
+  table(
+    columns: (auto, 1fr, 1.4fr),
+    align: (left, left, left),
+    stroke: 0.4pt,
+    [*Versuch*], [*Werkzeugkonfiguration*], [*Hypothese*],
+    [V1 Baseline], [Prompt-only, ohne Agenten, ohne Tools], [Formal strukturierte Spezifikation erreichbar, Discovery-Breite begrenzt],
+    [V2 Agenten], [Wie V1, ergänzt um rollenspezialisierte Agentendateien], [Höhere Strukturierungstiefe und Normkonformität bei vergleichbarer Breite],
+    [V3 MCP-Tools], [Wie V2, ergänzt um MCP-Server für Code, Datenbank und optional GUI], [Größere Discovery-Breite, höhere Steuerungskomplexität],
+    [V4 (optional)], [Beste Konfiguration aus V1–V3 mit alternativem Modell], [Trennung modell- gegenüber werkzeugabhängiger Effekte],
+  ),
+  caption: [Übersicht der geplanten Versuche mit Werkzeugkonfiguration und Arbeitshypothese.],
+) <tab_versuchsreihe>
+
+Konstanten und Variablen sind in jedem Versuch klar dokumentiert. Konstanten umfassen Codebasis, Grundprompt, Modellfamilie, Validierungsstichprobe und Bewertungskriterien. Variabel ist die Werkzeugkonfiguration. Damit lassen sich Unterschiede in den Ergebnissen ursächlich der Werkzeugvariation zuordnen.
+
+#heading(level: 2)[Stakeholder-Validierung als zentrales Verifikationsverfahren]
+
+Die Stakeholder-Validierung ist das zentrale Verifikationsverfahren dieser Arbeit. Sie ist nicht als nachgelagerter Schritt gedacht, sondern bildet das Maß, an dem die KI-Ergebnisse gemessen werden. Plausibel formulierte LLM-Ausgaben sind nicht hinreichend. Eine Anforderung gilt erst dann als belastbar, wenn sie durch einen Domänenexperten geprüft und bestätigt wurde.
+
+Vorgesehen sind drei bis fünf Validatoren mit jeweils mehrjähriger Erfahrung in der c-entron-Codebasis und in den fachlich abgedeckten Geschäftsprozessen. Die Auswahl orientiert sich an Modulvertrautheit, sodass alle relevanten Bereiche wie Auftragsabwicklung, Lager und Fakturierung durch mindestens einen Validator abgedeckt sind. Die Teilnehmer sind bereits identifiziert; der Interview-Leitfaden ist im Anhang dokumentiert.
+
+Für die Validierung wird pro Versuchslauf eine stratifizierte Stichprobe gezogen. Die Stratifizierung erfolgt entlang zweier Dimensionen. Erstens nach Belegart, also nach Primär-, Sekundär- und Kontextbeleg im Sinne der in den theoretischen Grundlagen eingeführten Klassifikation. Zweitens nach Risikoklasse, wobei Abrechnungs- und Berechtigungslogik mit höherer Stichprobenrate erfasst werden als periphere Funktionen. Die Stichprobengröße wird so dimensioniert, dass je Stratum mindestens 30 Anforderungen bewertet werden.
+
+Jede Anforderung wird entlang von fünf Dimensionen bewertet:
+
+- *Sachliche Korrektheit:* Beschreibt die Anforderung das tatsächliche Systemverhalten?
+- *Vollständigkeit:* Sind Akteur, Vorbedingung und Ergebnis ausreichend spezifiziert?
+- *Verständlichkeit:* Lässt sich die Anforderung ohne Rückfrage interpretieren?
+- *Redundanzfreiheit:* Ist die Anforderung von anderen klar abgegrenzt?
+- *Nützlichkeit:* Ist die Anforderung für die Migration verwertbar?
+
+Die Bewertung erfolgt auf einer fünfstufigen Likert-Skala mit definierten Ankern an den Polen, wobei 1 für „trifft nicht zu" und 5 für „trifft voll zu" steht. Bei migrationskritischen Anforderungen ist eine doppelte Bewertung durch zwei Validatoren vorgesehen, um die Inter-Rater-Reliabilität abschätzen zu können.
+
+Ergänzend zur itemweisen Bewertung werden mit den Validatoren halbstrukturierte Interviews geführt. Themenblöcke sind die Erkennung impliziter Regeln, fehlende Stakeholder-Sichten, migrationsspezifische Risiken sowie die Nützlichkeit der KI-Ergebnisse im Vergleich zu einer hypothetischen manuellen Analyse. Die Auswertung erfolgt über thematische Codierung und wird mit den itemweisen Bewertungen trianguliert.
+
+Eine Anforderung gilt im Sinne dieser Arbeit als belastbar, wenn drei Quellen sie stützen: ein konkreter Code-Beleg, eine KI-Ausgabe und eine Expertenbestätigung. Diese Triangulation reduziert das Risiko, dass eine plausibel formulierte aber inhaltlich falsche LLM-Ausgabe ungeprüft in die Spezifikation übernommen wird.
+
+#heading(level: 2)[Evaluationsrahmen]
+
+Der Evaluationsrahmen wird vor der Durchführung der Versuche definiert. Damit wird eine nachträgliche Anpassung der Kriterien an die Ergebnisse ausgeschlossen. Die Bewertung orientiert sich an den drei Qualitätsdimensionen, die in den theoretischen Grundlagen als Standard-Kriterien für Requirements-Sätze hergeleitet wurden.
+
+*Statement-Qualität.* Pro einzelner Anforderung wird gemessen, ob sie eindeutig formuliert, vollständig im Satzbau, frei von unbelegten Annahmen und mit Akzeptanzkriterium oder Prüfidee versehen ist. Die Messung erfolgt über die zuvor beschriebene Likert-Skala.
+
+*Set-Qualität.* Pro Spezifikations-Set, also Stakeholder-, System- und Software-Requirements, wird gemessen, ob die Menge konsistent, nicht redundant und ausreichend breit ist, ohne sich in Detailfällen zu verlieren. Die Messung erfolgt qualitativ durch Expertenbewertung und ergänzend durch maschinelle Konsistenzprüfungen wie doppelte IDs oder fehlende Belege.
+
+*Traceability-Qualität.* Pro Beleg-Verknüpfung wird gemessen, ob der Beleg reproduzierbar auffindbar ist, etwa über Dateipfad, Methode oder SQL-Query, und ob die Ableitung vom Beleg zur Anforderung nachvollziehbar bleibt.
+
+Ergänzend zur Qualitätsbewertung wird eine Aufwands-Kennzahl in hybrider Form erhoben. Sie kombiniert quantitative Indikatoren mit einer groben Stundenschätzung als Plausibilitätsprüfung. Indikatoren sind unter anderem Tokenkosten, Bearbeitungsdauer pro Modul und Anzahl der Validierungs-Iterationen. Die Stundenschätzung erfolgt als grobe Vergleichsangabe gegen ein hypothetisches manuelles Vorgehen, in dem ein erfahrener Analyst die gleichen Module ohne KI-Unterstützung dokumentiert hätte. Sie liefert keinen exakten Effizienzfaktor, sondern eine Größenordnung.
+
+#heading(level: 2)[Reproduzierbarkeit und Risikomanagement]
+
+Reproduzierbarkeit und Risikomanagement sind als querschnittliche Aspekte angelegt. Sie betreffen alle Versuchsdurchläufe gleichermaßen und werden hier zusammengefasst.
+
+Alle steuerungsrelevanten Artefakte werden versioniert vorgehalten. Hierzu zählen die verwendeten Prompts in ihrer Textfassung, die Agentendateien mit ihren Rollenbeschreibungen, die MCP-Server-Konfigurationen sowie die Angaben zu Modellversion, Temperatur und Kontextfenstergröße. Jeder Versuchsordner enthält die vollständige Konfiguration als Single Source. Wo möglich, werden deterministische Einstellungen gewählt.
+
+Da die Codebasis kundenbezogene Strukturen enthält, werden datenschutzkritische Werkzeuge bewusst eingegrenzt. MCP-Server für Datenbank-Inspektion und Symbol-Navigation werden lokal betrieben. An externe LLM-Anbieter werden nur diejenigen Codeausschnitte gesendet, die für den jeweiligen Analyseschritt notwendig sind. Personenbezogene Daten oder vollständige Datenexporte sind ausgeschlossen.
+
+Die folgenden vier Risikokategorien werden adressiert:
+
+- *Halluzinationen:* Begegnet durch Belegpflicht und Stakeholder-Validierung. Jede Anforderung ohne nachvollziehbaren Beleg wird als Hypothese markiert.
+- *Reproduzierbarkeitsverlust:* Begegnet durch versionierte Prompts und deterministische Einstellungen, soweit das Modell sie unterstützt.
+- *Domänen- und Datenbias:* Begegnet durch eine Stichprobenwahl, die alle relevanten Module abdeckt und nicht nur die in der KI-Ausgabe häufig auftauchenden.
+- *Datenschutzverletzungen:* Begegnet durch On-Premise-MCP, kontrollierten Versand und Logging der externen Aufrufe.
+
+#heading(level: 2)[Konkrete Konfigurationen der geplanten Versuche]
+
+Dieser Abschnitt konkretisiert die zuvor beschriebene Versuchsreihe auf Konfigurationsebene. Jeder Versuch ist durch seinen Prompt, seine Agentenliste und seine MCP-Server-Liste vollständig beschrieben. Modellversion, Kontextfenster und Temperatur werden im Versuchsordner protokolliert.
+
+#figure(
+  table(
+    columns: (auto, 1fr, 1fr, 1fr),
+    align: (left, left, left, left),
+    stroke: 0.4pt,
+    [*Element*], [*V1 Baseline*], [*V2 Agenten*], [*V3 MCP-Tools*],
+    [Modell], [Claude (Claude Code)], [Claude (Claude Code)], [Claude (Claude Code)],
+    [Grundprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt], [Standard-Extraktionsprompt],
+    [Agentendateien], [keine], [Stakeholder, System, Software, ISO-29148-Orchestrator], [Wie V2, ergänzt um codebasis-spezifische Reviewer],
+    [MCP-Server], [keine], [keine], [Symbol-Navigation, Datenbank-Inspektion, optional GUI-Beobachtung],
+    [Validierungsstichprobe], [Stratifiziert], [Stratifiziert], [Stratifiziert],
+  ),
+  caption: [Detail-Konfiguration der drei Kernversuche.],
+) <tab_versuchskonfiguration>
+
+Die Versuchsordner-Struktur folgt einer einheitlichen Konvention. Pro Versuch existiert ein Unterordner mit den Konfigurationsartefakten, ein Eingangsprotokoll mit Modell- und Werkzeugangaben, ein Ergebnis-Unterordner sowie eine Verlaufsdokumentation für die Validierungsschritte. Damit ist jeder Versuch eigenständig reproduzierbar.
+
+#heading(level: 2)[Überleitung]
+
+Mit der vorangegangenen Methodikbeschreibung ist das Untersuchungsdesign vollständig dokumentiert. Das folgende Kapitel beschreibt die Durchführung der geplanten Versuche und stellt die erzeugten Ergebnisartefakte vor. Daran schließt sich die Anwendung des hier definierten Evaluationsrahmens auf die Ergebnisse an. Den Abschluss bildet die Diskussion der gewonnenen Erkenntnisse im Hinblick auf die vier Forschungsleitfragen.