AI/ML 
Rozwój oprogramowania 
Reaktive Qualitätssicherung findet Fehler – vorausschauende Qualitätssicherung hilft, Fehlerrisiken frühzeitig zu erkennen und Probleme vor dem produktiven Einsatz zu vermeiden. VM.PL entwickelt Predictive-QA-Systeme: ML-Modelle, die aus historischen Testdaten und Fehlerberichten lernen und potenzielle Fehlerschwerpunkte vorhersagen, bevor Änderungen in Produktion gehen. Nach der 4D-Methodik, integriert in Azure DevOps/Pipelines, ohne Austausch der bestehenden Testinfrastruktur.
Was ist Predictive QA – und warum ist KI entscheidend für vorausschauende Qualitätssicherung?
Klassische Qualitätssicherung arbeitet überwiegend reaktiv: Tests werden ausgeführt, Fehler werden gefunden, behoben und dokumentiert. Predictive QA ergänzt diesen Ansatz um eine vorausschauende Risikobewertung. Das ML-Modell analysiert historische Fehlerlogs, die Codeänderungshistorie und Testergebnisse und berechnet einen Risikoscore für einzelne Codemodule, bevor ein neuer Build in Produktion geht.
| Kriterium | Reaktive QA (klassisch) | Predictive QA mit KI (VM.PL) |
| Ziel | Fehler finden, nachdem sie entstanden sind | Potenzielle Fehlerschwerpunkte frühzeitig erkennen und priorisieren |
| Grundlage | Testfälle und Testplanung durch das QA-Team | ML-Modell lernt anhand historischer Fehler-Logs |
| Test-Priorisierung | Priorisierung anhand definierter Kriterien oder manueller Bewertung | ML priorisiert Tests anhand des prognostizierten Fehlerrisikos – besonders kritische Tests zuerst |
| Ressourcen | Testaufwand wird anhand bestehender Testpläne verteilt | QA-Team konzentriert sich verstärkt auf Bereiche mit hohem Risiko |
| Fehler-Erkennung | Reaktiv nach Code-Änderung | Proaktiv: Risikobewertung nach Codeänderungen in Azure Pipelines |
Forschungsarbeiten zur KI-gestützten Qualitätssicherung zeigen, dass Verfahren zur Mustererkennung auch komplexe Fehlerzusammenhänge analysieren können, die sich mit klassischen Regeln nur schwer beschreiben lassen. Predictive QA überträgt dieses Prinzip auf das Softwaretesting und die risikobasierte Testpriorisierung.
Wie verwendet VM.PL Machine Learning für Testautomatisierung und Fehlerprognose?
Das ML-Modell analysiert drei Datenquellen: historische Testlogs, Fehlerberichte aus dem Bugtracker und die Codeänderungshistorie (Git-Commits). Aus der Kombination dieser Signale kann es einen Risikoscore für jedes relevante Codemodul berechnen, der nach einem Commit im Dashboard angezeigt wird.
VM.PL setzt je nach Use Case drei ML-Methoden ein:
- Klassifikation: Das Modell berechnet für jedes Codemodul eine geschätzte Fehlerwahrscheinlichkeit auf Basis von Änderungsfrequenz, historischer Fehlerrate und Abhängigkeitstiefe.
- Zeitreihen-ML: Das Modell erkennt zeitliche Muster – wann treten Fehler typischerweise nach bestimmten Änderungstypen auf? Relevant für die Releaseplanung und die Festlegung von Code-Freeze-Phasen.
- Clustering: Das Modell gruppiert wiederkehrende Fehlermuster und identifiziert strukturell ähnliche Fehlerquellen – auch über verschiedene Releases hinweg.
| ML-Methode | Anwendungsfall | Datenvoraussetzung |
| Klassifikation (XGBoost) | Fehlerwahrscheinlichkeit pro Code-Modul nach Commit | Bugtracker + Git-Historie, als Orientierungswert mindestens 6 Monate |
| Zeitreihen-ML (LSTM) | Wann treten Fehler nach bestimmten Änderungstypen auf? | Testergebnisse mit Zeitstempeln, als Orientierungswert mindestens 12 Monate |
| Clustering (K-Means) | Strukturell ähnliche Fehlermuster identifizieren | Fehler-Beschreibungen + Code-Diff-Daten |
| Anomalie-Erkennung | Unbekannte Fehlermuster im laufenden Betrieb erkennen | Referenzdaten aus bisherigen Testläufen |
Der tatsächliche Datenbedarf hängt von der Anzahl der Änderungen, der Fehlerhäufigkeit und der Qualität der vorhandenen Testhistorie ab. Die genannten Zeiträume dienen als Orientierungswerte.
Wie integriert VM.PL Predictive QA in bestehende CI/CD-Pipelines?
Die bestehende Testsuite bleibt vollständig erhalten. VM.PL fügt ein Predictive-QA-Gate als zusätzlichen Schritt in Azure Pipelines ein: Nach jedem Commit analysiert der ML-Service den Kontext der Codeänderungen und gibt eine priorisierte Testliste aus. Tests mit hohem prognostiziertem Fehlerrisiko werden zuerst ausgeführt. Dadurch erhalten Entwicklungsteams früher Feedback zu besonders kritischen Bereichen. Eine Verkürzung der gesamten Pipeline-Laufzeit hängt von der gewählten Teststrategie ab.
Technische Integration:
- Azure DevOps / Azure Pipelines: Predictive-QA-Gate als YAML-Schritt – Integration in die bestehende Pipeline mit möglichst geringem Anpassungsaufwand.
- ML-Service: Python-basierter FastAPI-Service in Azure Container Apps – skalierbar und für eine hochverfügbare Bereitstellung konfigurierbar.
- Azure Application Insights: Monitoring der Predictive-QA-Entscheidungen und relevanter Modellkennzahlen – nachvollziehbar für Auditzwecke.
- Roll-Back: Das Predictive-QA-Gate kann deaktiviert werden, ohne die bestehende Testlogik zu ersetzen. Die ursprünglichen Testprozesse bleiben weiterhin verfügbar.
Wie bewertet VM.PL die Genauigkeit des Predictive-QA-Modells – Precision, Recall und Threshold-Kalibrierung?
Jedes Predictive-QA-Modell kann zwei Arten von Fehlklassifikationen erzeugen: False Positives (Module werden als riskant eingestuft, obwohl sie keine relevanten Fehler enthalten) und False Negatives (fehlerhafte Module werden vom Modell nicht als riskant erkannt). Welcher Fehlertyp die größeren Auswirkungen hat, hängt vom Kontext ab – und bestimmt die Wahl des Entscheidungsschwellenwerts.
| Kennzahl | Bedeutung | Typische Zielwerte bei VM.PL |
| Precision | Anteil der als riskant markierten Module, die tatsächlich Fehler enthalten. Hohe Precision = weniger unnötige Tests. | Je nach Kontext kann eine Precision von mindestens 70 % angestrebt werden; bei hohem Testaufwand pro Modul gegebenenfalls mehr |
| Recall | Anteil der tatsächlich fehlerhaften Module, die das Modell erkennt. Hoher Recall = weniger Fehler in Produktion. | Beispielhafte Zielgrößen: mindestens 90 % in besonders kritischen Szenarien und mindestens 80 % bei weniger kritischen Anwendungen. Die Eignung hängt von den konkreten Sicherheitsanforderungen ab |
| F1-Score | Harmonisches Mittel aus Precision und Recall – wichtig bei unausgewogenen Klassenverteilungen (wenige fehlerhafte Module) | Mögliche primäre Optimierungsmetrik im Architecture Blueprint der Definition-Phase |
| AUC-ROC | Maß für die Trennfähigkeit des Modells über verschiedene Entscheidungsschwellenwerte hinweg – 1,0 = perfekte Trennung, 0,5 = Zufallsniveau | Beispielhafter Zielwert für den Produktionseinsatz: mindestens 0,80 |
Threshold-Kalibrierung: VM.PL kalibriert den Entscheidungsschwellenwert gemeinsam mit dem QA-Team – abhängig von Testaufwand pro Modul, Fehlerkosten in Produktion und Release-Zeitdruck. Der Threshold ist konfigurierbar und kann bei entsprechender technischer Umsetzung über eine Azure-Pipeline-Variable ohne Redeployment angepasst werden.
Wie erkennt VM.PL Datendrift und hält das Predictive-QA-Modell aktuell?
Ein Predictive-QA-Modell, das auf Fehlermustern von vor zwölf Monaten basiert, muss nicht mehr optimal zur aktuellen Codebasis passen. Neue Technologien, geänderte Architekturmuster oder Veränderungen in der Teamzusammensetzung können die Fehlercharakteristik beeinflussen. Unter Datendrift versteht man Veränderungen in der statistischen Verteilung der Eingabedaten gegenüber der ursprünglichen Trainingsbasis.
Drei Ebenen des Drift-Managements:
- Drift-Erkennung:Ein geeignetes Monitoring-System vergleicht laufend die statistische Verteilung der Modelleingaben (Codeänderungsparameter, Abhängigkeitstiefe, historische Fehlerrate) mit der Trainingsbasis. Azure Application Insights kann dabei zur Erfassung und Visualisierung relevanter Monitoring-Daten eingesetzt werden. Signifikante Abweichungen lösen einen Drift-Alert aus – konfigurierbar nach Schwellenwert und Zeitfenster.
- Re-Training-Trigger: VM.PL implementiert zwei Aktualisierungsstrategien: zeitbasiert (automatisches Update alle n Releases) und ereignisbasiert (ein Drift-Alert kann einen erneuten Trainingsprozess auslösen). Neues Trainingsmaterial sind die zuletzt abgeschlossenen Releases – das Modell kann so mit aktuellen Fehlermustern aktualisiert werden.
- Modell-Versionierung und Rollback: Jedes Re-Training erzeugt eine neue Modellversion mit eigenem Evaluierungsbericht. Das Deployment erfolgt kontrolliert über Azure Pipelines – bei schlechterer Performance als die Vorgängerversion kann auf das vorherige Modell zurückgewechselt werden. Vor dem produktiven Einsatz wird die Modellqualität anhand festgelegter Kriterien geprüft.
- Mindestdatenbasis für Re-Training: Als Orientierungswert können die letzten 3–6 Releases oder etwa 6 Monate Fehlerlogs herangezogen werden. Der tatsächliche Bedarf hängt von der Releasefrequenz und Fehlerhäufigkeit ab. Die Discovery-Phase definiert den Mindestdatenbedarf für den spezifischen Kontext.
Mindest-Datenbasis für Re-Training: typischerweise die letzten 3-6 Releases oder 6 Monate Fehler-Logs – je nach Releasekadenz und Fehlerfrequenz. Die Discovery-Phase definiert den Mindest-Datenbedarf für den spezifischen Kontext.
Für welche Test-Ebenen eignet sich Predictive QA – Unit Tests, Integration, Regression und Mutation Testing?
Predictive QA ist keine Methode für eine einzelne Testebene – sie kann die risikobasierte Priorisierung über mehrere Ebenen der Testpyramide hinweg unterstützen. Je nach Datenlage und Projektkontext setzt VM.PL unterschiedliche Schwerpunkte.
| Test-Ebene | Predictive-QA-Anwendung | Datenbasis |
| Unit Tests | ML priorisiert die Ausführung von Unit Tests anhand des prognostizierten Fehlerrisikos der geänderten Funktionen. Bei selektiver Testausführung können zunächst Tests für geänderte und abhängige Funktionen gestartet werden | Git-Diff + historische Fehlerquote der Unit Tests |
| Integrations-Tests | ML erkennt, welche Schnittstellenveränderungen historisch zu Integrations-Fehlern geführt haben. API-Versionsvergleich als zusätzliches Signal. | API-Change-Log + Integrations-Fehler-Historie |
| Regressionstests | Test Impact Analysis: ML identifiziert die Regressionstests, die mit hoher Wahrscheinlichkeit von einer Codeänderung betroffen sind. Vollständige Regressionsläufe können zusätzlich vor einem Release durchgeführt werden | Abdeckungsmatrix (Coverage-Map) + Fehlerhistorie |
| Mutation Testing | ML identifiziert Module mit geringer Wirksamkeit der vorhandenen Tests (niedriger Mutation Score) – gezielte Nacharbeit statt flächendeckendem Mutation Testing | Entwicklung des Mutation Scores über mehrere Releases |
Shift-Left-Prinzip: Predictive QA unterstützt den Shift-Left-Ansatz, indem Risikosignale möglichst früh im Entwicklungsprozess verfügbar gemacht werden. VM.PL integriert den Risk-Score als Entwicklerfeedback direkt in den Pull-Request-Prozess – sichtbar im Azure-DevOps-PR-Dashboard, bevor der Code in den Hauptbranch übernommen wird.
Wie erklärt VM.PL Predictive-QA-Entscheidungen – Erklärbarkeit und SHAP für QA-Teams?
Ein Risikoscore ohne Erklärung ist für QA-Engineers nur eingeschränkt nutzbar: Sie müssen wissen, warum ein Modul als hochriskant eingestuft wird, um gezielt zu testen und Entwickler fundiert zu informieren. VM.PL integriert SHAP-basierte Erklärungsverfahren, um die Einflussfaktoren der Modellvorhersagen nachvollziehbar zu machen.
Drei Ebenen der Erklärbarkeit:
- SHAP Feature Importance (global): Über alle Modellvorhersagen hinweg zeigen SHAP-Werte, welche Eingabemerkmale den größten Einfluss auf die Fehlerwahrscheinlichkeit haben. Mögliche Einflussfaktoren sind die Änderungsfrequenz eines Moduls, die Tiefe seiner Abhängigkeiten, die Zeit seit dem letzten Test und die historische Fehlerrate. Die Ergebnisse werden im Architecture Blueprint dokumentiert und nach jedem Re-Training aktualisiert.
- SHAP für einzelne Predictions (lokal): Für jedes als riskant eingestufte Modul zeigt das Dashboard, welche konkreten Faktoren den Risikoscore beeinflussen. Ein illustratives Beispiel: Ein Modul erhält einen Risikoscore von 0,87. Als Einflussgrößen werden zwölf Änderungen innerhalb der letzten sieben Tage, eine Abhängigkeitstiefe von acht und eine historische Fehlerquote von 34 % identifiziert. QA-Engineers sehen auf einen Blick, worauf sich die Tests konzentrieren sollten.
- Audit-Trail für regulierte Bereiche: Predictive-QA-Entscheidungen können zusammen mit ihren SHAP-Erklärungen protokolliert und für interne Reviews sowie gegebenenfalls regulatorische Nachweise dokumentiert werden. Welche Dokumentations- und Nachweispflichten gelten, hängt vom Anwendungsfall und den einschlägigen Vorschriften ab, beispielsweise im Kontext von ISO 26262 oder dem EU AI Act.
Wie korreliert Predictive QA mit technischen Schulden und Code-Komplexität?
Technische Schulden und hohe Codekomplexität können wichtige Indikatoren für ein erhöhtes Fehlerrisiko sein. Das ML-Modell kann diese Zusammenhänge anhand historischer Daten analysieren und quantifizierbar machen. Predictive QA verbindet damit QA-Priorisierung und die Analyse technischer Schulden zu einem integrierten Signal.
Vier Komplexitäts-Features als ML-Inputs:
- Zyklomatische Komplexität: McCabe-Komplexität je Funktion und Modul – eine hohe Komplexität kann mit einer erhöhten Fehleranfälligkeit einhergehen. VM.PL extrahiert diesen Wert aus Werkzeugen zur statischen Codeanalyse (beispielsweise SonarQube-kompatiblen Tools) und führt ihn als Merkmal in das ML-Modell ein.
- Code Churn: Wie oft wurde ein Modul in den letzten n Releases verändert? Eine hohe Änderungsfrequenz in Kombination mit niedriger Testabdeckung kann auf ein erhöhtes Fehlerrisiko hinweisen. Code-Churn-Metriken werden direkt aus der Git-Historie extrahiert..
- Abhängigkeits-Coupling: Module mit vielen eingehenden und ausgehenden Abhängigkeiten (hoher Fan-In/Fan-Out) können bei Änderungen ein erhöhtes Risiko für Folgefehler aufweisen. Die Analyse der Abhängigkeitsgraphen erfolgt automatisch über statische Codeanalyse und fließt als Kopplungsmerkmal ins ML-Modell ein.
- Test-Coverage-Defizite: Module mit geringer Unit-Test-Abdeckung können bei vergleichbarer Änderungsfrequenz einen höheren Risikoscore erhalten, weil potenzielle Fehler dort seltener durch automatisierte Tests erkannt werden. Coverage-Daten stammen aus Azure-Pipelines-Coverage-Reports und werden automatisch normalisiert.
Synergieeffekt: Predictive QA hilft, Risiken im Zusammenhang mit technischen Schulden frühzeitig sichtbar zu machen. Teams erhalten eine datenbasierte Priorisierung für Refactoring-Maßnahmen – auf Grundlage prognostizierter Fehlerrisiken statt ausschließlich subjektiver Einschätzungen.
Welche regulatorischen und Qualitätsnormen berücksichtigt VM.PL bei Predictive QA – ISTQB, ISO 29119 und EU AI Act?
Für QA-Teams in regulierten Branchen können zusätzliche Anforderungen an die Dokumentation, Nachvollziehbarkeit und Validierung von Predictive-QA-Systemen gelten. VM.PL prüft in der Definition-Phase, welche Standards relevant sind, und richtet das QA-System entsprechend aus.
| Standard / Norm | Anforderung an Predictive QA | VM.PL-Umsetzung |
| ISTQB CT-AI (Certified Tester) | Orientierungsrahmen für Kompetenzen und Methoden beim Testen KI-basierter Systeme, einschließlich Testdatenqualität, Transparenz und menschlicher Bewertung | Validierungsschicht für Modellergebnisse · menschliche Überprüfung kritischer Entscheidungen · SHAP-basierte Erklärungen, soweit geeignet |
| ISO 29119 (Software Testing) | Strukturierte Testprozesse: Testplanung, Testdesign und Dokumentation der Testergebnisse sollen reproduzierbar und nachvollziehbar sein | Automatische Testreports · vollständige Testhistorie durch geeignete Protokollierung und Ablage · Audit-Trail für relevante ML-Entscheidungen |
| EU AI Act (High Risk) | Für KI-Systeme, die als Hochrisiko-KI eingestuft werden, gelten spezifische Anforderungen, unter anderem an technische Dokumentation, Transparenz und menschliche Aufsicht. Die Einstufung hängt vom vorgesehenen Verwendungszweck ab | SHAP-basierter Erklärbarkeitsbericht · menschliche Freigabe, sofern erforderlich · Modellversionsprotokoll |
| ISO 26262 / ASIL (Automotive) | Safety-Critical Testing: Nachvollziehbarkeit von Anforderungen und Testergebnissen sowie geeignete Verifikations- und Freigabeprozesse für sicherheitsrelevante Funktionen | Traceability zwischen Anforderungen und Tests · Berücksichtigung der ASIL-Anforderungen · menschliche Freigabe sicherheitskritischer Entscheidungen |
| DSGVO bei Testdaten | Personenbezogene Daten im Testumfeld müssen auf einer geeigneten Rechtsgrundlage verarbeitet und angemessen geschützt werden. Pseudonymisierte oder synthetische Daten können Risiken reduzieren | Synthetische Testdaten-Generierung · Pseudonymisierung als Standard · On-Premise-Option |
Welchen geschäftlichen Mehrwert bringt Predictive QA – Zeit, Kosten, Stabilität?
Drei messbare Effekte, die sich in der Praxis direkt beziffern lassen:
- Kürzere Test-Laufzeiten: Wenn kritische Tests priorisiert und nicht kritische Tests später ausgeführt werden, kann die Zeit bis zum ersten relevanten Testergebnis reduziert werden. Werden zusätzlich geeignete Tests selektiv ausgeführt, lässt sich unter bestimmten Voraussetzungen auch die gesamte Pipeline-Laufzeit verkürzen. Weniger Zeit zwischen Commit und Feedback beschleunigt Entwicklungszyklen.
- Frühere Fehler-Erkennung: Fehler in der Entwicklungsphase zu beheben kann deutlich kostengünstiger sein, als sie erst nach dem produktiven Einsatz zu korrigieren. In häufig zitierten Kostenmodellen werden je nach Entdeckungsphase Faktoren zwischen 6 und 100 genannt. Diese Werte sind als historische Orientierungsgrößen und nicht als allgemeingültige Kostengarantie zu verstehen. Predictive QA unterstützt dabei, besonders fehleranfällige Bereiche früher zu identifizieren.
- Stabilere Releases: Durch gezielte intensivere Tests der Hochrisikobereiche vor einem Release können potenzielle Probleme früher erkannt werden. Dies kann die Anzahl produktiver Fehler und den Bedarf an nachträglichen Hotfixes reduzieren.
Ressourcenoptimierung: QA-Engineers konzentrieren ihre Arbeit auf Bereiche mit dem höchsten prognostizierten Fehlerrisiko. Die automatisierte Analyse historischer Testdaten reduziert wiederkehrende manuelle Auswertungen. Dadurch bleibt mehr Zeit für komplexe Tests und die fachliche Bewertung kritischer Ergebnisse.
Wie sieht das 4D-Vorgehen bei VM.PL für Predictive QA aus?
Die Discovery-Phase bewertet zuerst die verfügbare Datenbasis. Für die Entwicklung eines zuverlässigen Predictive-QA-Modells müssen ausreichend aussagekräftige historische Test- und Fehlerdaten vorhanden sein. VM.PL prüft daher zunächst deren Verfügbarkeit, Qualität und Eignung für den konkreten Anwendungsfall.
| Phase | Aktivitäten | Deliverable | Dauer |
| Discovery | Fehler-Log-Analyse · CI/CD-Audit · Datenbasis-Bewertung · Use-Case-Validierung | Concept Document (Go/No-Go) | 1 Woche |
| Definition | ML-Architektur · Pipeline-Integrations-Plan · Threshold-Kalibrierung · Normen-Prüfung · Monitoring-Konzept | Architecture Blueprint | 1 Woche |
| Delivery | ML-Training · Azure-Pipeline-Integration · Dashboard-Setup (SHAP) · Abnahme | Produktives Predictive-QA-System | 4-8 Wochen |
| Direction | Modell-Monitoring · Drift-Erkennung · Re-Training bei neuen Fehlermustern · Accuracy-Drift | Entwicklungs-Roadmap | laufend |
Warum VM.PL für Predictive QA?
VM.PL entwickelt individuelle KI- und ML-Lösungen, die auf die vorhandene IT-Landschaft, Datenbasis und Qualitätsanforderungen eines Unternehmens abgestimmt sind. Dabei stehen die Integration in bestehende Entwicklungsprozesse, die Nachvollziehbarkeit von Entscheidungen und eine langfristig wartbare Architektur im Mittelpunkt. Fünf Differenzierungsmerkmale:
- Azure-Stack-Kompetenz: Azure DevOps, Azure Pipelines, Azure Application Insights und Azure Container Apps als integrierte Plattform – bestehende Microsoft-Umgebungen können genutzt und der zusätzliche Integrationsaufwand dadurch reduziert werden.
- Individuelle ML-Modelle auf Unternehmensdaten: Das ML-Modell wird anhand der tatsächlichen Fehlerhistorie des Unternehmens entwickelt, nicht ausschließlich anhand generischer Trainingsdaten. Dadurch können projektspezifische Fehlermuster und technische Besonderheiten berücksichtigt werden.
- Erfahrung mit KI-gestützter Softwarequalität und Sicherheit: VM.PL setzte Claude Code bei der Modernisierung eines bestehenden Building-Management-Systems (BMS) ein. Im Rahmen des Projekts wurden 87 Sicherheitslücken identifiziert und behoben. KI unterstützte unter anderem die Analyse des bestehenden Systems und die Vorbereitung der Modernisierung, während kritische Architekturentscheidungen und Tests von erfahrenen Ingenieuren verantwortet wurden. Der Projektaufwand konnte um 260 Arbeitsstunden reduziert werden. Referenz: KI-gestützte Modernisierung und Sicherheitstests eines BMS-Systems.
- Kein Vendor-Lock-in: VM.PL setzt auf individuell entwickelte Lösungen und transparente Architekturentscheidungen. Nutzungsrechte an Quellcode, Modellgewichten und Pipeline-Konfigurationen sowie mögliche Lizenzkosten werden projektspezifisch vereinbart.
- Nearshore-Effizienz: Wrocław, Polen – gut erreichbar aus dem DACH-Raum, deutschsprachige Zusammenarbeit, Unternehmensstandort innerhalb der EU und persönliche Vor-Ort-Termine nach Vereinbarung.
Einstieg: In einem ersten unverbindlichen Discovery-Gespräch besprechen wir die vorhandene Fehlerhistorie, die eingesetzten Testwerkzeuge und die Anforderungen an eine mögliche Predictive-QA-Lösung. Darauf aufbauend können ein Fehlerlog-Audit und ein Concept Document zur Bewertung der technischen Machbarkeit und Datenqualität erstellt werden.