kap 4+5 added

Kapitel/03_fallstudie.typ

@@ -1,5 +1,101 @@
+#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)[Fallstudie c-entron GmbH (ca. 6 Seiten)]
 
+Dieses Kapitel beschreibt den Anwendungskontext der Arbeit in Form einer Fallstudie. Im Mittelpunkt steht eine gewachsene, Windows-basierte ERP-Software der c-entron GmbH, die im Rahmen einer Modernisierung auf eine webbasierte Plattform überführt werden soll. Ziel des Kapitels ist es, die fachlichen und technischen Rahmenbedingungen so zu strukturieren, dass die Anforderungen an ein KI-gestütztes Reverse Requirements Engineering nachvollziehbar werden. Dazu werden zunächst Unternehmenskontext und Legacy-Software eingeordnet und anschließend die Migrationsstrategie sowie die spezifischen Herausforderungen zusammengefasst.
+
 #heading(level: 2)[Unternehmenskontext und Legacy-Software]
 
+#heading(level: 3)[Unternehmens- und Domänenkontext]
+
+Die c-entron GmbH (Ulm) wird in dieser Arbeit als Fallunternehmen betrachtet. Das Unternehmen entwickelt und betreibt eine ERP-Suite, die sich an IT-Systemhäuser und deren typische Abläufe richtet. Im Vergleich zu neu entstehenden SaaS-Produkten ist die betrachtete Lösung über einen langen Zeitraum in einem stabilen Marktsegment gereift. Damit ist der Funktionsumfang breit, zugleich ist die Implementierung historisch gewachsen und enthält produktionsnahe Randfälle, Ausnahmen und kundenbezogene Varianten.
+
+Für den Kontext dieser Arbeit sind drei Aspekte wesentlich:
+
+- **Geschäftskritische Domäne:** ERP-Systeme bilden Kernprozesse ab. Änderungen wirken direkt auf Abrechnung, Lieferfähigkeit und Projektsteuerung.
+- **Hohe Integrationsdichte:** ERP-Funktionen sind typischerweise über Schnittstellen, Datenimporte/-exporte und angebundene Drittsysteme mit weiteren Anwendungen gekoppelt.
+- **Regel- und Datenorientierung:** Ein großer Teil der Logik manifestiert sich in Validierungen, Statusübergängen, Berechtigungsprüfungen und Datenmodellrestriktionen.
+
+Die Software deckt nach vorliegendem Projektkontext unter anderem Auftragsabwicklung, Lagerfunktionen, Fakturierung sowie Projektabrechnung ab. Für die Modernisierung ist daher nicht nur die Rekonstruktion einzelner Masken oder Funktionen relevant, sondern vor allem die Ableitung stabiler Geschäftsregeln und Datenbeziehungen, die als Basis für eine webbasierte Neuimplementierung dienen.
+
+#heading(level: 3)[Technologischer Ist-Stand (Legacy-Charakteristik)]
+
+Die betrachtete ERP-Suite ist als Windows-basierte Anwendung in einer klassischen Client/Server-Architektur gewachsen. Aus Sicht der Modernisierung ist weniger das „Alter“ entscheidend als die Kombination aus technischer Kopplung, historischer Evolution und begrenzter Dokumentation. Diese Merkmalskombination ist typisch für Legacy-Systeme @bisbal1999legacy.
+
+Für die Fallstudie lassen sich die folgenden, für Requirements-Rückgewinnung relevanten Charakteristika bündeln:
+
+- **Enge Kopplung zwischen UI, Fachlogik und Persistenz:** Geschäftsregeln sind nicht konsistent in einer Schicht isoliert, sondern verteilen sich über unterschiedliche Komponenten.
+- **Implizite Regeln in Code und Daten:** Ein Teil der Anforderungen ist nicht explizit dokumentiert, sondern ergibt sich aus Validierungen, Prüfpfaden, Standardwerten und Datenmodellannahmen.
+- **Evolution über lange Zeiträume:** Funktionserweiterungen und Fehlerkorrekturen führen zu Sonderfällen und Workarounds, die fachlich begründet sein können, aber selten als Requirements festgehalten sind.
+- **Heterogene Artefakte:** Neben Quellcode existieren Konfigurationen, UI-Texte, Reportdefinitionen, Skripte oder Import-/Exportlogiken, die Anforderungen indirekt spiegeln.
+
+In der Summe ist der Ist-Zustand damit ein realitätsnaher Prüfstand für Reverse Requirements Engineering: Die Anforderungen liegen nicht als konsolidierte Spezifikation vor, sondern müssen aus einem Bündel technischer Artefakte rekonstruiert und anschließend fachlich validiert werden.
+
+#heading(level: 3)[Dokumentations- und Wissenslage]
+
+Für das betrachtete Modernisierungsvorhaben ist die Ausgangslage geprägt durch fehlende oder nur teilweise gepflegte Anforderungsdokumentation. In Standards des Requirements Engineering wird eine nachvollziehbare Spezifikation mit Qualitätskriterien wie Eindeutigkeit, Verifizierbarkeit und Traceability als Zielbild beschrieben @iso29148_2018 @ieee830_1998. Im Fallunternehmen sind solche Artefakte nicht in ausreichender Tiefe verfügbar, sodass wesentliche Informationen in folgenden Quellen gebunden sind:
+
+- **Implementierung und Laufzeitverhalten:** Fachliche Regeln werden praktisch durch Codepfade und Datenzustände realisiert.
+- **Change-Historie und Tickets:** Änderungsanlässe, Bugfixes und Kundenanpassungen sind häufig über Issue-Tracker, Commits oder Releases rekonstruierbar.
+- **Erfahrungswissen einzelner Mitarbeiter:** Domänenwissen ist personenbezogen und damit ein Risiko bei Personalwechsel.
+
+Für die vorliegende Arbeit folgt daraus, dass der Wert eines KI-gestützten Reverse Requirements Engineering nicht in der Generierung „gut klingender“ Spezifikationstexte liegt, sondern in der systematischen Extraktion belegbarer Aussagen, die als Requirements prüfbar sind und die spätere Migration absichern.
+
+#heading(level: 3)[Relevante Artefakte der Fallstudie]
+
+Für die Anforderungen an das Vorgehen in späteren Kapiteln ist es hilfreich, den Artefaktraum der Fallstudie zu strukturieren. Im Kontext der ERP-Modernisierung sind insbesondere folgende Artefaktklassen als Requirements-Träger relevant:
+
+1. **Quellcode:** Implementierte Regeln, Berechtigungen, Statuslogik, Datenzugriffe.
+2. **Konfiguration und Parameter:** Feature-Schalter, Mandantenparameter, systemweite Defaults.
+3. **UI- und Reportartefakte:** Feldbezeichnungen, Validierungstexte, Druck-/Exportformate.
+4. **Datenstrukturbezogene Artefakte:** Datenmodelle, Constraints, Referenzen, historisierte Strukturen.
+5. **Projektartefakte:** Tickets, Release Notes, Testfälle, Migrationsnotizen.
+
+Diese Artefakte sind nicht gleichwertig. Für Requirements-Rückgewinnung ist entscheidend, dass Belege in ihrer Aussagekraft bewertet und im Prozess sichtbar gemacht werden. Damit wird die fachliche Validierung gezielt auf risikoreiche oder unsichere Aussagen gelenkt.
+
 #heading(level: 2)[Migrationsstrategie und spezifische Herausforderungen]
+
+#heading(level: 3)[Zielbild der Modernisierung]
+
+Das Modernisierungsziel ist eine webbasierte Plattform, die plattformunabhängige Nutzung und modernere Betriebsmodelle unterstützt. Damit verschiebt sich der Schwerpunkt von einer rein funktionalen Betrachtung hin zu einem Zusammenspiel aus Funktionsäquivalenz und nicht-funktionalen Zielgrößen, insbesondere im Bereich Betrieb, Sicherheit und Änderbarkeit. Das Qualitätsmodell ISO/IEC 25010:2011 bietet hierfür eine etablierte Taxonomie, um solche Zielgrößen systematisch zu erfassen @iso25010_2011.
+
+Aus Sicht des Fallunternehmens ist das Zielbild in drei Dimensionen zu konkretisieren:
+
+- **Benutzeroberfläche und Interaktion:** Webbasierte Oberflächen, Rollen- und Rechtekonzepte, konsistente Navigation.
+- **Betriebsmodell und Deployment:** Automatisierte Bereitstellung, Skalierung, Updatefähigkeit und Wartbarkeit über Releases.
+- **Integrationen und Daten:** Stabilisierung von Schnittstellen, Datenmigration und Sicherstellung konsistenter Geschäftsobjekte.
+
+#heading(level: 3)[Strategische Optionen und Abgrenzung]
+
+Die Literatur zur Legacy-Modernisierung betont, dass Migrationen unterschiedliche Strategien annehmen können und dass eine bewusste Planung notwendig ist, um Risiken zu steuern @sneed1995planning @bisbal1997overview. In der Praxis reichen Optionen von minimal-invasiven Ansätzen (z. B. Rehosting) bis zur schrittweisen Neuimplementierung zentraler Funktionen. Für diese Arbeit ist weniger die vollständige Migrationsplanung Gegenstand, sondern die Frage, wie eine belastbare Requirementsbasis für die Umsetzung erzeugt wird.
+
+Die Abgrenzung des Beitrags lautet daher:
+
+- Schwerpunkt ist die **Rückgewinnung und Strukturierung** von Requirements aus bestehenden Artefakten.
+- Architektur- und Implementationsentscheidungen der Zielplattform werden nur soweit diskutiert, wie sie Requirements beeinflussen (z. B. Sicherheits- und Betriebsanforderungen).
+- Die eigentliche technische Migration (Datenmigration, Refactoring im Detail, Release-Planung) wird als Rahmenbedingung verstanden und in späteren Kapiteln methodisch adressiert.
+
+#heading(level: 3)[Spezifische Herausforderungen im Fallunternehmen]
+
+Die Fallstudie weist mehrere Herausforderungen auf, die für die Methodik des Reverse Requirements Engineering unmittelbar relevant sind. Die folgenden Punkte bündeln die zentralen Problemfelder und leiten Anforderungen an das Vorgehen ab:
+
+- **Funktionsäquivalenz und Randfälle:** Ein großer Teil des Systemwertes liegt in korrekt implementierten Ausnahmen, Sonderfällen und Prozessvarianten. Diese sind im Code sichtbar, aber selten dokumentiert. Daraus folgt eine hohe Priorität für Traceability und Validierung.
+- **Implizite Geschäftsregeln:** Geschäftslogik ist häufig als Prüf- und Statuslogik realisiert. Ohne strukturierte Extraktion besteht das Risiko, dass Regeln in der Neuimplementierung vereinfacht oder falsch interpretiert werden.
+- **Datenzentrierte Domäne:** ERP-Funktionalität ist eng mit Datenobjekten, Relationen und historisierten Zuständen gekoppelt. Anforderungen müssen daher nicht nur UI-nah formuliert werden, sondern auch als Daten- und Integritätsanforderungen.
+- **Nicht-funktionale Anforderungen rücken in den Vordergrund:** Mit einer webbasierten Zielplattform steigen Anforderungen an Sicherheitsmechanismen, Verfügbarkeit, Rollout-Fähigkeit und Observability. Studien zu Security-Aspekten in Legacy-to-Cloud-Migrationen zeigen, dass Identitätsmanagement, Datenflusskontrolle und Compliance wiederkehrende Kernprobleme sind @security2014legacycloud.
+- **Organisatorische Randbedingungen:** Ressourcen für manuelle Analyse sind begrenzt und hängen von erfahrenen Mitarbeitern ab. Daraus folgt die Notwendigkeit, Analysearbeit skalierbar zu machen und Ergebnisse reproduzierbar zu erzeugen.
+
+#heading(level: 3)[Konsequenzen für das Vorgehen in dieser Arbeit]
+
+Aus den genannten Herausforderungen ergeben sich konkrete Anforderungen an das in Kapitel 4 entwickelte Vorgehen:
+
+1. **Belegpflicht und Nachvollziehbarkeit:** Jede extrahierte Anforderung muss auf Artefakte zurückgeführt werden können (Datei, Modul, Datenobjekt, UI-Text).
+2. **Explizite Unsicherheitskennzeichnung:** Aussagen, die nicht eindeutig aus Artefakten ableitbar sind, müssen als Hypothesen markiert und priorisiert validiert werden.
+3. **Segmentierung und Kontextsteuerung:** Da Artefakte verteilt sind, ist eine systematische Auswahl relevanter Kontexte notwendig, um Überinterpretation zu reduzieren.
+4. **Human-in-the-loop:** Fachliche Validierung ist zwingend, da „plausible“ Textausgaben kein hinreichender Beweis für fachliche Korrektheit sind.
+
+Damit schafft dieses Kapitel die Grundlage für die folgenden Abschnitte: Kapitel 4 beschreibt das methodische Vorgehen und das Prozessmodell, Kapitel 5 überführt es in einen Prototyp, und Kapitel 6 evaluiert die Eignung im Fallkontext der c-entron GmbH.