1. Anforderungen

Dieses Dokument beschreibt die technische Umsetzung des Vendor Resource Pool (VRP) — einer zentralen Web-Plattform, die Generalunternehmer dabei unterstützt, bei kurzfristigen Teilabrufen sekundenschnell passende IT-Fachkräfte aus ihrem Partner-Netzwerk zu identifizieren und direkt anzufragen. Das Dokument dient als verbindliche Grundlage für Architekturentscheidungen, Technologiewahl und Vorgehensmodell im Rahmen der Umsetzung.

1.1 Qualitätsziele

Benutzerfreundlichkeit & Akzeptanz

Die Akzeptanz der Plattform hängt direkt davon ab, wie wenig Aufwand sie für Partner-Manager verursacht. Drag-and-Drop-Upload für Experten-Profile und tokenbasierte Quick-Update-Links, die ohne Login-Schritt funktionieren, sind bewusste Designentscheidungen: Je geringer die Hürde zur Datenpflege, desto vollständiger und aktueller die Verfügbarkeitsdaten — und desto höher der Wert der Plattform für den GU-Resource-Manager. Das Frontend wird entsprechend auf minimale Interaktionstiefe und sofortige Rückmeldung ausgelegt.

Zuverlässigkeit & Performance

Die Echtzeit-Suche über das gesamte Partner-Netzwerk ist der zentrale Wertbeitrag der Plattform: Was heute Tage dauert, soll in Sekunden passieren. Die Suchantwortzeiten müssen auch bei wachsendem Netzwerk im Sekundenbereich bleiben — das System wird so ausgelegt, dass es von einem kleinen Netzwerk bis zu einer großen Anzahl von Partnern und Profilen skaliert, ohne Re-Architektierung. Automatisierte Reminder und tokenbasierte Verfügbarkeits-Updates laufen zuverlässig im Hintergrund, ohne manuelle Eingriffe zu erfordern.

Sicherheit & Datenschutz (Security by Design)

DSGVO-Konformität ist eine Pflichtanforderung: Experten-Profile enthalten personenbezogene Daten in Form von Lebensläufen, Kontaktinformationen und Projekterfahrungen. Die Architektur stellt konsequente Mandantentrennung sicher — Partner dürfen gegenseitig keine Profile oder Daten sehen. Die KI-Extraktion von CVs erfolgt ausschließlich über Modelle in der EU-Region, die keine Daten für Modelltraining verwenden. Das Shadow-Profile-Konzept und die explizite Partner-Freigabe zur De-Anonymisierung sind als systemseitig erzwungene Mechanismen implementiert, nicht als optionale Einstellung. Ein Löschkonzept ist Teil der Umsetzung.

Wartbarkeit & Erweiterbarkeit

Die Plattform wird initial für einen einzigen GU gebaut — die Architektur ist jedoch von Beginn an so ausgelegt, dass eine spätere Multi-Mandanten-Fähigkeit (SaaS für mehrere GUs) ohne Re-Architektierung erreichbar ist. Eine saubere Service-Trennung zwischen Frontend, Backend und Intelligence Service ermöglicht unabhängige Weiterentwicklung und Skalierung der einzelnen Komponenten. Die KI-Extraktion ist als austauschbarer Service konzipiert: bessere Modelle können eingebunden werden, ohne die Kernplattform zu ändern.

1.2 Funktionale Anforderungen

Die funktionalen Anforderungen wurden in einem agilen Prozess erarbeitet und in Form von Epics und User Stories in einem separaten Backlog-Dokument detailliert.

Profil-Upload & KI-Extraktion: Partner-Manager laden Experten-Profile (PDF oder Word) per Drag-and-Drop hoch. Eine KI extrahiert automatisch Skills, Zertifikate und Projekterfahrung und überführt die Inhalte in eine einheitliche Struktur. Der Partner-Manager reviewt das Ergebnis und korrigiert es bei Bedarf. Ziel ist, manuelles Eintippen vollständig zu vermeiden — nicht, eine perfekte Extraktion zu liefern.
Expertensuche & Matching: Der GU-Resource-Manager durchsucht in Echtzeit das gesamte Partner-Netzwerk nach Skills, Zertifikaten, Branchenerfahrung, Senioritätslevel, Standort, Rate und Verfügbarkeitsdatum. Die Suche liefert ausschließlich einzelne Experten mit bestätigter Verfügbarkeit — anonymisiert dargestellt. Dieses Epic ist der zentrale Wertbeitrag der Plattform.
Verfügbarkeitspflege: Automatische E-Mail-Reminder in konfigurierbaren Intervallen sorgen dafür, dass Verfügbarkeitsdaten aktuell bleiben. Partner-Manager aktualisieren die Verfügbarkeit ihrer Experten über einen tokenbasierten Quick-Update-Link direkt aus der E-Mail heraus — ohne Login-Schritt.
Partner-Dashboard & Skill-Matrix: Der Partner-Manager erhält eine zentrale Übersicht über alle seine Experten-Profile mit Verfügbarkeitsstatus und Datenfrische (Ampelsystem: grün/gelb/rot). Eine Skill-Matrix visualisiert die Kapazitätsdeckung des eigenen Pools und zeigt, welche Skills besonders häufig oder selten vertreten sind.
Shadow-Profile & Anonymisierung: Profile werden standardmäßig anonymisiert geführt — Name und identifizierende Merkmale sind für den GU-Resource-Manager nicht sichtbar. De-Anonymisierung erfolgt ausschließlich durch explizite Freigabe des Partner-Managers im Rahmen einer konkreten Anfrage. Dieser Mechanismus ist der zentrale Vertrauensbaustein im Netzwerk.
Anfrage-Workflow & Benutzerverwaltung: Der vollständige Workflow von der Anfrage bis zur Bestätigung läuft im Tool ab — kein E-Mail-Ping-Pong mehr. Der GU-Resource-Manager stellt Teilabrufe zusammen (z.B. "15 Java Seniors ab März"), wählt passende Einzelexperten aus verschiedenen Partnerfirmen aus und fragt sie direkt an. Partner bestätigen oder lehnen im Tool ab. Drei Rollen sind abgebildet: GU-Resource-Manager, Partner-Manager und Admin.

2. Technisches Konzept

Bei der Firma Objectbay werden für die Umsetzung von Kundenanforderungen gängige und erprobte Technologien eingesetzt. Dadurch wird sichergestellt, dass die Software auch nach vielen Jahren noch gewartet, erweitert und modifiziert werden kann. Darüber hinaus werden nach Möglichkeit ausschließlich Open-Source-Technologien verwendet, um Kosten zu minimieren und maximale Flexibilität zu gewährleisten. Diese technologischen Entscheidungen legen die Basis für eine langfristig erfolgreiche und nachhaltige Softwarelösung.

Die Lösung besteht aus vier Hauptkomponenten: einem Angular-Frontend als zentrales User Interface für alle drei Rollen, einem Kotlin/Spring-Boot-Backend als API- und Geschäftslogik-Schicht, einem Python/FastAPI-Intelligence-Service für die KI-gestützte CV-Extraktion sowie einer PostgreSQL-Datenbank als persistenter Datenspeicher.

2.1 Technologische Grundlagen

1. Frontend

Das Frontend des Vendor Resource Pool wird mit Angular und TypeScript entwickelt. Als UI-Komponentenbibliothek setzen wir PrimeNG ein — eine feature-reiche Enterprise-Bibliothek, die die spezifischen UI-Anforderungen der Plattform direkt adressiert.

Komponenten für datenintensive Darstellungen: PrimeNG liefert sofort einsatzbereite Komponenten für die zentralen UI-Elemente der Plattform: sortier- und filterbare Datentabellen für die Expertenliste, mehrstufige Filterleisten für die Kombination von Skills, Rate und Verfügbarkeitsdatum, sowie Chart-Komponenten für die Skill-Matrix im Partner-Dashboard. Diese Anforderungen wären mit einer schlanken Bibliothek mit erheblich mehr Eigenaufwand verbunden.
Struktur & Wartbarkeit: Angular erzwingt eine klare, komponentenbasierte Architektur mit einem etablierten Modulkonzept. Für eine Plattform mit drei klar getrennten Rollenperspektiven (GU-Resource-Manager, Partner-Manager, Admin) ist diese Struktur ein natürlicher Fit — jede Rolle bekommt ihren eigenen Bereich mit wiederverwendbaren Shared-Komponenten.
TypeScript & Typsicherheit: Der durchgehende Einsatz von TypeScript im gesamten Frontend garantiert Typsicherheit während der Entwicklung und reduziert Laufzeitfehler. In Kombination mit Angular-Services und strikt typisierten API-Contracts zum Backend ergibt sich eine robuste, wartbare Codebasis.
Drag-and-Drop & Upload: Die PrimeNG-Bibliothek enthält eine FileUpload-Komponente mit nativer Drag-and-Drop-Unterstützung, die den Profil-Upload für Partner-Manager direkt umsetzbar macht — inklusive Fortschrittsanzeige während der KI-Extraktion.

2. Backend

Das Core-Backend des Vendor Resource Pool wird mit Kotlin und dem Spring Boot-Framework realisiert. Es stellt REST-APIs für das Frontend bereit, orchestriert den Anfrage-Workflow, verwaltet die Mandantentrennung und kommuniziert mit dem Intelligence Service.

Robuste Enterprise-Architektur: Spring Boot bietet ein ausgereiftes Ökosystem für API-Management, Datenbankzugriff und Security-Integration. Die strikte Schichtenarchitektur (Controller, Service, Repository) ist für das VRP besonders wichtig: Mandantentrennung und Zugriffslogik werden an einer zentralen Stelle durchgesetzt, nicht verteilt über den Code.
Kotlin-Ausdrucksstärke: Kotlin reduziert Boilerplate-Code erheblich und ermöglicht prägnante, lesbare Implementierungen für die komplexen Domänenobjekte der Plattform — Experten-Profile mit hierarchischen Skills, Zertifikaten und Projekterfahrungen sind in Kotlin dank Data Classes und typsicheren Null-Handling sauber modellierbar.
Anfrage-Workflow & Benachrichtigungen: Der Workflow von der Anfrage über die Partner-Bestätigung bis zur De-Anonymisierung wird als klarer Zustandsautomat im Backend implementiert. E-Mail-Benachrichtigungen (Reminder, Anfragen, Bestätigungen) sind als asynchrone Hintergrundprozesse realisiert, die den Hauptworkflow nicht blockieren.
Tokenbasierte Quick-Update-Links: Die sicherheitsrelevante Logik für zeitlich begrenzte, einmalig nutzbare Tokens für die Login-freie Verfügbarkeitspflege ist zentral im Backend implementiert und wird nicht an das Frontend delegiert.

3. Intelligence Service (KI-Extraktion)

Für die KI-gestützte Extraktion von Skills, Zertifikaten und Projekterfahrung aus hochgeladenen CVs wird ein dedizierter Intelligence Service in Python mit FastAPI betrieben. Dieser Service ist architektonisch vom Core-Backend getrennt und über eine interne REST-API angebunden.

Pragmatischer Extraktionsansatz: Der Intelligence Service folgt dem vereinbarten Ansatz "gut genug, um manuelles Eintippen zu vermeiden" — keine Vollautomatisierung, sondern qualitativ hochwertige Erstvorbereitung mit anschließendem Partner-Review. Ein LLM analysiert den CV-Volltext und gibt strukturierte Daten zurück, die der Partner-Manager anschließend prüft und korrigiert. Die Qualität der Extraktion verbessert sich kontinuierlich durch Modell-Updates, ohne die Kernplattform zu berühren.
Python-Ökosystem für Dokumentenverarbeitung: Python bietet das umfangreichste Ökosystem für Dokumentenverarbeitung (PDF-Parsing, DOCX-Extraktion) und LLM-Integration. FastAPI liefert eine performante, typsichere API-Schicht mit automatischer OpenAPI-Dokumentation, die die Integration mit dem Kotlin-Backend vereinfacht.
Unabhängige Skalierbarkeit: Wenn das Partner-Netzwerk wächst und viele Profile gleichzeitig hochgeladen werden, kann der Intelligence Service unabhängig vom Core-Backend skaliert werden. CV-Extraktion ist ein rechenintensiver, zustandsloser Prozess — ideal für horizontale Skalierung.
Austauschbarkeit: Die Abstraktion als eigenständiger Service stellt sicher, dass bessere oder spezialisierte Modelle eingebunden werden können, sobald sie verfügbar sind — ohne Änderungen am Angular-Frontend oder Kotlin-Backend.

4. Datenbanktechnologie

Als primäre Datenbank wird PostgreSQL eingesetzt. PostgreSQL liefert mit seiner nativen Full-Text-Search-Funktionalität die performante Grundlage für die kombinierte Expertensuche nach Skills, Zertifikaten, Senioritätslevel, Rate und Verfügbarkeitsdatum — und ist damit für die Anforderungen von v1 die pragmatisch richtige Wahl. Wenn das Netzwerk erheblich wächst und komplexere Ähnlichkeitssuchen erforderlich werden, ist eine Migration auf oder Ergänzung durch eine spezialisierte Suchmaschine (z.B. Elasticsearch) ohne Umbau der Applikationsschicht möglich.

Die Datenbankarchitektur adressiert zwei zentrale strukturelle Anforderungen: Mandantentrennung (Partner-Daten sind durch Row-Level-Security strikt isoliert — kein Partner sieht die Profile eines anderen) und Shadow-Profile (anonymisierte und de-anonymisierte Profilansichten werden durch eine saubere Trennung personenbezogener Felder in der Datenbankstruktur realisiert, nicht durch nachgelagerte Filterung).

5. Sicherheitsmechanismen

Authentifizierung und Autorisierung werden über Keycloak mit Role-Based Access Control (RBAC) realisiert. Die drei Rollen der Plattform — GU-Resource-Manager, Partner-Manager und Admin — haben strikt getrennte Berechtigungen, die auf Keycloak-Ebene definiert und im Spring-Boot-Backend durchgesetzt werden. Keycloak unterstützt alle gängigen Authentifizierungsprotokolle (OAuth2, OpenID Connect) und ermöglicht eine spätere SSO-Integration, falls der Auftraggeber dies wünscht.

Die Mandantentrennung wird auf mehreren Ebenen erzwungen: auf Datenbankebene durch Row-Level-Security, auf API-Ebene durch kontext-bewusste Autorisierungsprüfungen im Backend und auf Frontend-Ebene durch rollenspezifische Routing-Guards. Eine einzelne Schwachstelle auf einer Ebene reicht nicht aus, um Mandantendaten zu kompromittieren.

Die DSGVO-Konformität wird durch mehrere Maßnahmen sichergestellt: LLM-Verarbeitung personenbezogener CV-Daten ausschließlich über Amazon Bedrock in der EU-Region Frankfurt (keine Datenweitergabe für Modelltraining), ein implementiertes Löschkonzept (Partner-Manager können eigene Profile löschen, Admin kann alle Daten löschen), sowie minimale Datenspeicherung (nur die für den jeweiligen Anwendungsfall erforderlichen personenbezogenen Daten). Die tokenbasierten Quick-Update-Links sind zeitlich begrenzt, kryptographisch signiert und einmalig nutzbar — bei Ablauf oder ungültigem Token wird der Zugriff verweigert, ohne eine Fehlermeldung zu liefern, die Rückschlüsse auf das System erlaubt.

Deployment

Alle Services — Angular-Frontend, Kotlin-Backend, Python-Intelligence-Service und Keycloak — werden als Docker-Container bereitgestellt und über Kubernetes auf Azure AKS orchestriert. Diese Infrastruktur garantiert standardisierte, reproduzierbare Deployments und ermöglicht bedarfsgerechtes Auto-Scaling: Der Intelligence Service skaliert unabhängig vom Core-Backend, wenn viele Profile gleichzeitig hochgeladen werden.

Die CI/CD-Pipeline über GitLab CI sorgt für vollständig automatisierte Auslieferungen: Jeder Commit durchläuft statische Codeanalyse, automatisierte Tests und Security-Checks, bevor er in die Zielumgebung deployed wird. Die Pipeline umfasst getrennte Stages für Test-, Integrations- und Produktivumgebung.

Monitoring und Observability wird über OpenTelemetry im Kotlin-Backend und Python-Intelligence-Service implementiert. Als Observability-Plattform empfehlen wir Datadog — eine vollständige Lösung für Metriken, Logs, Traces und Alerting, die ohne eigene Infrastruktur-Wartung auskommt.

LLM-Observability

Für die Überwachung der KI-Extraktionsqualität und Token-Kosten wird Langfuse eingesetzt. Langfuse ermöglicht das Tracing jeder CV-Extraktion: Welche Prompts wurden verwendet, wie lange hat die Verarbeitung gedauert, wie viele Tokens wurden verbraucht, und wie unterscheidet sich die Extraktionsqualität je nach CV-Format und -Länge. Diese Transparenz ist für den pragmatischen Ansatz der Plattform essenziell — sie ermöglicht gezielte Prompt-Optimierungen ohne aufwendige manuelle Auswertung und liefert die Datenbasis für eine kontinuierliche Verbesserung der Extraktionsqualität.

3. Vorgehensmodell

Agiles Vorgehen und Scrum

Die Softwareentwicklung erfolgt nach dem agilen Vorgehensmodell Scrum. Zu betonen ist, dass Scrum als Rahmenwerk gilt, das flexibel an die Bedürfnisse des Projekts angepasst werden kann. Die wichtigste Prämisse ist, dass agile Werte und Prinzipien gelebt werden, um die Zusammenarbeit zwischen Team und Kunden zu fördern und die Qualität der Software zu erhöhen.

Die entwickelte Software wird in möglichst kurzen Zyklen an den Kunden ausgeliefert, um frühzeitig Feedback zu erhalten und Anpassungen vornehmen zu können. Dadurch reduziert sich das Risiko von Fehlentwicklungen und die Software kann schneller in den Produktivbetrieb überführt werden.

Software Engineering

Objectbay lebt die Philosophie, dass Software nachhaltig und effizient entwickelt werden muss. Das impliziert auch, dass die zu entwickelnde Software auch nach dem Projektabschluss und der Übergabe an den Kunden leicht gewartet, erweitert und langlebig verwendet werden kann. Um diese Qualitätskriterien zu erreichen, müssen gewisse Aufwände in die Entwicklung gesteckt werden, die andere Anbieter in der Regel nicht leisten. Daraus resultiert, dass der Entwicklungsaufwand zwar höher ist, im Vergleich zu weniger hohen Qualitätsansprüchen, jedoch werden die langfristigen und laufenden Kosten, aber auch das technologische Betriebsrisiko beim Kunden wesentlich reduziert.

Modulare und Komponentenbasierte Entwicklung

Software muss so gebaut werden, dass bei Änderung der funktionalen Anforderung die Adaption des Codes nur minimal ausfällt. Die zugrunde liegenden Prinzipien sind "Coupling" und "Cohesion". Ein solches Softwaresystem zu entwickeln muss gut durchdacht sein, angefangen von der Konzeption und der Anforderungsanalyse mit dem Kunden bis hin zum tatsächlichen Schreiben des Codes. Im Gegensatz zu "Quick & Dirty" Implementierungen sind durchdachte und nachhaltige Ansätze mit kognitiven und technischen Aufwänden verbunden.

Testgetriebene Entwicklung und Testabdeckung

Wenn Software auch nach vielen Jahren adaptiert und weiterentwickelt werden soll, ist es für nachfolgende EntwicklerInnen wichtig, dass die Software gut dokumentiert und deren Funktionsweise zu jeder Zeit automatisiert sichergestellt ist. Bei Objectbay spielt deshalb das automatisierte Testen eine wichtige Rolle. Automatisierte Tests helfen dabei, Fehler im Code gar nicht erst entstehen zu lassen oder zumindest sehr schnell beheben zu können. Darüber hinaus dienen automatisierte Software-Tests als Teil der technischen Dokumentation, wodurch spätere EntwicklerInnen den Code schnell verstehen und weiterentwickeln können.

Letztendlich helfen automatisierte Software-Tests dabei, dass die an den Kunden ausgelieferte Software nahezu frei von Fehlern ist und bereits ab dem ersten Tag des Produktiveinsatzes funktioniert.

Vollumfängliche Ende-zu-Ende Umsetzung

Objectbay liefert Software in einem ganzheitlichen Konzept. Im Sinne der Vergleichbarkeit mit Mitbewerbern ist anzumerken, dass wir nicht nur Code ausliefern, sondern den Kunden im gesamten Entwicklungsprozess begleiten. Wir unterstützen bei der Erfassung der Anforderungen und der Erstellung eines Backlogs, der vom Entwicklungsteam umgesetzt wird.

Darüber hinaus stellen wir sicher, dass unsere Software im Sinne der Qualität bestens geprüft und getestet sowie fehlerfrei ausgeliefert wird. Dabei setzen wir neben automatisierten Tests auch auf laufende Kommunikation mit dem Kunden und versuchen möglichst schnelles und umfangreiches Feedback zu erhalten. Dies passiert laufend, nicht erst am Ende der Entwicklung. Von Objectbay wird nicht nur Quellcode ausgeliefert, sondern wir sorgen auch dafür, dass die Software in der bestmöglichen Laufzeitumgebung betrieben werden kann. Unsere Software ist nachhaltig und kann auch in vielen Jahren noch verwendet, erweitert und gewartet werden.

Rahmenbedingungen und Konventionen

Entwicklungsumgebung

Entwickelt wird die Software auf den Geräten der Firma Objectbay mit gängigen Tools wie IntelliJ, VS Code etc. Die Software wird in einem Git-Repository versioniert.

Spezifikation

Die Software wird nach den Vorgaben des Auftraggebers spezifiziert und entwickelt. Die Spezifikation erfolgt in Form von User Stories, die in einem Product Backlog verwaltet werden. User Stories werden von einem möglichst fixen Ansprechpartner (Product Owner) des Auftraggebers erstellt, priorisiert und freigegeben. Bei der Erstellung der User Stories unterstützt das Objectbay-Entwicklungsteam im Rahmen der Scrum-Meetings. Konkret handelt es sich dabei um das (Backlog-)Refinement.

Auslieferung

Die Auslieferung der Software erfolgt in regelmäßigen, kurzen Abständen, um schnelles Feedback zu ermöglichen und eine kontinuierliche Verbesserung zu fördern. Im Rahmen der Inbetriebnahme wird die Bereitstellung der Anwendung so gestaltet, dass eine containerisierte Umgebung genutzt wird, die durch Kubernetes verwaltet wird. Dies gewährleistet eine standardisierte und stabile Laufzeitumgebung.

Die Zielumgebung für die Inbetriebnahme ist Azure. Dabei stellen wir folgende Elemente zur Verfügung:

Deployment-Prozess: Wir stellen eine Continuous-Delivery-Pipeline bereit, die automatische Auslieferungen und Updates in der Azure Kubernetes Service (AKS)-Umgebung ermöglicht. Die GitLab-CI-Pipeline umfasst getrennte Stages für Test-, Integrations- und Produktivumgebung mit vollständig automatisierten Security-Checks und Quality-Gates.
Monitoring-Konfiguration: Wir richten ein initiales Monitoring über OpenTelemetry und Datadog ein, um eine lückenlose Überwachung von Performance- und Verfügbarkeitskennzahlen aller Services zu ermöglichen — einschließlich dedizierter LLM-Observability über Langfuse für die KI-Extraktionskomponente.
Ressourcenverwaltung: Unterstützung bei der initialen Konfiguration von Kubernetes-Funktionen wie Auto-Scaling und Load Balancing, die eine bedarfsgerechte Skalierung der Container ermöglichen. Der Intelligence Service für die CV-Extraktion ist dabei unabhängig vom Core-Backend skalierbar konfiguriert.

Durch die Bereitstellung dieser Infrastruktur und Mechanismen wird sichergestellt, dass die Anwendung in einer performanten und skalierbaren Umgebung betrieben werden kann.

Dokumentation

Das Softwaresystem, die Architektur und der Code werden mit gängigen Standards, wie beispielsweise Arc42 dokumentiert. Dies ermöglicht es sowohl nicht-technischen Stakeholdern als auch fremden EntwicklerInnen sich schnell im System zurechtzufinden.

Definition of Done

Vor dem Beginn der Entwicklung einigen sich Objectbay und der Auftraggeber auf eine "Definition of Done". Diese spezifiziert das Level an Qualität inkl. Security hinsichtlich der umgesetzten funktionalen Inhalte (Akzeptanzkriterien) sowie nicht-funktionaler Aspekte wie beispielsweise Quality-Gates. Beispiele für Quality Gates sind automatische Security-Vulnerability Checks in der CI/CD-Pipeline nach einem Code-Commit im Versionskontrollsystem (Git). Weitere Quality-Gates können sein: Abdeckungsgrad der Software mit automatisierten Tests, statische Codeanalyse mittels SonarQube u. v. m.

Die Definition of Done kann in weiterer Folge als Vertragsbestandteil angesehen werden und garantiert dem Auftraggeber, dass die Umsetzung das vereinbarte Mindestniveau an Qualität einhält.

Für den Vendor Resource Pool gilt folgende Definition of Done:

Alle Akzeptanzkriterien der User Story sind erfüllt und automatisch testbar.
Die Build Pipeline ist grün.
Ein Code Review nach dem 4-Augen-Prinzip wurde durchgeführt.
Die Software ist frei von bekannten Fehlern.
Es wurde erfolgreich auf die Testumgebung und auf die Integrationsumgebung deployed.
Sicherheitsanforderungen wurden überprüft (statische Codeanalyse).
Die technische Dokumentation wurde aktualisiert.
Mandantentrennung: Jede Story, die Profil- oder Benutzerdaten berührt, wurde gegen die Anforderung geprüft, dass Partner gegenseitig keine Daten sehen können.
DSGVO: Personenbezogene Daten werden nur in dem Umfang verarbeitet und gespeichert, wie es die jeweilige Story erfordert; Löschbarkeit ist sichergestellt.