[Seite 1]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Teil B Leistungsbeschreibung
(wird bei Zuschlagserteilung Vertragsbestandteil)
Managed Service E-AKTE 2027
Anlagen:
Anlage 1 Hausordnung für externe Dienstleister der Bundesagentur für Arbeit (BA) zur Einhaltung des Datenschutzes Anlage 2 Organisation der BA Anlage 3 Technische und organisatorische Maßnahmen (TOM) Anlage 4 Skill-Profile Anlage 5 Releaseplan / Meilensteinplan Anlage 6 Monatlicher KPI-Erfüllungsgrad (Muster)
Aus Gründen der Lesbarkeit wurde im Text die männliche Form gewählt, nichtsdestoweniger beziehen sich die Angaben auf Angehörige aller Geschlechter.
Seite 1 von insgesamt 81 Seiten
[Seite 2]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Inhalt
1 AUSGANGSLAGE UND ZIEL DER AUSSCHREIBUNG ................................ 7
1.1 Ist-Zustand ............................................................................................................... 7 1.1.1 Die E-AKTE ........................................................................................................... 7 1.1.2 Standort der E-AKTE ............................................................................................. 7 1.1.3 Aufbauorganisation ................................................................................................ 7 1.1.4 Ablauforganisation ................................................................................................. 7
1.2 Soll-Zustand ............................................................................................................. 8
1.3 Nachhaltigkeit .......................................................................................................... 8 1.3.1 Green-IT und Umwelt ............................................................................................. 8 1.3.2 Soziale Nachhaltigkeit ............................................................................................ 8
2 TECHNOLOGISCHES UMFELD / INFRASTRUKTUR .................................... 8
2.1 Einleitung ................................................................................................................. 8
2.2 Umgebungen ............................................................................................................ 9
2.3 Plattformen ............................................................................................................... 9 2.3.1 Infrastrukturplattform BA private Cloud (BApC) ...................................................... 9 2.3.2 Ablaufplattform Container (CaaS) .......................................................................... 9 2.3.3 Middleware Ablaufplattform (MWaaS) .................................................................... 9 2.3.4 Datenbank-Plattform (DBaaS) ................................................................................ 9 2.3.5 E-AKTE-Plattform .................................................................................................. 9 2.3.6 Architekturübersicht E-AKTE .................................................................................10 2.3.7 Traditional IT (TI) ..................................................................................................11
2.4 Infrastruktur ............................................................................................................11 2.4.1 Netzwerk ...............................................................................................................11 2.4.2 Server ...................................................................................................................11 2.4.3 Standard-Arbeitsplatzsystem ................................................................................12 2.4.4 PC-Arbeitsplätze ...................................................................................................12 2.4.5 Virtuelle Desktop Infrastruktur (VDI) ......................................................................12 2.4.6 Drucker .................................................................................................................12
2.5 Betriebstools ...........................................................................................................13
2.6 Softwareentwicklungsmethodik ............................................................................14
2.7 Fachliche Tests und Testautomatisierung ............................................................14
Seite 2 von insgesamt 81 Seiten
[Seite 3]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
2.8 Sicherheit ................................................................................................................16 2.8.1 Sicherheitsanforderungen .....................................................................................16 2.8.2 Anbindung von Tools ............................................................................................17 2.8.3 Sicherheitskonzept ................................................................................................17 2.8.4 Informationssicherheitsmanagementsystem .........................................................17 2.8.5 Auditrecht..............................................................................................................17
2.9 Eingesetzte Werkzeuge und Standards/Frameworks ...........................................17
2.10 Schnittstellenpartner ..............................................................................................21 2.10.1 Überblick ...........................................................................................................21 2.10.2 Angebundene Schnittstellen ..............................................................................21
3 RAHMENBEDINGUNGEN ............................................................................. 22
3.1 IT-Service-Management-Prozesse .........................................................................22
3.2 Betriebssprache ......................................................................................................22
3.3 Anforderung an den AN .........................................................................................23
3.4 Leitlinien zur Leistungserbringung .......................................................................23
3.5 Erforderliche Funktionskenntnisse .......................................................................24
4 AUSSCHREIBUNGSGEGENSTAND ............................................................ 25
4.1 Nicht optionale und optionale Leistungen ............................................................25
4.2 Gegenstand der zu erbringenden Leistungen ......................................................25 4.2.1 Beschaffungsgegenstand ......................................................................................25 4.2.2 Konkretisierung und Abgrenzung ..........................................................................26
5 MANAGED SERVICE .................................................................................... 27
5.1 Wiederkehrende Aufgaben .....................................................................................27 5.1.1 Aufwandsschätzung ..............................................................................................27
5.2 Bearbeitung von Demands .....................................................................................27 5.2.1 Übersicht...............................................................................................................27 5.2.2 Definition eines Demands .....................................................................................28 5.2.3 Direkt-Demand (Sonderform) ................................................................................28 5.2.4 Beispiele/Vergangenheitswerte .............................................................................28 5.2.5 Einreichung durch die BA ......................................................................................29 5.2.6 Erstbewertung und Aufwandsschätzung durch den AN .........................................29 5.2.7 Beauftragung durch die BA ...................................................................................29
Seite 3 von insgesamt 81 Seiten
[Seite 4]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.2.8 Umsetzung ............................................................................................................29 5.2.9 Priorisierung ..........................................................................................................30 5.2.10 Status und Kommunikation ...............................................................................30 5.2.11 Fachliche Abnahme ..........................................................................................30 5.2.12 Dokumentation ..................................................................................................30
5.3 Bearbeitung von Incidents (Support) ....................................................................30 5.3.1 Leistungsumfang ...................................................................................................30 5.3.2 Bearbeitung von Security-Risiko-Tickets ...............................................................32 5.3.3 Rahmenbedingungen ............................................................................................32
5.4 Testmanagement ....................................................................................................32 5.4.1 Übersicht...............................................................................................................32 5.4.2 Abnahmekonzept ..................................................................................................33
5.5 Mitwirkung an Audits ..............................................................................................41
5.6 Abstimmungsformate .............................................................................................42 5.6.1 Anlassbezogenes Fehlermeeting ..........................................................................42 5.6.2 Zweiwöchentliches Review-Meeting ......................................................................42 5.6.3 Monatsmeeting .....................................................................................................43 5.6.4 Release-Meeting ...................................................................................................44 5.6.5 Steuerungskreis ....................................................................................................44
5.7 Deployments / Pflege ..............................................................................................45 5.7.1 Datenpflege ..........................................................................................................45 5.7.2 System- und Service-Betreuung (Administration) ..................................................45 5.7.3 Build- und Release-Management ..........................................................................45 5.7.4 Datenbank-Management .......................................................................................46 5.7.5 Sicherheit und Infrastruktur-Hygiene .....................................................................46 5.7.6 Software-Anpassung und Konfiguration ................................................................47 5.7.7 Dokumentation und Nachvollziehbarkeit ...............................................................47
5.8 Dokumentation und Ablage ...................................................................................47
5.9 Nutzung Hard- und Softwareinfrastruktur der BA ................................................48
5.10 Vereinbarte Kennzahlen zur Leistungserbringung ...............................................48 5.10.1 Qualitätssicherung der Softwareentwicklung .....................................................48 5.10.2 Leistungsübergabepunkte .................................................................................49 5.10.3 SLA zwischen AN und BA .................................................................................49
5.11 Freigabe und fachliche Abnahme ..........................................................................51 5.11.1 Unterscheidung .................................................................................................51
Seite 4 von insgesamt 81 Seiten
[Seite 5]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.11.2 Freigabe ............................................................................................................51 5.11.3 Abnahme (zahlungsbegründend) ......................................................................56
5.12 Bedienter Betrieb und Programmversion / Wartungsfenster ..............................60
6 BEISTELLLEISTUNGEN DER BA / LEISTUNGSABGRENZUNG ................ 60
7 SONSTIGE LEISTUNGEN ............................................................................. 60
7.1 Vorlaufende Transition (Werkleistung) .................................................................60
7.2 Abschließende Transition (Werkleistung) .............................................................62
7.3 Exit-Management ....................................................................................................63 7.3.1 Exit-Management-Konzept ....................................................................................64
7.4 Ergänzende Dienstleistungen ................................................................................65 7.4.1 Zeiten der Leistungserbringung bei den ergänzenden Dienstleistungen ...............65 7.4.2 Vorgehen bei Dienstleistungsabrufen ....................................................................65
8 UMFANG UND DAUER DER LEISTUNG ...................................................... 66
8.1 Vertragslaufzeit, Leistungszeitraum, Kündigungsoptionen ................................66
8.2 Transitionsphasen ..................................................................................................67
8.3 Release- und Meilensteinplanung .........................................................................67
8.4 Ort und Zeiten der Leistungserbringung / Servicezeit / Rufbereitschaft ............67 8.4.1 Allgemeines ..........................................................................................................67 8.4.2 Service- und Rufbereitschaftszeiten ......................................................................68
8.5 Flexibilisierung des Leistungsumfangs ................................................................68 8.5.1 Änderungen im Vertragsverlauf .............................................................................69 8.5.2 Spontane Umpriorisierungen.................................................................................69 8.5.3 Planbare Umpriorisierungen..................................................................................70 8.5.4 Ausgleich von operativen Leistungsschwankungen ..............................................70 8.5.5 Ausgleich von mittelfristigen Leistungsschwankungen ..........................................70 8.5.6 Änderungsverlangen .............................................................................................70
9 VERTRAGSABWICKLUNG ........................................................................... 72
9.1 Allgemeines ............................................................................................................72 9.1.1 Ansprechpartner ...................................................................................................72
10 DATENSCHUTZ / AUFTRAGSVERARBEITUNG ......................................... 73
Seite 5 von insgesamt 81 Seiten
[Seite 6]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
10.1 Gegenstand und Dauer der Verarbeitung .............................................................73 10.1.1 Gegenstand der Verarbeitung ...........................................................................73 10.1.2 Dauer der Verarbeitung .....................................................................................73
10.2 Konkretisierung des Auftragsinhalts ....................................................................73 10.2.1 Art und Zweck der vorgesehenen Verarbeitung von Daten ...............................73 10.2.2 Art der Daten .....................................................................................................73 10.2.3 Kategorien betroffener Personen ......................................................................74
10.3 Kundinnen und Kunden der BAtechnische und organisatorische Maßnahmen und deren Kontrolle ...........................................................................................................74
10.4 Berichtigung, Einschränkung und Löschung von Daten .....................................74
10.5 Beachtung zwingender gesetzlicher Pflichten durch den Auftragnehmer .........74
10.6 Mitteilung bei Verstößen des Auftragnehmers .....................................................75
10.7 Regelungen bei Remote-Zugriff und Tele-/Heimarbeit .........................................75
11 SCHRIFTLICHE AUFGABENSTELLUNG ..................................................... 76
12 VERIFIZIERENDE BIETERPRÄSENTATION ................................................ 76
13 ABKÜRZUNGEN / GLOSSAR ....................................................................... 77
Seite 6 von insgesamt 81 Seiten
[Seite 7]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
1 Ausgangslage und Ziel der Ausschreibung
1.1 Ist-Zustand
1.1.1 Die E-AKTE Die E-AKTE ist ein Dokumentenmanagementsystem und besteht zum Zeitpunkt der Ausschreibung aus rd. 1 Million Lines of Code (LoC). Der Basisdienst E-AKTE unterstützt durch die Einführung einer elektronischen Akte den Reformprozess der Bundesagentur für Arbeit (BA), insbesondere • sichere und beschleunigte Bearbeitung aus Kundensicht o Die weitgehend papierlose und somit ortsungebundene Abwicklung mit elektronischer Vorgangssteuerung gestaltet die Bearbeitungsvorgänge sicherer, transparenter und zügiger und erhöht die Auskunftsfähigkeit. • Bearbeitungserleichterung für Sachbearbeitende o Eine durchgängige IT-Unterstützung bis hin zur Ablage ermöglicht den Sachbearbeitenden eine sichere und zügige Abwicklung ihrer Aufgaben ohne Medienbrüche. • Flexible und wirtschaftliche Lösung für die BA o Die Gesamtlösung als flexibler Basisdienst kann an veränderte Rahmenbedingungen und weitere Einsatzbereiche angepasst werden und löst bisherige Verfahren in wirtschaftlicher Weise ab. Darüber hinaus stellt der Basisdienst E-AKTE die Revisions- und Kassensicherheit der Dokumente sicher, die im DMS-System abliegen.
1.1.2 Standort der E-AKTE Das E-AKTE-System besteht aus Server- und Client-seitigen Komponenten. Die Server- seitigen Komponenten werden redundant in unterschiedlichen Rechenzentrumsstandorten der BA am Standort Nürnberg betrieben. Verantwortlich für die IT-Infrastruktur ist das IT-Systemhaus der BA. Die weiteren für die Durchführung des Auftrages relevanten Details zur Infrastruktur und Standorten finden sich auf der Website des IT-Systemhauses und im IT-Sicherheitskonzept, welches (in Auszügen) nach Zuschlag dem AN übergeben wird. Die Client-seitigen Komponenten stehen bundesweit auf den regulären Mitarbeiter- Arbeitsplätzen in den verschiedenen Dienststellen der BA zur Verfügung und werden grundsätzlich von ca. 120.000 Nutzerkonten verwendet.
1.1.3 Aufbauorganisation Das IT-Verfahren E-AKTE-DMS ist ein vom IT-Systemhaus (Organisationseinheit »K52 – Dokumente und Archiv«, im Folgenden: »K52«) bereitgestellter Basisdienst. Im Rahmen des Betriebs und der Weiterentwicklung des IT-Verfahrens E-AKTE-DMS ist dabei ein Großteil der Geschäftsbereiche direkt oder indirekt beteiligt.
1.1.4 Ablauforganisation Das E-AKTE-System importiert elektronische Dokumente aus verschiedenen Quellen, ordnet die Dokumente elektronischen Akten zu und stellt Dokumente und Akten anschließend den Anwendern im Rahmen verschiedener Fachprozesse zur Verarbeitung zur Verfügung. Wird ein Dokument »zu den Akten« (z.d.A.) verfügt, wird es durch E-AKTE in dem angebundenen E-ARCHIV der BA archiviert. Die elektronische Akte verbleibt dabei über die Lebenszeit der
Seite 7 von insgesamt 81 Seiten
[Seite 8]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Akte mit den enthaltenen Dokumenten im E-AKTE-System und erlaubt den Anwendenden über die Aktenstruktur auch weiterhin Zugriff auf bereits archivierte Dokumente. Die aktuell vorgesehenen Geschäftsprozesse, in denen das E-AKTE-System eingesetzt wird, entsprechen den Prozessen, die für diese Vorgänge zweckmäßig und erfahrungsgemäß zielführend sind: • Digitalisierung des BA-Schriftgutes (Eingangsmanagement) • Elektronische Schriftgutverwaltung (Dokumentenimport, Auftragsverwaltung) • Elektronische Ablage und Archivierung • QS-Prozesse Dokumentenimport (für Bestandsakten und Sachbearbeitungsdokumente) Diese Prozesse sind in der Prozesslandkarte der BA (s. Kapitel 3.1) detailliert wiedergegeben. Die Kernfunktionalität des E-AKTE-Systems für die Anwendenden wird über den E-AKTE- Schreibtisch in Form der Scan-Auftrags-, Postkorb-, Akten- und Dokumenten-Verwaltung zur Verfügung gestellt. Zur Abbildung der Kernfunktionalität in E-AKTE-DMS bestehen neben der Anbindung zum Scan-Dienstleister (E-AKTE-DiBAS) und dem Archiv (E-ARCHIV) weitere Anbindungen zu bestehenden Fachverfahren der BA.
1.2 Soll-Zustand
Mit dem Abschluss dieses Vertrages ist die Weiterentwicklung und Pflege des Basisdienstes E-AKTE und des fachlichen Unterstützungsbedarfs im Rahmen der IT-Strategie durch den Auftragnehmer (AN) sichergestellt.
1.3 Nachhaltigkeit
1.3.1 Green-IT und Umwelt Um Umweltbelastungen zu reduzieren, das Angebot umweltfreundlicher Produkte und Dienstleistungen zu verbessern und / oder die Markteinführung innovativer umweltfreundlicher Produkte gezielt zu unterstützen, beschafft die BA energieeffiziente Produkte und Dienstleistungen. Weiter achtet die BA darauf, dass ein entsprechendes Umwelt- oder Energiemanagementsystem (z. B. EMAS, ISO-140051) bei potentiellen Auftragnehmern (AN) vorliegt. In die Leistungsbeschreibung (LB) bzw. das Leistungsverzeichnis (LV) fließen daher ggf. auch Umwelt-, Klima- und insbesondere Energieeffizienzaspekte durch Verwendung entsprechender Kriterien ein. Vorzulegende Nachweise werden im Leistungsverzeichnis explizit angefordert.
1.3.2 Soziale Nachhaltigkeit Die BA beachtet beim Einkauf soziale Nachhaltigkeitskriterien.
2 Technologisches Umfeld / Infrastruktur
2.1 Einleitung
Der Abschnitt »technologisches Umfeld« beschreibt die aktuell gültigen technischen Rahmenbedingungen, wie sie in der BA realisiert sind. Die aufgeführten Produkte und Komponenten werden im Rahmen eines systematisch betriebenen Lifecycle-Managements regelmäßig aktualisiert; insofern beschreiben konkrete Versionsbezeichnungen lediglich den aktuellen Zustand zum Zeitpunkt der Erstellung dieser Leistungsbeschreibung.
Seite 8 von insgesamt 81 Seiten
[Seite 9]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Das IT-Systemhaus der BA betreibt eine zentral gemanagte, auf einheitlichen Vorgaben basierende Infrastruktur, die den Mitarbeitern der BA und der angebundenen Organisationen eine hochverfügbare IT-Dienstleistung bereitstellt.
2.2 Umgebungen
Die Betriebsarchitektur besteht aus produktiven und nicht-produktiven Umgebungen, in denen Anwendungen für den Endanwender entwickelt, getestet und produktiv zur Verfügung gestellt werden. Für diese Schritte bis zur Produktivsetzung werden unterschiedliche Umgebungen bereitgestellt (»Staging«). Im produktiven Umfeld sind, je nach Kritikalität, Failover (s. Glossar, Kapitel 13) sowie Hochverfügbarkeits-Mechanismen im Einsatz. Die Umgebungen sind auf unterschiedliche BA- Standorte verteilt und basieren auf den technischen Komponenten, die in den folgenden Abschnitten beschrieben sind.
2.3 Plattformen
Im IT-Systemhaus werden für den Ablauf von Fachanwendungen und Infrastruktur-Diensten sogenannte »Plattformen« bereitgestellt, die einen einheitlichen Betrieb der jeweiligen Services auf einer definierten Infrastruktur ermöglichen. Es wird unterschieden zwischen Infrastruktur- und Ablaufplattformen.
2.3.1 Infrastrukturplattform BA private Cloud (BApC) Die BApC ist die Ziel-Infrastrukturplattform für alle neuen und bestehenden Services. Sie basiert auf einer einheitlichen Server-Infrastruktur, der »VMware«-Suite und »Cisco«-ACI. Sie stellt IaaS (Infrastructure as a Service) u.a. in Form virtueller Linux-Server (»SUSE SLES 15«) und virtueller Windows-Server (»MS Windows Server 2022«) einschließlich Storage sowie der erforderlichen Netzanbindung bereit.
2.3.2 Ablaufplattform Container (CaaS) Basierend auf der BApC betreibt die BA eine Containerplattform. Wesentliche Bestandteile sind »Kubernetes«, »Istio« als Service-Mesh und »Rancher« zum Deployment von »Kubernetes«-Clustern, sowie »iSCSI« für lokale Persistenz und die Möglichkeit, eine »S3«- Schnittstelle zu nutzen.
2.3.3 Middleware Ablaufplattform (MWaaS) Als Ablaufumgebung für »JEE«-Anwendungen stehen vonseiten BA »Middleware«-Server auf Basis »Linux« und »Websphere« bereit. Die zukünftige Versionspflege erfolgt durch den AN im Rahmen seiner Leistungen (s. Kapitel 5.7).
2.3.4 Datenbank-Plattform (DBaaS) Datenbanken werden in der »Traditional IT« bereitgestellt. Es kommt »Oracle RAC« zum Einsatz.
2.3.5 E-AKTE-Plattform Die E-AKTE-Plattform der BA basiert auf folgenden Komponenten: • MS Windows Server • Linux-Server • MS SQL Server • Oracle DB
Seite 9 von insgesamt 81 Seiten
[Seite 10]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Kubernetes-Cluster Die technische Infrastruktur der E-AKTE-Plattform befindet sich in folgenden Umgebungen: • Produktion (Prod) ➢ DST1, DST2 ➢ TDST (Schulung) • Nicht produktive Umgebungen und Testumgebungen ➢ SPU (Softwareproduktionsumgebung): ▪ SDST1-6 ➢ STU (Systemtestumgebung): ▪ EDST1, EDST6 ➢ P-INT (Produktintegrationsumgebung): ▪ EDST3, EDST4 ➢ SSP P0 (derzeit) (Schnittstellenpool): ▪ EDST5 ➢ SSP (zukünftig): ▪ EDST2 ➢ S-INT (Systemintegrationsumgebung): ▪ IDST2, IDST3 ➢ LTU (Lasttestumgebung): ▪ IDST1, IDST4
2.3.6 Architekturübersicht E-AKTE Das E-AKTE-System basiert auf dem DMS-Standardprodukt »IBM FileNet Content Manager« mit dem integrierten »IBM FileNet P8 Business Process Manager« aus der »IBM FileNet P8«- Produktfamilie. Die für das E-AKTE System geforderte Funktionalität wird zu großen Teilen durch dieses DMS- Standardprodukt abgedeckt. Darüber hinaus notwendige funktionale Erweiterungen betreffen die Übergabe- und Import-Schicht, die Verwaltung von Akten und von Aufträgen, die Schnittstelle zum E-ARCHIV, das Regelwerk für die Verteilung von Aufträgen, Signaturfunktionen sowie Protokoll- und Journalfunktionen. Diese Erweiterungen sind in eigenen Komponenten implementiert und werden auf eigenen Applikationsservern betrieben. Hierbei kommen Websphere und »Kubernetes« zum Einsatz. Das Verfahren E-AKTE wird produktiv in einer Hochverfügbarkeitskonfiguration, verteilt über die Rechenzentren der BA, betrieben. Sie nutzen zur Persistenz der Informationsobjekte eine »Oracle«-Datenbank, die per »Oracle Real Application Cluster« ebenfalls hochverfügbar im SAN (Storage Area Network) der BA betrieben wird. Die nachfolgende Grafik (Architekturübersicht) stellt einen grundlegenden Überblick über die einzelnen Komponenten des heutigen E-AKTE-Systems der BA dar:
Seite 10 von insgesamt 81 Seiten
[Seite 11]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Abb.1 Architekturübersicht (Module in der E-AKTE)
2.3.7 Traditional IT (TI) Die »Traditional IT« (TI) ist die Zusammenfassung aller Bestandssysteme, die nicht der BApC zuzuordnen sind.
2.4 Infrastruktur
2.4.1 Netzwerk • Lokale Netzwerke werden mit Switches realisiert. Es ist eine Netzzugangskontrolle auf Basis IEEE 802.1X implementiert. • Das Weitverkehrsnetz ist als Managed Service durch einen externen Provider bereitgestellt. Es verbindet alle Liegenschaften der BA untereinander und mit den zentralen RZ-Standorten. • Das Rechenzentrumsnetz ist hochverfügbar über die verschiedenen RZ-Standorte auf Basis der Fabric-Lösung des Herstellers Cisco aufgebaut und verwendet die Bandbreiten zwischen 1 Gbit/s bis 100 Gbit/s.
2.4.2 Server Alle IT-Verfahren und die wesentlichen Infrastrukturdienste werden zentral durch Hochverfügbarkeitsrechenzentren bereitgestellt. Zum Einsatz kommen folgende Komponenten (Es werden stets aktuelle Versionen eingesetzt): • Hardware: ➢ Industrie-Standard-Server in Racktechnologie auf Basis der x86-Architektur (64 Bit) ➢ Storage–Systeme: EMC XtremIO, Pure Storage, angebunden über Fibre-Channel; weiterhin Netapp-Systeme • Betriebssysteme:
Seite 11 von insgesamt 81 Seiten
[Seite 12]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
➢ Windows-Server ➢ Linux-Server • Server-Virtualisierung: ➢ VMWARE
2.4.3 Standard-Arbeitsplatzsystem • Standardisierte Business-Class Notebooks (x86) mit Windows 11 64Bit und 8 oder 16 GByte Hauptspeicher • Dient als vollfunktionaler Arbeitsplatz inkl. USB-C Docking Station und Monitor (Standardgröße 24‘‘) • Zugang zum BA-Netzwerk über LAN in Dienstgebäuden • VPN-Lösung (LAN, WLAN und Mobilfunk) für den mobilen Zugang zum BA-Netzwerk • Zentrale, automatisierte, imagebasierende OS-Basis-Bereitstellung • Applikationen werden in einem standardisierten Paketformat erstellt und über SCCM automatisiert verteilt. • Standard-Office Suite: MS Office 2024
2.4.4 PC-Arbeitsplätze • Einsatz nur in Ausnahmefällen und besonderen Einsatzszenarien • Keine USB-C Dockingstation • Zugang zum BA-Netzwerk über LAN in Dienstgebäuden • VPN-Lösung (nur LAN) für den mobilen Zugang zum BA-Netzwerk • Alle sonstigen Punkte wie unter Standard-Arbeitsplatzsystem sind ebenso gültig.
2.4.5 Virtuelle Desktop Infrastruktur (VDI) • Einsatz als volumenbegrenztes Fallback-Szenario sowie für besondere Einsatzszenarien (z. B. die Entwicklung von Software) • Zum Einsatz kommt aktuell die Desktop-Virtualisierung-Lösung von Citrix. • Die Nutzung ist von Extern möglich, z. B. von zuhause im Rahmen von Mobilarbeit über einen privaten PC. • Hinweis: Die Bereitstellung von passender Hardware, um auf VDI zuzugreifen, obliegt dem AN. (s. Leistungsbewertung, Kriterium A7)
2.4.6 Drucker • Druckerhardware ➢ Arbeitsplatzdrucker, Netzwerkdrucker, Multifunktionsdrucker und Sonderdrucker, Verbrauchsmaterial • Druckerbezogene Software (z. B. Treiberinstallation und -tests, Software für Druckermanagement und sicheren Netzwerkdruck: ➢ »Follow-Print« ➢ »Offline-Print«
Seite 12 von insgesamt 81 Seiten
[Seite 13]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
2.5 Betriebstools
Die folgende Tabelle gibt einen Überblick über die wesentlichen, im IT-Betrieb der BA eingesetzten Werkzeuge:
| Umfeld | Tool/Werkzeug | ||||
|---|---|---|---|---|---|
| Automatisierung und Jobautomation | Automation Engine AE (ehem. UC4) | ||||
| Microsoft – Azure DEVOPS Services | |||||
| FNT-Command | |||||
| FNT-Service Planet | |||||
| Sicherung | ARCserve UDP | ||||
| Netzwerkmonitoring | Microfocus Network Node Manager | ||||
| Systemmonitoring | MS System Center Operations Manager (SCOM) | ||||
| Metrik Monitoring (Telegraf, TimescaleDB, Prometheus, Grafana) | |||||
| Softwareverteilung | MS System Center Configuration Manager | ||||
| Applikations-Monitoring | u. a. Dynatrace, Automai (EUE) | ||||
| Log-Monitoring | Elastic Stack (Beats, Logstash, Elasticsearch, Kibana) | ||||
| Eventkorrelation | MS System Center Service Manager | ||||
| MS System Center Orchestrator | |||||
| IT-Sicherheit | ISMS-Tool der BA | ||||
| IT-Prozessunterstützung | ServiceNow | ||||
| Datenbank-Monitoring | Oracle Enterprise Manager |
Tabelle 1: Übersicht der Betriebstools
Neben den allgemeinen Betriebstools werden im E-AKTE-Betrieb noch folgende zusätzliche Anwendungen und Werkzeuge eingesetzt:
| Anwendungen und Werkzeuge | Beschreibung sowie Besonderheiten | ||||
|---|---|---|---|---|---|
| Atlassian Confluence / Jira | |||||
| APM (Application Performance Monitoring) | Performance Analysen anhand von Dashboards, Kibana, Eigenentwicklung, ELK, etc. | ||||
| Putty | |||||
| WinSCP | |||||
| Admin-Tools | Eine Scriptsammlung zur Wartung, SW-Versorgung, Prüfung und Verwaltung von bestehenden Systemen. Eigenentwicklung basierend auf Bash, Perl, Python, JAVA, SQL – PHP, Javascript für Webseiten, Powershell | ||||
| SQL-Developer | Backend SQL Bash, SQL | ||||
| Reporting Tools | Performance Web (Eigenentwicklung der BA) |
Tabelle 2: Übersicht der speziellen Betriebstools des E-AKTE-Betriebs
Seite 13 von insgesamt 81 Seiten
[Seite 14]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
2.6 Softwareentwicklungsmethodik
Die wesentlichen E-AKTE-Komponenten (vor allem E-AKTE-Client und E-AKTE-Services) sind auf Basis der Programmiersprache Java in Verbindung mit einer Java EE-Architektur entwickelt worden:
• Der E-AKTE-Client ist als Java RichClient entwickelt worden (SmartClient-Framework basierend auf Swing). • Die E-AKTE-Services werden als Enterprise JavaBeans realisiert und stellen die jeweiligen Services als Dienste für den Client zur Verfügung.
Da es sich bei dem E-AKTE-System um eine Rich-Client-Architektur handelt, kommen die Web-basierten Komponenten der „Java EE“-Plattform wie z.B. „Java Server Faces“, „Java Server Pages“ oder „Java Servlet API“ derzeit nicht zum Einsatz. Vom AN zu beachten sind im Rahmen der Entwicklung die Releasetermine und die Verfügbarkeit der verschiedenen Testumgebungen.
2.7 Fachliche Tests und Testautomatisierung
Fachliche Tests finden auf verschiedenen Teststufen gemäß dem »ISTQB«®-Standard durch den AN statt. So sind bei der Softwareentwicklung nach dem V-Modell für Unittests verbindlich funktionale Tests auf Basis von QS-gesicherten Komponentenspezifikationen vorgesehen. Ähnliches gilt für Komponentenintegrationstests, die technisch wie Unittests realisiert werden. Funktionale Systemtests (d.h. aus Sicht des Endanwenders) bilden hier im Allgemeinen die umfangreichste Teststufe. Bei agiler Vorgehensweise folgt man dem Prinzip, funktionale Tests bzw. das „Continuous Deployment“ zu unterstützen. Die automatisierte Testdurchführung ist in allen Teststufen vorgesehen. Für fachlich motivierte Tests und den Test von Webservices kommt in der Testautomatisierung die in der BA entwickelte schlüsselwortbasierte Testfall-Notation zum Einsatz. Diese ermöglicht auch die manuelle Testdurchführung. Zur Testautomatisierung werden »Eclipse«, »JUnit« und »Silk4J« eingesetzt. Das auf der Schlüsselwortnotation basierende Testautomatisierungsframework unterstützt auch die Testausführung auf der eingeführten Containerplattform. Inhaltliches Rahmenwerk für alle Testaktivitäten ist die BA-Teststrategie, die sich umfassend an den Standards des »ISTQB«® orientiert. Erforderliche Informationen aus der BA- Teststrategie werden zur Verfügung gestellt.
Seite 14 von insgesamt 81 Seiten
[Seite 15]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Abb. 2 V-Modell Testmanagement
• Modultest und Vorintegrationstests: Entsprechen dem Unit Test, Komponenten- Integrationstest und Systemtest, welche im Rahmen der Entwicklung, des Konfigurationsmanagements und der fachlichen Tests durchgeführt werden. • Integrationstest: Entspricht dem Systemverbundtest des »E-AKTE-DMS«-Produkts. • Freigabe: Entspricht der Freigabe des Produktes bzw. der Anforderung sowie des Testberichts durch den Bedarfsträger.
Für jede Teststufe werden bestimmte Testobjekte identifiziert. Die Testobjekte bilden den Testgegenstand, der getestet werden soll. Zu jedem Testobjekt gehören Testfälle, die gewährleisten, dass sämtliche Verhaltensweisen des Testobjektes verifiziert werden. Die Testobjekte werden zum Teil über Anwendungsfälle abgebildet, die die Grundlage für die Testfälle bilden. Das detaillierte Testvorgehen innerhalb des E-AKTE-DMS für die einzelnen Teststufen und Testarten (Sicherheitstests, Reviews, Lasttests etc.) wird auf Basis der BA-Teststrategie in den nachfolgenden Abschnitten beschrieben. Testobjekte Hier wird zusammengefasst, wie das zu testende System aufgebaut ist, d.h. aus welchen (BA- eigenentwickelten) Komponenten es besteht und welche davon getestet werden (Testobjekte). Testobjekte sind der E-AKTE-DMS-Server, Batch-Komponenten, E-AKTE-DMS-Client sowie die Datenhaltung mittels Datenbank. Strukturierte fachliche Themenbereiche, die zu testen sind (inkl. technische Trennung von Client und Service): • Scan-Auftragsverwaltung: Aufträge an den Scan-Dienstleister werden über diesen Testbereich erzeugt, verwaltet und bearbeitet (z.B. Auftrag Rescan, Auftrag Digitalisierung, etc.). o Client: Scan-Auftragsverwaltungsoberfläche (GUI), o Service: Scan-Auftragsservice (Fachlogik).
Seite 15 von insgesamt 81 Seiten
[Seite 16]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Postkorbverwaltung: Übernimmt die Verwaltung und Steuerung von Postkörben und Aufträgen sowie deren Abwicklung (z.B. Auftragsliste abrufen, Vorgang öffnen, etc.). o Client: Postkorbverwaltungsoberfläche (GUI), o Service: Postkorbservice (Fachlogik). • Aktenverwaltung: Akten und deren Strukturen werden verwaltet und in strukturierter Form dargestellt und ihre Metadaten geändert (z.B. Akte anlegen, Akte öffnen, Aktensegment erstellen, Versandpaketverwaltung, etc.). o Client: Aktenverwaltungsoberfläche (GUI), o Service: Aktenservice (Fachlogik). • Dokumentenverwaltung: Hier werden die Dokumente in Form ihrer Meta- und Inhaltsdaten (Images) verwaltet, dargestellt und ihre Metadaten geändert. o Client: Dokumentenverwaltungsoberfläche (GUI), o Service: Dokumentenservice (Fachlogik). • Übergabe / Import: Die Übergabe- und Importfunktionalität des Systems dient dem Versand und dem Empfang von Dokumenten der Fachverfahren über die angebundenen Schnittstellen (s. Kapitel 2.10), Quittungen und Referenzdaten zum und vom Scandienstleister innerhalb der BA sowie der damit verbundenen Fehlerbehandlung sowie dem Datenaustausch mit den angebundenen Fachverfahren. • übergreifende Testbereiche o Nachrichtenservice (DIANA (Datenübertragungstechniken), KAFKA) zum Datenaustausch, o Administration: Systemadministration und fachliche Administration, o generischer Druckertreiber (E-AKTE-Drucker), o E-ARCHIV, o Regelwerk, o Monitoring, o Batchverarbeitung / Jobsteuerung, o Authentifizierung und Autorisierung (Benutzermanagement), o Schnittstellen, o Provisionierung.
2.8 Sicherheit
Das BA-Vorgehen im Rahmen der Erstellung eines verfahrensspezifischen IT- Sicherheitskonzeptes (vSiko) ist an den IT-Grundschutz nach den BSI-Standards 200-1, 200- 2 und 200-3 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) angelehnt. Für die E-AKTE existiert ein aktuelles vSiko mit Freigabe vom 30.03.2026. Die Freigabe des vSikos erfolgt mindestens jährlich. Hierbei hat der AN die BA zu unterstützen (s. Kapitel 5.7.5 und Leistungsbewertung, Kriterium A3).
2.8.1 Sicherheitsanforderungen Die folgenden Anforderungen sind vom AN vollständig zu erfüllen.
Seite 16 von insgesamt 81 Seiten
[Seite 17]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
2.8.2 Anbindung von Tools Der AN hat initial mindestens die folgenden Tools mittels einer »AppSec (Application Security) Pipeline« anzubinden. Diese werden von der BA dem AN bereitgestellt:
• CheckMarx (Static Application Security Testing (SAST)) • Nexus IQ (Open Source Lib Scanner: Vulnerabilities / OSS Lizenzen) • SMaRT (Eigenentwicklung der BA: Fokus auf Schwachstellen in Kaufsoftware)
2.8.3 Sicherheitskonzept Der AN hat die BA bei der Erstellung eines Sicherheitskonzepts nach BSI-Standard 200-2 unter Verwendung des IT-Grundschutz-Kompendiums (aktuelle Edition) oder vergleichbar konform der Standard-Absicherung umfassend zu unterstützen. Ziel des Sicherheitskonzeptes ist, auf der Grundlage einer sorgfältigen Bewertung des Schutzbedarfes (auf Basis der Schutzziele Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität) und möglicher Risiken, technische und organisatorische Maßnahmen bezogen auf den Ausschreibungsgegenstand zu beschreiben, die störungsfreie und gegen Missbrauch, Manipulation und Datenverlust geschützte Funktionen des Ausschreibungsgegenstandes gewährleisten zu können.
2.8.4 Informationssicherheitsmanagementsystem Die Steuerung der Informationssicherheit im relevanten Anwendungsbereich (Ausschreibungsgegenstand) erfolgt anhand eines Informationssicherheits- managementsystems (ISMS). Das ISMS-Tool der BA dokumentiert die Informationssicherheit der E-AKTE.
2.8.5 Auditrecht Die BA ist nach ISO 27001 auf Basis IT-Grundschutz zertifiziert. Des Weiteren ist die BA als Betreiber kritischer Dienstleistungen verpflichtet, für einen sicheren und zuverlässigen Betrieb ihrer IT-Systeme und Einrichtungen zu sorgen und die Verfügbarkeit der kritischen Dienstleistungen uneingeschränkt zu gewährleisten. Grundlage ist das Dokument »Konkretisierung der Anforderungen an die gemäß § 8a Absatz 1 und Absatz 1a BSIG umzusetzenden Maßnahmen«. Aus diesen Gründen ist eine Überprüfung der Leistungen des AN in Bezug auf den Managed Service der E-AKTE durch die BA notwendig. Die Umsetzung erfolgt in regelmäßigen Security- Reifegrad-/KRITIS-Audits. Diese finden im Regelfall remote statt. Ziel soll es sein, dass der AN und seine Leistung jährlich auditiert und Befunde frühzeitig dokumentiert und abgestellt werden können. Dadurch soll das erreichte Sicherheitsniveau der BA mindestens gehalten und sogar verbessert werden. Die Prüfgrundlage orientiert sich dabei an den vertraglich vereinbarten Sicherheitsanforderungen, den Anforderungen des IT- Grundschutz-Kompendiums in der aktuellen Edition und den Richtlinien zur Informationssicherheit der BA, welche im Rahmen der Erbringung der Managed Service- Leistung notwendig sind. Zur Durchführung der Audits erteilt der AN der BA ein Auditrecht in Bezug auf den Ausschreibungsgegenstand und unterstützt die BA (s. Kapitel 4 sowie 5.5).
2.9 Eingesetzte Werkzeuge und Standards/Frameworks
Im Folgenden sind die wichtigsten Werkzeuge und Standards/Frameworks, welche bei der E- AKTE der BA zum Zeitpunkt dieser Ausschreibung eingesetzt werden, aufgeführt. Der AN hat sämtliche Abweichungen von den hier genannten (oder während der Vertragslaufzeit diese ersetzenden/ergänzenden) Werkzeuge und Standards/Frameworks im Zuge seiner Leistungserbringung vorher mit der BA abzustimmen.
Seite 17 von insgesamt 81 Seiten
[Seite 18]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Nr. | Name des eingesetzten Werkzeugs | Kommentar |
|---|---|---|
| 1 | Adobe Reader | |
| 2 | Apache Subversion (SVN) | |
| 3 | Avi Loadbalancer | |
| 4 | AWI | (Tool von Broadcom für die Batchjobs / früher UC4) |
| 5 | BASH | |
| 6 | CertNanny | |
| 7 | Confluence | |
| 8 | Dynatrace / INSTANA | |
| 9 | Eclipse | |
| 10 | Elasticsearch | |
| 11 | GIT, Bitbucket | Bitbucket wird derzeit verwendet, 2027 Wechsel zu GitHub |
| 12 | Grafana | |
| 13 | Hashicorp | |
| 14 | IBM ESM (Enterprise System Monitoring) | Monitoringtool (Websphere, FileNet) |
| 15 | IntelliJ | |
| 16 | Jadice Viewer (Levigo) | derzeit in Evaluierung, Wechsel zu einem anderen PDF-Viewer in Zukunft möglich |
| 17 | JAWS / Supernova | |
| 18 | Jenkins, Maven, ANT | |
| 19 | Jira | |
| 20 | Jython / Python | |
| 21 | Kibana | |
| 22 | Microsoft AD LDS (Active Directory Lightweight Directory Service) | |
| 23 | MID Innovator | u. a. Testwerkzeug und Anforderungsgrundlage für das fachliche Modell der E-AKTE |
Seite 18 von insgesamt 81 Seiten
[Seite 19]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| 24 | ||
|---|---|---|
| 25 | PowerShell | |
| 26 | Rancher | |
| 27 | RocketChat | |
| 28 | S3 Browser | |
| 29 | Seerene | |
| 30 | Service Now | |
| 31 | Servlets* | |
| 32 | SilkCentralTestmanager / Aqua | |
| 33 | SilkPerformer / Loadrunner / Jmeter | |
| 34 | SilkTest | derzeit in Ablöse, Nachfolge noch nicht bekannt |
| 35 | soapUI | |
| 36 | SonarQube | |
| 37 | SQL Developer | |
| 38 | Tamara (Testautomatisierungsframework auf Java-Basis) / Robot Framework | |
| 39 | Windows 11 | |
| 40 | Windows Server und SQL Server |
Tabelle 3 Eingesetzte Werkzeuge
Seite 19 von insgesamt 81 Seiten
[Seite 20]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Nr. | Name des eingesetzten Standards / Frameworks | Kommentar |
|---|---|---|
| 1 | .NET | |
| 2 | Checkmarx | |
| 3 | Docker | |
| 4 | FileNet | |
| 5 | Java 8 / 11 / 17 / 21 | OpenJDK, Azul, IBM-JRE |
| 6 | JavaEE 8 / JakartaEE 11 | |
| 7 | Kafka | |
| 8 | Kubernetes | |
| 9 | Log4j | |
| 10 | JUnit, DBUnit | |
| 11 | JPA/EclipseLink | |
| 12 | Nexus IQ | |
| 13 | NodeJS | |
| 14 | Websphere | |
| 15 | REST | |
| 16 | Oracle 12c | |
| 17 | iText | |
| 18 | JAWS | |
| 19 | LunarPlus | |
| 20 | Apache Pekko | |
| 21 | S3 | |
| 22 | SUSE Linux (Serverbetriebssystem) | |
| 23 | Windows 11 (Clientbetriebssystem) | |
| 24 | Windows (Serverbetriebssystem) | |
| 25 | Quarkus |
Tabelle 4 Eingesetzte Standards / Frameworks
Seite 20 von insgesamt 81 Seiten
[Seite 21]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
*Zusätzlich zu den eingesetzten Werkzeugen erstellt und verwendet die BA weitere Servlets (Upload- und Download sowie Betriebs- und Admin-Servlets), deren Pflege und Weiterentwicklungen Teil des Managed Service des AN sein werden. (s. Kapitel 5.7) Zusätzlich zu den vorgenannten eingesetzten Technologien und Standards/Frameworks wird die E-AKTE der BA kontinuierlich über eine geplante Technologie-Roadmap an die komplexen Rahmenbedingungen der Digitalisierung des IT-Systemhauses und des Leistungsbereiches der BA angepasst. Seit 2026 stehen z.B. folgende Themen auf der Agenda:
• Major- und Minor- Versionswechsel beigestellter Produkte: z.B. Oracle RAC Das IT-Systemhaus der BA untersucht innovative Konzepte und setzt diese um. Je nach Notwendigkeit und Anforderung wird die Technologie-Roadmap der E-AKTE der BA während der Vertragslaufzeit gemäß Kapitel 8 angepasst bzw. weiterentwickelt werden.
2.10 Schnittstellenpartner
2.10.1 Überblick Die E-AKTE verfügt über mehr als 130 Schnittstellenpartner, die Schnittstellen unterschiedlicher Art zur Dokumentenverwaltung und Kommunikation nutzen. Der Traffic beläuft sich insgesamt auf ca. 1,52 Mio. Dokumente (inkl. Referenzdaten) pro Tag. Dementsprechend kommen den Schnittstellen der E-AKTE eine sehr hohe Bedeutung zu.
• Synchrone Schnittstellen, u. a REST/SOA
• Asynchrone Schnittstellen, u. a. Kafka, Filetransfer (Batch)
2.10.2 Angebundene Schnittstellen Es gibt verschiedene Kategorien angebundener Schnittstellen. Diese sind u.a.:
• Intranet-Fachverfahren, genutzt durch interne Anwender der BA u. a. VERBIS, ALLEGRO oder E-JUSTIZ
• Basisdienste, KRITIS-relevante* Schnittstellen (KIWI, ALLEGRO, die Personendatenbank STEP) oder das E-ARCHIV
• Externe Systeme wie die DPAG als Scandienstleister
• Interne Systeme im Kontext der E-AKTE, wie der E-AKTE Client oder diverse Microservices u. a. zum Import von Dokumenten
• Onlineservices, genutzt durch Kunden der BA, u. a. zur Antragstellung und Veränderungsmitteilung, aber auch Postfachkommunikation Die Schnittstellenpartner sind an die E-AKTE sowohl als Producer (z. B. zur Dokumentenübergabe) als auch als Consumer (z. B. zum Abruf strukturierter Daten von Dokumenten) angebunden. Die Kommunikation erfolgt hierbei sowohl synchron als auch asynchron. *Die BA nutzt REST-Services von IT-Fachverfahren für die Echtzeit-Plausibilisierung von Fachschlüsseln; z. B. Kundennummer, Kindergeldnummer, Bedarfsgemeinschaft, usw. Wenn deren Funktion gestört ist, muss (von der verursachenden Stelle unabhängig) durch den AN unverzüglich eine Analyse und Behebung erfolgen. (s. hierzu Kapitel 5.3)
Seite 21 von insgesamt 81 Seiten
[Seite 22]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
3 Rahmenbedingungen
3.1 IT-Service-Management-Prozesse
Die Ablauforganisation des IT-Systemhauses ist über ITSM-Prozesse spezifiziert, die sich am internationalen Standard ISO/IEC-20000 und der IT Infrastructure Library (ITIL) orientieren. Die einzelnen Aktivitäten und Schnittstellen sind zusammen mit den unterschiedlichen Rollen und Verantwortlichkeiten in einem Prozessmodell beschrieben. Für alle im IT-Systemhaus tätigen Mitarbeiter und Dienstleister ist die Nutzung der ITSM- Prozesse bezüglich aller eingesetzten technischen Produkte, IT-Services und Services Betrieb Infrastruktur (SBI) verbindlich. Sie werden bei ihren Aktivitäten innerhalb der ITSM-Prozesse durch spezielle Tools unterstützt. Ein Großteil der ITSM-Prozesse nutzt aktuell hierfür ServiceNow, in dem die Arbeitsabläufe gesteuert durchgeführt werden und in dem beispielsweise auch der UHD (s. Kapitel 3.4 und 13) die gemeldeten Störungen der Anwender erfasst. Aktuell sind 14 ITSM-Prozesse bebaut (Prozessmodell, Kennzahlen, Toolunterstützung, Prozesssteuerung).
Abbildung 1 Prozesslandkarte der IT-Betriebsprozesse
3.2 Betriebssprache
Das vom AN eingesetzte Personal muss die deutsche Sprache in Wort und Schrift beherrschen und in der Kommunikation mit den Beschäftigten der BA anwenden. In der englischen Sprache ist ein gutes Sprach- und Lese-Verständnis erforderlich. Die vom AN erstellte Servicedokumentation bzw. eine Berichterstattung erfolgt ausschließlich in Deutsch. Der benannte Ansprechpartner (s. Kapitel 9.1.1) sowie seine Vertretung müssen mindestens über Sprachniveau C1 verfügen.
Seite 22 von insgesamt 81 Seiten
[Seite 23]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Die vorausgesetzte Niveaustufe der Sprachfertigkeiten ist mindestens B2. Das Sprachniveau B2 beschreibt eine fortgeschrittene Sprachkompetenz (obere Mittelstufe). Es bedeutet, in der Lage zu sein, Alltagssituationen souverän zu meistern, komplexere Texte zu verstehen sowie spontan und fließend mit Muttersprachlern zu kommunizieren, ohne dass dies für beide Seiten große Anstrengungen erfordert. Die Niveaustufen stammen aus dem sogenannten „Gemeinsamen Europäischen Referenzrahmen für Sprachen“ des Europarats. (s. Leistungsbewertung, Kriterium A1)
3.3 Anforderung an den AN
Die Tätigkeiten im Rahmen des Managed Service werden durch den AN geplant und durchgeführt. Beim ersten Einsatz wie auch bei einem Wechsel des eingesetzten Personals ist zu berücksichtigen, dass eine erweiterte Sicherheitsüberprüfung (Ü2) nach § 9 SÜG für den (in der BA) neuen Dienstleister durchzuführen ist. Der AN wird bei planbaren Austauschen anderes Personal nur dann einsetzen, wenn das neue Personal vorab vollständig für Tätigkeiten aufgrund dieser Leistungsbeschreibung vorbereitet wurde. Das heißt, der AN stellt sicher, dass bei eigenem Personalwechsel bzw. bei der Einarbeitung bislang nicht an dieser Stelle eingesetzter Teammitglieder sich diese schnell in die Abläufe und Aufgaben des neuen Aufgabenfeldes einarbeiten können. Die Einarbeitung bzw. Schulung neuer Dienstleister hat der AN selbst sicherzustellen, die geschuldete Leistungserbringung darf darunter nicht leiden bzw. verzögert werden. Zudem ist ein kompakter Wissenstransfer sicherzustellen, um die Einarbeitungszeit zu reduzieren. Diese gilt auch bei Abwesenheiten von einzelnen Dienstleistern. Die gesamte Team- Leistungsfähigkeit darf durch ungeplante bzw. geplante Abwesenheit einzelner Dienstleister nicht negativ berührt werden. Die BA kann (z. B. aufgrund von unethischem Verhalten) den sofortigen Austausch eines oder mehrerer für die Leistungserbringung eingesetzter Dienstleister des AN verlangen, wenn ein wichtiger Grund dazu vorliegt.
3.4 Leitlinien zur Leistungserbringung
Im folgenden Abschnitt werden einige abgestimmte »Leitlinien« für die Leistungserbringung beschrieben – die Liste ist nicht abschließend, sie soll das gemeinsame Verständnis jedoch verdeutlichen und erläutern.
• Der AN gewährleistet durch seine Leistungen im Rahmen des Managed Service den Betrieb der E-AKTE durch die BA mit hoher Stabilität (s. Kapitel 5.10.3). Die Sicherstellung des laufenden Betriebs, dessen Optimierungen, kurzfristige Störungsbehebungen und stabile Veränderungsabläufe sind daher wesentliche Ziele.
• Eine im Rahmen des Managed Service (z. B. durch die fachliche und technische Weiterentwicklung) erfolgte Optimierung der bestehenden Abläufe und Tätigkeiten darf nicht zu laufenden Mehraufwendungen bei anderen Bereichen führen. Nimmt der AN technische Optimierungen an den Systemen vor, so ist durch ihn sicherzustellen, dass diese den Security-Richtlinien der BA entsprechen. Zudem sind derartige Maßnahmen vorab mit der BA zu besprechen. Die BA behält sich ein Veto der Umsetzung vor. Durchgeführte Optimierungen (z. B. Automatisierungen oder Monitoring- Verbesserungen) müssen dokumentiert und so ausgeführt werden, dass diese reversibel zum ursprünglichen Stand sind.
• Als weitere wichtige Rahmenbedingung ist die verbindliche Einhaltung von Umsetzungsterminen vom AN zu berücksichtigen. Hier gelten die Terminvorgaben aus dem Release-Management und dem Anforderungsmanagement für die verschiedenen Umgebungen.
Seite 23 von insgesamt 81 Seiten
[Seite 24]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• In der Zusammenarbeit mit der BA ist ein entsprechendes seriöses Auftreten und Verhalten ist wichtig und wird grundsätzlich vorausgesetzt.
• In der Zusammenarbeit mit dem UHD gibt es zusätzliche Vorgaben der BA, die der UHD einzuhalten hat. Die Zusammenarbeit beruht auf einer sachlichen und lösungsorientierten Ebene, Diskussionen mit dem UHD sind zu vermeiden, der AN informiert ggf. die BA bei Auffälligkeiten.
• Der AN bemüht sich aktiv um den Erhalt bzw. Aufbau seiner Leistungsfähigkeit (z. B. durch Übertragung gefundener Lösungen auf andere Fehlerbilder oder durch die aktive Reduzierung bekannter Fehler, verbesserte Automation bzw. verfeinerte Betriebsüberwachungen oder durch Härtung der Anwendungen etc.). Der PRO- Prozess ist entsprechend anzuwenden.
• Findings (s. Glossar, Kapitel 13), die zu einem erhöhten Ticketvolumen führen oder führen können, sind vom AN aktiv und unverzüglich an den benannten Ansprechpartner der BA zu melden.
• Der AN stellt sicher, dass bei Personalwechsel bzw. bei der Einarbeitung neuer MA sich diese schnell in die Abläufe und Aufgaben des Bereichs einleben können. Die Ausgliederung, den Arbeitsübergang, die Einarbeitung bzw. Schulung neuer MA hat der AN selbst sicherzustellen, die Serviceerbringung darf dadurch nicht negativ beeinflusst werden. Zudem ist ein kompakter Wissenstransfer sicherzustellen, um die Einarbeitungszeit zu reduzieren, bzw. bei Abwesenheiten von einzelnen MA den Service dennoch stabil erbringen zu können. Die Einarbeitung ist anzeigepflichtig und für die BA kostenneutral.
• Die benannten Prozessvorgaben der BA sind zu erfüllen, insbesondere gilt das für die vereinbarten, bereichsübergreifenden KPI der Prozesse. Im Leistungszeitraum durchgeführte Anpassungen der Prozessvorgaben sind einzuhalten. Werden im Bereich K52 ergänzende Regelungen zu den Prozessen vorgenommen, so gelten diese zusätzlich bzw. vorrangig.
• Der AN gibt aktiv neue Informationen und zugewonnenes Know-How an die BA weiter durch Dokumentation und Verlinkung zu entsprechenden Einträgen in der Knowledge- Base.
3.5 Erforderliche Funktionskenntnisse
Zur Aufgabenerfüllung sind neben Kenntnissen in den in Kapitel 2.9 erwähnten Werkzeugen, Frameworks und Standards u.a. folgende funktionale Kenntnisse des AN erforderlich:
| Kenntnisse bei der Umsetzung von... | Beschreibung / Besonderheiten | ||||
|---|---|---|---|---|---|
| Unternehmenssicherheit | Berücksichtigung der geltenden Sicherheitskonzepte; Pflege, Fortschreibung und Aktualisierung der Sicherheitskonzepte | ||||
| Administration FileNet inkl. Durchführung der Deployments, Updates und Upgrades | |||||
| Fehleranalyse und Störungsbeseitigung | U.a. durch Auswertung von Logfiles | ||||
| Management, Monitoring, Alerting von Datenbanken mit Standardtools | Oracle und MS SQL-Datenbanken | ||||
| ITIL-Kenntnisse | Insbesondere INC / PRO / CHG / RGB (s. Leistungsbewertung, Kriterium A2) | ||||
| Test-Kenntnisse | »ISTQB«®-Zertifizierung | ||||
| Monitoring der Anwendungen | CloudControl, ESM | ||||
| Serveradministration der Verfahrensserver | Linux- und Windowsserver, MS SQL-Server |
Seite 24 von insgesamt 81 Seiten
[Seite 25]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Sprachen (Expertenlevel) | • Java • JavaScript/TypeScript • SQL • Python • ShellScript • C/C++ |
|---|---|
| Sprachen sonstige | • HTML / CSS • XSLT • UML für MID-Innovator |
| Techstack (Expertenlevel) | • IBM FileNET P8 (Zertifikat: »IBM Certified Deployment Professional - FileNet P8«, Kursbestätigung: »IBM FileNet P8 Platform Essentials«) • Oracle-Datenbanken (Oracle Database@AWS Architect Professional, Kursbestätigung »Exam 1Z0-071: Oracle Database SQL«) • WebSphere (Zertifikat: »WebSphere ND 9.0.5.23« oder neuer, »IBM Certified Administrator, WebSphere Application Server Network Deployment v9.0.5«) • INSTANA • MS SQL • Kubernetes / Rancher • Quarkus |
| Techstack sonstige | • MS Office API und AddIns • Eclipse Framework • Microsoft Power BI • KeePass, Bitwarden, HashiCorp |
Tabelle 5: Übersicht der erforderlichen Funktionskenntnisse
4 Ausschreibungsgegenstand
4.1 Nicht optionale und optionale Leistungen
Durch den AN sind im Leistungszeitraum folgende Leistungen zu erbringen: Hauptleistungen: • Managed Service für die E-AKTE (s. Kapitel 5) Sonstige Leistungen: • Vorlaufende Transition, nicht optional (s. Kapitel 7.1) • Abschließende Transition, optional (s. Kapitel 7.2) • Exit-Management, nicht optional (s. Kapitel 7.3) • Ergänzendes DL-Kontingent, optional (s. Kapitel 7.4)
4.2 Gegenstand der zu erbringenden Leistungen
4.2.1 Beschaffungsgegenstand Beschaffungsgegenstand ist ein Managed Service zur Bereitstellung des Systems E-AKTE als produktionsreifer Liefergegenstand und aller dafür notwendigen fachlichen und technischen Entwicklungsarbeiten (hinsichtlich gesetzlicher Anforderungen und Standard-Anforderungen), Qualitätssicherung und Pflegearbeiten an der E-AKTE der BA (kritische Infrastruktur), sowie Schnittstellenkommunikation und die Anbindung weiterer Verfahren und Projekte an den
Seite 25 von insgesamt 81 Seiten
[Seite 26]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Basisdienst. Dazu gehört die Durchführung der Anwendungsentwicklung E-AKTE inkl. Analyse des Anwendungsdesigns bei Änderungen an der Oberfläche sowie Beurteilung der Auswirkungen auf die Konfiguration und Infrastruktur. Das IT-Systemhaus der BA verantwortet die IT-Betriebsführung und übernimmt diese. Dies schließt die Bereitstellung der dafür notwendigen IT-Infrastruktur mit ein.
4.2.2 Konkretisierung und Abgrenzung Der Beschaffungsgegenstand betrifft ausschließlich die Weiterentwicklung und Pflege des für die BA erzeugten spezifischen Codes der zum Zeitpunkt der Ausschreibung in der BA im Einsatz befindlichen E-AKTE. Die Pflege und der Support sowie die Überlassung und Verwaltung von Lizenzen beigestellter Kauf-Software (Oracle WLS/Websphere und Datenbankmanagement-Software, Jadice Viewer, INSTANA etc.) sind nicht Bestandteil der vorliegenden Ausschreibung. Zudem verbleibt der Betrieb der produktiven Umgebungen (TDST und DST) inkl. der dazugehörigen Microservices bei der BA. Die vom AN zu erbringenden Leistungen müssen die BA in die Lage versetzen, auf kurzfristig entstehende, veränderte oder neue Anforderungen in der Kunden– und Anwenderunterstützung und in der Informationstechnik erfolgreich reagieren zu können. Die durch den AN im Bereich der Softwareentwicklung im beschriebenen technologischen Umfeld (s. Kapitel 2) zu erbringenden externen Leistungen betreffen die Weiterentwicklung und Pflege der Anwendung E-AKTE der BA mit den Bereichen:
• Scan-Auftragsverwaltung
• Postkorbverwaltung
• Aktenverwaltung
• Dokumentenverwaltung
• Reporting
• Übergabe/Import
• Massendatenverarbeitung bzw. Batches
• Interne und externe Schnittstellen Dabei sind folgende Disziplinen betroffen:
• Anforderungsmanagement
• Software-Architektur
• Design und Implementierung bzw. Softwareentwicklung incl. Test
• Umgebungsmanagement und Build & Deployment
• Projekt- bzw. Verfahrensmanagement. Der AN gewährleistet die Erfüllung sämtlicher Anforderungen, die sich aus der Leistungsbeschreibung ergeben. Er hat Zugang zum Quellcode der E-AKTE und kann diesen nach Absprache/Information mit der BA verändern. Der AN ist im Zuge seiner Leistungserbringung im Krisenfall (K-Fall, s. Kapitel 8.4.2) zur umfassenden Unterstützung der BA verpflichtet, auch wenn der operative Betrieb des Produktivsystems gegenüber den Kunden durch die BA erfolgt, da es sich bei der E-AKTE um ein KRITIS-Verfahren handelt.
Seite 26 von insgesamt 81 Seiten
[Seite 27]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5 Managed Service
Sämtliche Leistungen, die in diesem Kapitel genannt werden, fallen im Leistungszeitraum des Managed Services (Leistungszeitraum 2) an.
5.1 Wiederkehrende Aufgaben
| Aufgaben | Beschreibung / Besonderheiten | ||
|---|---|---|---|
| Meilensteinplan in Kapitel 8.3 sowie | |||
| Bearbeitung von Demands | s. Kapitel 5.2 | ||
| Bearbeitung von Incidents | s. Kapitel 5.3 | ||
| Testmanagement | s. Kapitel 5.4 | ||
| Mitwirkung an Audits | s. Kapitel 5.5 | ||
| Teilnahme an Abstimmungsformaten | s. Kapitel 5.6 | ||
| Durchführung von Deployments / Pflege | s. Kapitel 5.7 | ||
| Dokumentation und Ablage von Arbeitsergebnissen | s. Kapitel 5.8 |
Tabelle 6: Übersicht der wiederkehrenden Aufgaben
5.1.1 Aufwandsschätzung Nur zum Zweck der Kalkulation findet sich im Folgenden die geschätzte Aufwandsverteilung für den Managed Service (s. Kapitel 5.1). Diese erhebt keinen Anspruch auf Richtigkeit und ist für die BA nicht bindend.
| Aufgaben | Aufwandsschätzung pro Vertragsjahr | ||||
|---|---|---|---|---|---|
| Bearbeitung von Demands (inkl. Incident- Bearbeitung) | 2.200 PT | ||||
| Testaufwand (inkl. Incident-Bearbeitung und Testmanagement) | 2.800 PT | ||||
| Mitwirkung an Audits | 2 PT | ||||
| Teilnahme an Abstimmungsformaten | 65 PT | ||||
| Durchführung von Deployments / Pflege | 1.100 PT | ||||
| Dokumentation und Ablage von Arbeitsergebnissen | 29 PT |
Gesamt pro Vertragsjahr 6.196 PT
5.2 Bearbeitung von Demands
5.2.1 Übersicht Der AN analysiert Demands (s. Glossar, Kapitel 13) und setzt diese um, inkl. Tests, Qualitätssicherung und der notwendigen dazugehörigen Dokumentation. Anschließend erfolgt die Übergabe der Deployment-Pakete an den Betrieb der BA sowie die Unterstützung des Betriebs beim Deployment und der Abnahme in den Produktionsumgebungen.
Seite 27 von insgesamt 81 Seiten
[Seite 28]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.2.2 Definition eines Demands Als »Demand« gelten fachliche oder technische Anforderungen der BA, die über den regulären Incident- oder Wartungsumfang hinausgehen. Hierzu zählen insbesondere Anpassungen, Erweiterungen, Konfigurationsänderungen, Weiterentwicklungen oder Analyseleistungen. Anforderungen entstehen aus der Weiterentwicklung bzw. den Vorgaben durch die BA. Die Koordination der Demands erfolgt durch die BA.
5.2.3 Direkt-Demand (Sonderform) Als »Direkt-Demand« gelten fachliche Anforderungen der BA, deren vorgegebene Bearbeitungszeit <10 AT betragen kann. Der »Direkt-Demand« ist nicht Bestandteil der Meilensteinplanung (s. Kapitel 8.3).
5.2.4 Beispiele/Vergangenheitswerte Die folgenden Beispiele/Vergangenheitswerte dienen zur Orientierung.
• Direkt-Demands (1,5 PT)
• Verzweigung zu IT-Fachverfahren (4,5 PT)
• Organisationsänderungen in RD-Bezirken (6 PT) • Anpassung eines Attributes in Referenzdatenspezifikation • Erstellung eines Kopierauftrages für mehrere Empfänger in einem Arbeitsschritt (15,1 PT) • KIWI: Attribut (z. B. Vorname Kind) an E-AKTE übermitteln (26 PT) • Schnittstellennutzung zwischen ALLEGRO und E-AKTE (10,5 PT) • Verzweigung zwischen E-AKTE und ERP (18,5 PT) • E-AKTE DMS Löschen von Fällen mit Schutzkennzeichen (13 PT) • Online-Bekanntgabe in der FamKa (9 PT) • EAKTE - Anpassung der Schnittstelle zum Postfachservice (15 PT) • Aktensuche/Aktentypsuche erweitern bei Schutzkennzeichen M (16 PT) • Schulungsdatengenerierung (4 PT) • mehrere Akten »gesammelt« abgeben (40,5 PT) • E-AKTE - FamKa: Pflege des Teamkenners auf Auftrags-Ebene (32,3 PT) • Mehrfachänderungen von Wiedervorlagen und Möglichkeit zur Bearbeitung/Löschung (35PT) • Sperren von Postkörben Dezentral ermöglichen (49,2 PT) • Gleichzeitiges Anbringen einer Dokumentenanmerkung/Verfügung an mehrere Dokumente (58PT) • Wechsel aus der Aktenansicht in den Bearbeitungsauftrag (43 PT) • Umhängen: Anzeige der Aktensegmente/ Unter-AS als Liste (73 PT) • Unveränderbare Anzeige (und Suche) der Online übermittelten Dokumentenbezeichnung der Kunden (81 PT) • E-JUSTIZ-BA/E-AKTE - Anhebung der Dateigröße bei Übernahme von Dokumenten aus E-JUSTIZ-BA (80 PT)
• E-AKTE/E-JUSTIZ-BA - Versand eines Repräsentats (135 PT)
Seite 28 von insgesamt 81 Seiten
[Seite 29]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Erfassung des Betreffs beim Anlegen eines Aktensegments bzw. Unteraktensegments (147 PT)
• Berücksichtigung/Unterstützung eines vierstelligen Teamkenners bei Organisationseinheiten in den IT-Fachverfahren (897 PT)
5.2.5 Einreichung durch die BA Die BA übermittelt Demands über das vereinbarte Ticketsystem oder einen sonst festgelegten Kommunikationskanal (zzt. Atlassian Jira). Jeder Demand enthält mindestens:
• Beschreibung des gewünschten Leistungsumfangs
• Zielsetzung und fachlicher Hintergrund
• Priorität und gewünschter Umsetzungstermin
• Betroffene Systeme, Schnittstellen oder Komponenten
• Ansprechpartner der BA
• Vorgabe zur Reaktionszeit durch den AN
• Akzeptanzkriterien
5.2.6 Erstbewertung und Aufwandsschätzung durch den AN Der AN prüft den Demand innerhalb der vorgegebenen Reaktionszeit auf:
• Vollständigkeit und Verständlichkeit
• Auswirkungen auf bestehende Systeme und Prozesse
• Abgrenzung zum bereits vereinbarten Leistungsumfang
• Erforderlichen Aufwand und notwendige Ressourcen Anschließend erstellt der AN eine Aufwandsschätzung inkl. Lösungsweg und reicht diese ein.
5.2.7 Beauftragung durch die BA Mit der Umsetzung eines Demands beginnt der AN erst nach schriftlicher Beauftragung durch die BA. Die Beauftragung wird über das Ticketsystem (z.Zt. Atlassian Jira) durch einen Eintrag im Kommentarfeld »im Release PRV_JJ_MM umsetzen«, Fix Version/s auf die richtige Version und gleichzeitig im Tool der Demand in den Status »Beauftragt« verändert.
5.2.8 Umsetzung Der AN setzt freigegebene Demands nach den im Managed Service geltenden Qualitäts-, Dokumentations- und Sicherheitsstandards um. Dabei gelten insbesondere:
• Nachvollziehbare Umsetzungsschritte
• Einhaltung der Coding-, Test- und Dokumentationsvorgaben
• Berücksichtigung der vereinbarten Betriebs- und Wartungsfenster
• Abstimmung mit der BA bei Risiken oder Abweichungen
Seite 29 von insgesamt 81 Seiten
[Seite 30]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.2.9 Priorisierung Werden mehrere Demands gleichzeitig beauftragt, erfolgt die Bearbeitung durch den AN entsprechend der gemeinsam abgestimmten Priorität. Die BA kann Prioritäten ändern; hierdurch können sich Termine anderer Demands verschieben.
5.2.10 Status und Kommunikation Der AN informiert die BA regelmäßig über den Bearbeitungsstand. Hierzu gehören mindestens:
• Eingang und Annahme des Demands
• Ergebnis der Erstbewertung
• Freigabe- bzw. Rückfragebedarf
• Fortschritt der Umsetzung Bei X-7 erwartet die BA einen BzA-Bericht über den aktuellen Status aller beauftragten Demands inkl. der offenen Fehler. Bei X-5 erwartet die BA einen FTNF-Bericht über das fertige Produkt.
• Abschlussmeldung
5.2.11 Fachliche Abnahme Nach Umsetzung stellt der AN die Ergebnisse zur Prüfung bereit. Die BA nimmt den Demand innerhalb einer vereinbarten Frist fachlich ab oder meldet Mängel bzw. Änderungsbedarf zurück. Hierfür gelten die Regelungen des Kapitels 5.10.3.3.
5.2.12 Dokumentation Der AN dokumentiert sämtliche umgesetzten Demands nachvollziehbar (zzt. in Jira und Confluence). Die Dokumentation umfasst mindestens:
• Beschreibung der vorgenommenen Änderungen
• Betroffene Systeme oder Komponenten
• Relevante technische und fachliche Dokumente
• Test- und Abnahmeergebnisse
5.3 Bearbeitung von Incidents (Support)
5.3.1 Leistungsumfang Incidents (INC) werden von der BA (zzt. über Atlassian Jira) übertragen und priorisiert. Ihre Bearbeitung durch den AN umfasst u. a. die Fehleranalyse, Fehlerbehebung und nachhaltige Störungsbeseitigung gemäß ITIL-Incident- und Problemprozess für die betreuten Verfahren. Der AN kann hierzu Fehleranalysen hinsichtlich des Anwendungsverhaltens durchführen, ggf. unter Verwendung spezieller Tools. Als Grundlage der Fehleranalyse dienen Fehlermeldungen der Anwender, Spezifikationsdokumente der Anwendungsfunktionalität, Fehlermeldungen der Anwendung an der Oberfläche, in Logfiles, sowie die Daten, die die Anwendungen über Schnittstellen mit anderen Anwendungen austauschen. Unter Verwendung der verfügbaren Tools werden Datenfehler, Performanceprobleme und Konfigurationsprobleme in Anwendungen analysiert und korrigiert. Alle Änderungen des Quellcodes der Anwendungen für die Ausführung der Leistung werden in den regelmäßig stattfindenden Abstimmungen (s. Kapitel 5.6) besprochen.
Seite 30 von insgesamt 81 Seiten
[Seite 31]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Die Bearbeitung von Incidents (INC) (z.B. technische Störungen, Fehler, Security-Tickets und Supportanfragen) ist Bestandteil der Managed-Service-Leistungen des AN und während der gesamten Vertragslaufzeit (s. Kapitel 8.1) kontinuierlich zu erbringen. Die Supportleistungen sind unabhängig von Release- oder Versionswechseln vollumfänglich sicherzustellen. Der AN hat den Support auch nach Durchführung von Releases, Deployments oder Versionswechseln uneingeschränkt fortzuführen. Dies umfasst insbesondere:
• Fehlermanagement: Strukturierte Erfassung, Klassifizierung und Behebung von Abweichungen inkl. Testfallerstellung (Ableitung aus Tickets aus der Produktion)
• Analyse, Bearbeitung und Behebung von Softwarefehlern (Bugs)
• Bearbeitung technischer Störungen, Security-Risiko-Tickets und Betriebsprobleme
• Unterstützung der BA bei operativen und technischen Fragestellungen
• Bereitstellung von Workarounds zur temporären Aufrechterhaltung des Betriebs
• Unterstützung bei Fehleranalysen und technischen Bewertungen
• Unterstützung von Task Forces bei Störungen der betreuten Verfahren
• Bearbeitung technischer Anfragen und Feature Requests
• Bereitstellung technischer Informationen und Handlungsempfehlungen Die Leistungen sind durch qualifizierte technische Support-Mitarbeiter des AN zu erbringen. Der AN hat sicherzustellen, dass der Support während der vereinbarten Servicezeiten (s. Kapitel 8.4) erreichbar ist. Die Erreichbarkeit hat mindestens über folgende Kommunikationswege zu erfolgen:
• Telefon über eine gültige Rufnummer (keine kostenpflichtige Sonderrufnummer)
• Ticketsystem der BA (z. B. zzt. Atlassian Jira) Der Support hat in deutscher Sprache zu erfolgen. Sofern dies im Einzelfall nicht möglich ist, ist eine Leistungserbringung in englischer Sprache zulässig. Technische Dokumentationen und Beschreibungen sind in deutscher und zusätzlich in englischer Sprache bereitzustellen. Der AN hat der BA einen Zugang zu einer bestehenden Knowledge Base bereitzustellen. (s. Leistungsbewertung, Kriterium A5) Im Störungsfall hat der AN unverzüglich alle erforderlichen Maßnahmen einzuleiten, um die Verfügbarkeit und Funktionsfähigkeit der E-AKTE schnellstmöglich wiederherzustellen. Des Weiteren hat er die nachfolgenden Reaktions- und Wiederherstellungszeiten verbindlich einzuhalten. Die Reaktionszeiten laufen innerhalb der Servicezeiten, die Wiederherstellungszeiten nicht.
| Störungsklasse | Bezeichnung | Beschreibung | Reaktionszeit in Stunden | Wiederher- stellungs- zeit |
|---|---|---|---|---|
| Prio 1 | Kritische Störung | Ausfall des Systems ohne Workaroundmöglichkeit, Datenschutzpanne, IT- Sicherheitsvorfall | bis zu 1h | bis zu 12h |
Seite 31 von insgesamt 81 Seiten
[Seite 32]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Prio 2 | Schwerwiegende Störung | Wesentliche Funktion nicht nutzbar; kein akzeptabler Workaround | bis zu 4h | bis zu 3 Arbeitstage |
|---|---|---|---|---|
| Prio 3 | Mittelschwer | Funktion eingeschränkt; Workaround vorhanden | bis zu 12h | Bis zu 10 Arbeitstage |
| Prio 4 | Leichte Störung | Technische Anfragen, Unterstützung, Feature Requests etc. | bis zu 24h | Nächster Release- Zyklus |
5.3.2 Bearbeitung von Security-Risiko-Tickets INCs, die von der BA als Security-Tickets definiert werden, erhalten im Ticketsystem der BA (z.B. zzt. Atlassian Jira) eine fortlaufende Nummer. Security-Risiko-Tickets erhalten darüber hinaus eine gesonderte Markierung. Für sie gelten die folgenden Regelungen zu den Reaktions- und Wiederherstellungszeiten:
| Störungsklasse | Bezeichnung | Beschreibung | Reaktionszeit in Stunden | Wiederher- stellungszeit |
|---|---|---|---|---|
| Prio 1 | Kritische Störung | Ausfall des Systems ohne Workaroundmöglichkeit, Datenschutzpanne, IT- Sicherheitsvorfall | bis zu 1h | Bis zu 20 Arbeitstage |
| Prio 2 | Schwerwiegende Störung | Wesentliche Funktion nicht nutzbar; kein akzeptabler Workaround | bis zu 4h | Bis zu 20 Arbeitstage |
| Prio 3 | Mittelschwer | Funktion eingeschränkt; Workaround vorhanden | bis zu 12h | Bis zu 50 Arbeitstage |
| Prio 4 | Leichte Störung | Technische Anfragen, Unterstützung, Feature Requests etc. | bis zu 24h | s. Beschreibung |
Für Prio 4 gilt: Wenn ein Security-Risiko-Ticket vor X-13 eingeht, hat die Wiederherstellung noch im laufenden Release zu erfolgen; für alle Tickets, die nach diesem Zeitpunkt eingehen, kann die Wiederherstellung im Folge-Release erfolgen.
5.3.3 Rahmenbedingungen Der AN erhält, sofern erforderlich, Zugriff auf Produktivsysteme der BA. Dies geschieht unter Berücksichtigung der geltenden Sicherheits-, Datenschutz- und Compliance-Vorgaben der BA. Der AN hat sicherzustellen, dass Störungen strukturiert, nachvollziehbar und prioritätsgerecht bearbeitet werden.
5.4 Testmanagement
5.4.1 Übersicht Zum Umfang der durch den AN nach den Standards der BA (zzt. ISTQB®) durchzuführenden Tests in Testumgebungen mit dazugehöriger Dokumentation und Qualitätsmanagement gehören:
• Review der Anforderungen der BA
Seite 32 von insgesamt 81 Seiten
[Seite 33]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Durchführung von: o Unit-Tests o Komponententests o Systemintegrationstests o Systemtests o Last- und Performancetests ▪ Nutzerprofiltests ▪ Importlasttests ▪ Stresstests ▪ RZ-Wechseltests Zudem begleitet der AN die BA bei der Durchführung folgender Tests:
• Penetrationstests (Pentests) • Abnahmetests
5.4.2 Abnahmekonzept
5.4.2.1 Zweck und Geltungsbereich Das Test-Abnahmekonzept legt verbindliche Regeln, Kriterien und Prozesse für die Planung, Durchführung und Abnahme von Tests fest, die durch den AN erbracht werden müssen. Es konkretisiert die Rechte und Pflichten von AN und BA. Es gilt für alle Testaktivitäten, die durch den AN durchgeführt werden. Die Tests unterliegen dem V-Modell (s. Kapitel 2.7). Die hierbei definierten Störungsklassen, Reaktionszeiten und Behebungsfristen (s. Kapitel 5.4.2.7) gelten ausschließlich für den Testbetrieb.
5.4.2.2 Testobjekt und Testumfang Das Testobjekt ist die E-AKTE der BA mit folgenden Komponenten: • E-AKTE-Server • E-AKTE-Client • Microservices • Datenhaltung mittels Datenbank • Weitere zugehörige Softwarekomponenten im E-AKTE-Umfeld Der Testumfang erstreckt sich insbesondere auf: • Digitale Verwaltung von Dokumenten und Akten • Digitalisierung und Übertragung von Schriftgut aus Scanzentren • Speicherung von Dokumenten aus anderen BA-Verfahren über Massendatenschnittstellen und Webservices • Digitalisierung und Übertragung von Schriftgut mit Hilfe des generischen Druckertreibers und aus Outlook • Routing von Dokumenten • Visualisierung und Bearbeitung über die E-AKTE-Oberfläche • Webschnittstellen und Massendatenschnittstellen • Übertragung von Dokumenten an andere Behörden und Rechtsanwälte • Bereitstellung der Dokumente zur Anbietung an das Bundesarchiv
Seite 33 von insgesamt 81 Seiten
[Seite 34]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Aussonderung von Akten und Aktensegmenten nach Erreichen der gesetzlich vorgeschriebenen Zeit • Übertragung der Dokumente an das E-Archiv nach Erreichen der vorgeschriebenen Zeit • Abruf der Dokumente aus dem E-Archiv • Prüfung der benutzerspezifischen Nutzung entsprechend dem technischen Berechtigungskonzept • Prüfung der digitalen barrierefreien Bereitstellung der E-AKTE nach BITV 2.0, EN 301 549 und WCAG • Beauftragung und Unterstützung der BITV-Begutachtung durch die BA und der hierfür beauftragten Dienstleister • Prüfung der Online-Hilfe • Durchführung von Geschäftsprozesstests mit den eingebundenen Prozesspartnern gemäß Drehbuch und CHG-Prozess • Umsetzung/Prüfung von Direkt-Demands
5.4.2.3 Zielsetzung Die primären Testziele sind wie folgt: • Sicherstellung der korrekten Funktionalität der E-AKTE gemäß den spezifizierten Anforderungen • Überprüfung der Einhaltung sämtlicher Anforderungen • Validierung der Interoperabilität mit definierten Schnittstellenpartnern. Die übergeordneten Qualitätskriterien sind im Kapitel 5.10.3.1 zu finden. Die Erfüllung der im Kapitel 5.4 beschriebenen KPIs ist Voraussetzung für die Abnahme (s. Kapitel 5.11), welche zentrale Voraussetzung für die Vergütung ist. Werden die KPIs nicht erfüllt, gelten die Regelungen zur Nachbesserung und erneuten Abnahme.
5.4.2.4 Verantwortlichkeiten Die BA verpflichtet sich zur Bereitstellung fachlicher Anforderungen und Spezifikationen in abgestimmter Form sowie der fachlichen Expertise für Klärungen und Abnahmetests seitens der BA. Die BA verpflichtet sich außerdem zur Bereitstellung der vereinbarten Testumgebungen inkl. Zugänge. Der AN verpflichtet sich zur Planung, Spezifikation und Durchführung der Tests gemäß ISTQB® und Testvorgaben der BA. Er erstellt und pflegt die Testdokumentation (Testfälle, Protokolle, Test-, Testdurchführungsfortschritts- und Fehlerberichte, Abschlussberichte) und führt regelmäßiges Reporting durch. Er wirkt aktiv an Reviews, Audits und Abstimmungen mit. Gemeinsam stimmen AN und BA Testpläne und Abnahmekriterien vor Testbeginn ab. Sie entscheiden auch gemeinsam über Änderungen mit Auswirkung auf Testumfang, -zeitplan und Abnahmekriterien im Rahmen des Change-Management-Prozesses.
5.4.2.5 Testprozess und Methodik • Grundlagen der Testmethodik Der AN verpflichtet sich, die Testaktivitäten nach anerkanntem, in der BA eingesetztem Industriestandard (zzt. ISTQB®) sowie den spezifischen Vorgaben der BA durchzuführen.
Seite 34 von insgesamt 81 Seiten
[Seite 35]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Dies beinhaltet u. a., dass alle Testfälle in BA-Schlüsselwortnotifikationen geschrieben sind. Für das Verfahren E-AKTE müssen zwingend funktionale und nicht-funktionale Tests durchgeführt werden, um eine umfassende Qualitätssicherung zu gewährleisten. Der AN ist zudem verpflichtet, wo technisch möglich und wirtschaftlich sinnvoll, Testautomatisierung einzusetzen. • Verbindlicher Phasenablauf Der Testprozess für das Verfahren E-AKTE ist in verbindliche Phasen unterteilt, die im Meilensteinplan (s. Kapitel 8.3) zu finden sind. Die im Testprozess verwendeten und erstellten Dokumente bilden die Grundlage für die Abnahme. Folgende Dokumente dienen dem AN als verbindliche Eingabe (Beistellleistung der BA): • Freigegebenes Test-, Lasttestkonzept und Anforderungsspezifikationen. • Spezifizierte Testdaten für die jeweilige Teststufe. Als vertraglich geschuldete Ausgabedokumente (Liefergegenstände) hat der AN folgende Artefakte zu übergeben: • Vollständig dokumentierte und versionierte Testfälle. • Nachvollziehbare Testprotokolle zu jeder Testausführung. • Fehlerberichte mit lückenloser Historie. • Einen umfassenden Testabschlussbericht, der den Erfüllungsgrad der Abnahmekriterien transparent ausweist. Traceability und Nachvollziehbarkeit Um die vertraglich vereinbarte Anforderungsabdeckung nachweisen zu können, verpflichtet sich der AN zur Führung einer »Traceability«-Matrix (Anforderungsabedeckungsmatrix, s. Kapitel 13) in einem von der BA bereitgestellten Testmanagement-Werkzeug. Diese muss jederzeit transparent darstellen, welche Anforderung durch welche Testfälle abgedeckt ist und welche Testergebnisse sowie Fehlerberichte hiermit verknüpft sind. Die lückenlose Dokumentation dieser Ein- und Ausgabedokumente je Testphase ist eine zwingende Voraussetzung für die Bewertung der Testabdeckung und die finale Abnahme durch die BA. Testumgebungen und vertragliche Verantwortlichkeiten Die Testdurchführung erfolgt auf dedizierten Testumgebungen, die durch die BA bereitgestellt werden. Der AN ist verpflichtet, diese Umgebungen zu übernehmen, die Instandhaltung im Zuge von Installationen sowie Deployment / Pflege (s. Kapitel 5.7) zu leisten und ausschließlich für vertraglich vereinbarte Zwecke zu nutzen. Störungen sind unverzüglich zu beheben. Um Verzögerungen innerhalb der BA (z. B. bei den Schnittstellenpartnern, s. Kapitel 2.10) abzusichern, sind für die Umgebungen verbindliche Verfügbarkeiten (Service Level Agreements) vom AN einzuhalten. Testdaten und strenge Datenschutzrichtlinien Für sämtliche Testdurchführungen muss der AN zwingend synthetische Testdaten (Test- Dienststellen) aus der Zentralen Testdatenbasis (ZOD) verwenden, da die Nutzung von Produktionsdaten streng untersagt ist. Eine definierte Ausnahme bildet lediglich die Verwendung von realen Dienststellen bei der Testdurchführung der Zahlverfahren in Verbindung mit ERP-FINANZEN unter Nutzung realer Dienststellen. Auch hier werden synthetische Testdaten verwendet. System-Mocks und Beistellleistungen Die Bereitstellung und Installation von notwendigen System-Mocks für die Testumgebungen (wie beispielsweise STEP, ALLEGRO oder ZERBERUS) erfolgt durch die BA. Kommt es hierbei zu Verzögerungen, muss der AN dies unverzüglich melden, um eine fristgerechte
Seite 35 von insgesamt 81 Seiten
[Seite 36]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Anpassung der eigenen Liefermeilensteine zu erwirken. Pflege und Instandhaltung obliegen dem AN. Zugriff und lückenlose Protokollierung Der AN erhält Zugang zu den Testsystemen über ein rollenbasiertes Zugriffskonzept mittels temporärer persönlicher Benutzerkennungen mit klar definierten Berechtigungen. Aus Revisionsgründen und zur Überprüfung der vertraglichen Compliance stimmt der AN zu, dass alle Zugriffe auf Testumgebungen und Testdaten lückenlos protokolliert werden. Bei personellen Wechseln der vom AN eingesetzten Dienstleister muss dieser die BA unverzüglich informieren, um verwaiste Zugriffsrechte und daraus resultierende Sicherheitsrisiken vertragskonform auszuschließen.
5.4.2.6 Testdokumentation Vertragliche Bedeutung der Dokumentation Die Erstellung und Pflege ist zwingende Voraussetzung für die Abnahme gem. Kapitel 5.11. Unvollständige, fehlerhafte oder nicht den Formvorgaben entsprechende Dokumentationen berechtigen die BA zur Verweigerung der Abnahme. Sämtliche Dokumente und Berichte sind in deutscher Sprache zu verfassen. Vorgaben zu Form und Werkzeugen Der AN ist verpflichtet, ausschließlich die von der BA vorgegebenen Werkzeuge und Templates zu nutzen, um eine nahtlose Integration in die bestehende IT-Landschaft zu gewährleisten. Testfälle und Testprotokolle müssen zwingend im Testmanagement-Tool verwaltet und Systemtests in Schlüsselwortnotation automatisiert werden. Für alle Testfälle, die in einer CI-Pipeline ausgeführt werden, muss die Protokollierung in der CI-Pipeline erfolgen. Für Fehlerberichte ist das Fehlermanagementtool der BA zu verwenden, wobei eine detaillierte Erfassung von Reproduktionsschritten, erwartetem Verhalten und Fehlerklassifizierung vertraglich geschuldet ist. Versionskontrolle und Nutzungsrechte Alle Testdokumente und Automatisierungsskripte unterliegen einer strikten Versionskontrolle, wobei wesentliche Änderungen über »Pull Requests« und »Code Reviews« abzustimmen sind. Mit der Erstellung der Testartefakte (Skripte, Konzepte, Fälle) räumt der AN der BA das ausschließliche, räumlich und zeitlich unbeschränkte Nutzungsrecht an diesen Ergebnissen ein. Um einen »Vendor-Lock-in« zu vermeiden, müssen alle Ergebnisse kontinuierlich an entsprechend zentralen Stellen innerhalb der BA abgelegt werden. Archivierung und Zugriffsrechte Die Vergabe von Zugriffsrechten erfolgt streng rollenbasiert, wobei dem AN nur die für die Vertragserfüllung zwingend notwendigen Rechte eingeräumt werden. Er hat sicherzustellen, dass nach Abschluss eines Testzyklus alle relevanten Dokumente revisionssicher aufbereitet sind, da die BA diese für mindestens fünf Jahre archivieren muss. Bei Vertragsende ist der Dienstleister verpflichtet, die Vollständigkeit der übergebenen Dokumentation schriftlich zu bestätigen und eventuelle lokale Kopien datenschutzkonform zu vernichten und dies der BA nachzuweisen.
5.4.2.7 Fehlermanagement im Test-Umfeld Prozess und vertragliche Pflichten Fehlererkennung, lückenlose Dokumentation, Analyse und Behebung gehören zu den Kernpflichten des ANs. Er muss jeden identifizierten und von der BA priorisierten Fehler im von der BA vorgegebenen Testmanagement-Tool nachvollziehbar dokumentieren und der BA eine entsprechende Rückmeldung zukommen lassen. Bei Meinungsverschiedenheiten über die Einstufung eines Fehlers obliegt die finale Entscheidung der BA. Nach jeder
Seite 36 von insgesamt 81 Seiten
[Seite 37]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Fehlerbehebung muss der AN eigenverantwortlich Regressionstests durchführen. Bei kritischen Fehlern ist ein vollständiger Testdurchlauf erforderlich, und die Verifikation von behobenen Fehlern der Klassen 1 und 2 unterliegt ggf. dem BA-internen Vier-Augen-Prinzip. Fehlerklassifizierung und Priorisierung Die vertragliche Abnahme und eventuellen Pönalen richten sich nach der Erfüllung der KPIs und nach der Schwere der identifizierten Fehler. Die Klassifizierung erfolgt in vier verbindliche Stufen. Zusätzlich erfolgt eine Priorisierung für den Release-Plan (s. Kapitel 8.3), die festlegt, ob ein Fehler zwingend vor der Abnahme (Hoch), idealerweise vor der Abnahme (Mittel) oder nach der Abnahme im Rahmen der regulären Gewährleistung (Niedrig) behoben werden muss. Fehler, die aufgrund der »JAVA Swing«-Bibliothek nicht behoben werden können, sind ggf. anders zu betrachten und gemeinsam mit der BA abzustimmen. Service Level Agreements im Test-Umfeld zur Fehlerbehebung Zur Sicherstellung der Systemstabilität gelten verbindliche Reaktions- und Wiederherstellungszeiten (»Service Level Agreements«) zwischen AN und BA. Werden diese Zeiten durch den AN schuldhaft überschritten, berechtigt dies die BA zur Geltendmachung von vertraglich vereinbarten Pönalen oder Rechnungsminderungen. Die Reaktionszeit beginnt mit der formalen Zuweisung des dokumentierten Fehlers an den AN. Die hier definierten Störungsklassen und Reaktions- sowie Wiederherstellungszeiten gelten ausschließlich für den Testbetrieb.
| Klasse | Bezeichnung | Beschreibung | Reaktionszeit (Test) | Wiederher- | ||
|---|---|---|---|---|---|---|
| stellungszeit | ||||||
| (Test) | ||||||
| 1 | Kritisch | System nicht nutzbar; kein Workaround möglich | < 2 Arbeitsstunden | < 1 Arbeitstag | ||
| 2 | Schwerwiegend | Wesentliche Funktion nicht nutzbar; kein akzeptabler Workaround | < 1 Arbeitstag | < 3 Arbeitstage | ||
| 3 | Mittelschwer | Funktion eingeschränkt; Workaround vorhanden | < 2 Arbeitstage | < 10 Arbeitstage | ||
| 4 | Leicht | Komforteinschränkung; keine fachliche Auswirkung | < 3 Arbeitstage | nächster Release-Zyklus |
Tabelle 7 Störungsklassen "Test"
Die oben genannten Reaktions- und Wiederherstellungszeiten können sich in der Geschäftsprozesstestphase und in der S-INT-Phase (Systemintegrationsphase) verkürzen. In diesen Fällen findet eine enge Abstimmung zwischen AN und BA statt. Metriken und Reporting • Vertragliche Auskunfts- und Berichtspflichten Der AN ist vertraglich verpflichtet, der BA jederzeit und unaufgefordert vollumfänglichen Einblick in den Testfortschritt und die Qualität des Testobjekts zu gewähren. Zur Sicherstellung der Transparenz und als Grundlage für formale Abnahmeentscheidungen sind verbindliche
Seite 37 von insgesamt 81 Seiten
[Seite 38]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Metriken regelmäßig zu erheben und in definierten Berichtsformaten zu übergeben. Das Reporting ist eine Hauptleistungspflicht; unvollständige, verspätete oder fehlerhafte Berichte berechtigen die BA zur Verweigerung der Abnahme. • Verbindliche Testmetriken Die folgenden Metriken sind vom AN in den vereinbarten Intervallen zu erheben, zu dokumentieren und als vertragsrelevante Nachweise aufzubereiten. Abweichungen von definierten Zielwerten sind im Reporting proaktiv zu begründen und mit entsprechenden Maßnahmen zur Gegensteuerung zu versehen.
| Metrik | Kategorie | Erhebungsintervall | Vertragsrelevantes Ziel |
|---|---|---|---|
| Anforderungsabdeckung | Testfortschritt | Wöchentlich | Nachvollziehbarkeit aller spezifizierten Anforderungen |
| Testfallausführungsstatus | Testfortschritt | Täglich | Anzahl der Testfälle je Status (bestanden, fehlgeschlagen) |
| Fehlerdichte und - verteilung | Testfortschritt | Wöchentlich | Max. 0,1 kritische Fehler pro 1000 Codezeilen |
| Automatisierungsgrad | Testfortschritt | zum Release (s. Kapitel 8.3) | Steigerung der automatisierten Regressionstests |
• Berichtsformate und Intervalle Die Kommunikation zwischen AN und BA erfolgt formalisiert über festgelegte Berichte, die vom AN weitestgehend automatisiert aus dem Testmanagement-Tool zu generieren sind, um manuelle Manipulationen auszuschließen. Der AN hat regelmäßig Statusberichte (Testfortschritt, offene Fehler) per E-Mail an die BA zu versenden. Zum Monatsmeeting (s. Kapitel 5.6.35.6.3) ist eine detaillierte Zusammenfassung inklusive Trendanalysen, identifizierter Risiken und Entscheidungspunkten zu liefern. Nach Abschluss eines Testzyklus ist ein fachlicher Testabschlussbericht zum BzA und zum Abschluss eines Releases ein Testabschlussbericht zur fachlich-technisch-normativen Freigabe als zwingende Vorbedingung für die formale Abnahme einzureichen. Die Häufigkeit von Berichten u. ä. kann sich (gemäß Meilensteinplan) ändern. • Eskalationsprozess bei Qualitätsabweichungen Um den Projekterfolg nicht zu gefährden, ist ein strikter Eskalationsprozess vertraglich vereinbart. Bei kritischen Abweichungen von den definierten Metriken (z. B. wenn die Anzahl gefundener Fehler der Klassen 1 und 2 den festgelegten Schwellenwert überschreitet) oder bei signifikantem Verzug im Testfortschritt ist der AN verpflichtet, unverzüglich die BA zu informieren und einen Maßnahmenplan vorzulegen. Bleibt die Gegensteuerung erfolglos, greifen die vertraglich vereinbarten Eskalationsstufen, die bis zur Einbeziehung des Steuerungskreises (s. Kapitel 5.6.5) und zur Geltendmachung von Schadensersatzansprüchen führen können. Abnahmekriterien und Abnahmeprozess • Vertragliche Bedeutung der Abnahmekriterien Die Erfüllung der definierten Abnahmekriterien ist zwingende Voraussetzung für die formale Abnahmeerklärung der BA.
Seite 38 von insgesamt 81 Seiten
[Seite 39]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Verbindliche Quantitative Kriterien Der AN muss die Erfüllung der in Kapitel 5.10.3.1 zu findenden KPIs in den Testabschlussberichten durch manipulationssichere Exporte aus den eingesetzten Test-Tools lückenlos nachweisen.
5.4.2.8 Abnahmekriterien Die folgenden Abnahmekriterien sind kumulativ zu erfüllen. Die Abnahme durch die BA kann nur erteilt werden, wenn alle Kriterien nachweislich erfüllt sind und keinerlei Engpässe vorliegen (s. Kapitel 5.4.2.10).
• Integrationsnachweis Nachweis der dokumentierten Integration und Ablauffähigkeit der Anwendung (insbesondere des E-AKTE-Clients) in allen BA-Testumgebungen im Zusammenspiel mit den angebundenen BA-Schnittstellenpartnern (s. Kapitel 2.10). Der Nachweis erfolgt durch ein formales Testprotokoll, das vom AN erstellt und der BA übergeben wird.
• Vollständige Testüberführung Vollständige Übergabe der bestehenden E-AKTE-Tests auf das umzusetzende E-AKTE- Front- und Backend. Alle bisherigen fachlichen und technischen Testszenarien sind weiterhin abzudecken. Darüber hinaus sind weitere Testfälle auf Basis der Akzeptanzkriterien zu prüfen und ggf. zu erstellen. Die Testfälle sind zusammen mit dem Inkrement zu liefern. Die BA behält sich Stichproben zur Testausführung vor. Teillieferungen werden ggf. durch das Abnahmeteam der BA geprüft.
• BA-Freigabe Freigabe der implementierten Module und Anforderungen durch die BA anhand der in den Anforderungen definierten Akzeptanzkriterien. Ohne vorliegende BA-Freigabe ist eine Abnahme nicht möglich.
• Barrierefreiheit (BITV 2.0) Der AN hat außerdem dafür zu sorgen, dass das Produkt die Barrierefreiheitsprüfung der BA besteht, um eine Freigabe zu erhalten. Dies bedeutet, dass die »BITV 2.0«-Abnahme (ggf. per Sondergenehmigung durch den BA-internen »UAC«-Prozess) erfolgreich ist, da diese ein entscheidendes Kriterium für die Freigabe der Version in die Produktionsumgebung ist. Nachweis der Barrierefreiheit gemäß BITV 2.0. Der Nachweis erfolgt ausschließlich durch den »UAC«-Bereich der BA. Eine interne Prüfung durch den AN allein ist nicht ausreichend. Um eine Abnahme (ggf. durch Sondergenehmigung) erfolgreich zu erhalten, dürfen nur max. 3 mittlere Befunde und max. 3 leichte Befunde vorhanden sein Leichter Befund (1): Ein leichter Befund ist ein Befund, der nur durch bestimmte Einstellungen der Bedienhilfen oder Betriebssystem umgangen werden kann, oder für Benutzer eine Störung oder Ablenkung darstellt. Entspricht Störungsklasse 4. Mittlerer Befund (2): Ein mittlerer Befund ist durch Bedienhilfen oder allgemeine Einstellungen im Betriebssystem nicht vermeidbar. Dennoch hat der Benutzer weiterhin die Möglichkeit, die Anwendung zu bedienen und alle Informationen zu erlangen, wenn auch nur schwer verständlich und schwer wahrnehmbar. Entspricht Störungsklasse 3. Schwerer Befund (3): Ein schwerer Befund führt dazu, dass die Anwendung an dieser Stelle nicht bedienbar ist oder relevante Informationen nicht zugänglich sind. Entspricht Störungsklasse 1 oder 2 und ist abnahmeverhindernd.
• Sicherheit / Pentest
Seite 39 von insgesamt 81 Seiten
[Seite 40]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Nachweis der Einhaltung der BA-SIA-Methodiken während der gesamten Entwicklungsphase sowie Aktualisierung des verfahrensspezifischen Sicherheitskonzepts. Einmal im Jahr ist vor Go-Live (Produktionseinführung) ein Pentest auf einer BA-Testumgebung durchzuführen. Sämtliche im Pentest identifizierten Befunde müssen vor dem Go-Live vollständig behoben sein. Die BA unterstützt hierbei den AN durch die Beauftragung der BA-internen Abteilungen. Entwicklungsbegleitend sind die BA-Sicherheitsstandards kontinuierlich zu prüfen und ggf. anzupassen. Fehler, die aufgrund von Bibliotheken nicht behoben werden können oder die Behebung weitreichende Auswirkungen auf das Gesamtsystem haben, sind ggf. anders zu betrachten und gemeinsam mit der BA abzustimmen.
• Fachliche Korrektheit inkl. Microservices Fachlich korrekter Ablauf (z. B. gemäß den Akzeptanzkriterien aus den dazugehörigen Anforderungen) für alle implementierten Funktionen der E-AKTE-Client-Anwendung einschließlich E-AKTE-Backend sowie sämtlicher Microservices im Container.
• CI/CD-Pipeline Fortführung bzw. Erstellung und produktive Einführung von automatisierten Tests in einer CI/CD-Pipeline für die E-AKTE-Microservices in allen BA-Umgebungen. Alle Testreports sind der BA bereitzustellen.
• Fehlerfreiheit in Testumgebungen (Klassen 1 und 2) Fehlerfreie Bereitstellung des E-AKTE-Verfahrens der Implementierung der beauftragten Änderungen (keine offenen Fehler der Klassen 1 und 2) in den BA-Testumgebungen zu den laut Releaseplan definierten Terminen.
5.4.2.9 Testwerkzeuge Aktuell werden folgende Werkzeuge für die Testdurchführung und Qualitätssicherung eingesetzt. Die BA kann Werkzeuge ggf. wechseln. Eine Abweichung vom AN bedarf der ausdrücklichen schriftlichen Zustimmung der BA.
| Zweck | Werkzeug / Plattform | ||||
|---|---|---|---|---|---|
| Unit-Test & Automatisierung | Eclipse, JUnit, Silk4J | ||||
| Testframework (Container) | Tamara / Robot Framework (schlüsselwortbasiert) | ||||
| Testmanagement | AQUA | ||||
| Code-Analyse | SonarQube (BA-Ruleset maßgeblich) | ||||
| KPI-Messung / Transparenz | Seerene-Plattform | ||||
| Source Control / Messbasis | GitHub Enterprise bzw. Bitbucket | ||||
| Anforderungs-/Fehlermanagement | Atlassian Jira (inkl. Commit-Zuordnung) | ||||
| Anforderungsgrundlage | Innovator |
5.4.2.10 Risikomanagement • Proaktive Risikoidentifikation und Hinweispflicht Der AN unterliegt einer vertraglichen Warn- und Hinweispflicht. Er ist verpflichtet, fortlaufend potenzielle funktionale, nicht-funktionale und projektspezifische Risiken zu identifizieren. Diese Risiken müssen anhand ihrer Eintrittswahrscheinlichkeit und Schadenshöhe
Seite 40 von insgesamt 81 Seiten
[Seite 41]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
kategorisiert und dokumentiert werden. Versäumt der AN die rechtzeitige Meldung absehbarer Risiken (z.B. Ressourcenengpässe, Performance-Probleme, Bedarf an Hardware), haftet er vollumfänglich für daraus resultierende Verzögerungen und Schäden. • Risikominimierungsmaßnahmen und Kostentragung Der AN hat auf eigene Kosten geeignete Risikominimierungsmaßnahmen für Risiken umzusetzen, die in seiner Einflusssphäre liegen. Die BA behält sich vor, für kritische Meilensteine verbindliche Go/No-Go-Kriterien festzulegen, die an den Status der gemeldeten Risiken geknüpft sind. • Risikokommunikation und Eskalation Der Status identifizierter Risiken ist vom AN transparent offenzulegen. Für neu auftretende oder sich akut verschärfende Risiken mit potenziellen Auswirkungen auf die Abnahme ist ein sofortiger Eskalationsprozess an die BA auszulösen.
5.4.2.11 Qualitätssicherung und Audits • Interne Qualitätssicherung des ANs Vor der Übergabe von Leistungen zur Abnahme an die BA ist der AN verpflichtet, eine interne Qualitätssicherung durchzuführen. Die BA akzeptiert keine fehlerhaften und nicht lauffähigen Liefergegenstände. • Auditrecht der BA Zur Sicherstellung der vertraglichen Compliance räumt der AN der BA (sowie von ihr beauftragten unabhängigen Dritten) das Recht ein, regelmäßige Audits des Testprozesses durchzuführen. Diese Audits dienen der Überprüfung der Einhaltung von Teststandards, der Bewertung der Testabdeckung und der Kontrolle der Effektivität der Testautomatisierung. Der AN ist zur vollständigen und unentgeltlichen Mitwirkung an diesen Audits verpflichtet. (s. Kapitel 5.5)
5.5 Mitwirkung an Audits
Der AN räumt der BA gemäß Kapitel 2.8.5 ein uneingeschränktes Auditrecht in Bezug auf den Leistungsgegenstand ein und unterstützt aktiv die Durchführung jährlicher, in der Regel remote stattfindender Security-Reifegradaudits. Hierzu gehört insbesondere die jährliche Auditvorbereitung und -begleitung gemäß den Anforderungen der ISO 27001 auf Basis IT- Grundschutz, des IT-Grundschutz-Kompendiums in aktueller Fassung sowie der einschlägigen Richtlinien zur Informationssicherheit der BA.
| IT-Grundschutz lt. BSI | https://www.bsi.bund.de/DE/Themen/Unternehmen-und- Organisationen/Standards-und-Zertifizierung/IT- Grundschutz/it-grundschutz_node.html |
|---|---|
| KRITIS-Audit | https://www.bsi.bund.de/DE/Themen/Regulierte- Wirtschaft/Kritische- Infrastrukturen/OH_Nachweise/orientierungshilfe_node.html |
Tabelle 8 Links zu Zertifizierungen
KRITIS-Betreiber sind verpflichtet, ihre informationstechnischen Systeme abzusichern und dies regelmäßig gegenüber dem BSI nachzuweisen. Der AN stellt sicher, dass alle für die Auditierung erforderlichen Unterlagen, Nachweise und Dokumentationen vollständig, aktuell und prüffähig vorbereitet und bereitgestellt werden. Darüber hinaus ist er verpflichtet, identifizierte Findings unverzüglich zu analysieren, geeignete Maßnahmen abzuleiten, deren Umsetzung zu dokumentieren und notwendige Anpassungen
Seite 41 von insgesamt 81 Seiten
[Seite 42]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
an Prozessen, Konzepten und Systemarchitektur unter Berücksichtigung der KRITIS- Anforderungen vorzunehmen. Die Auditvorbereitung und -unterstützung umfasst ebenfalls die Mitwirkung an externen Prüfungen und Zertifizierungen, insbesondere im Kontext von BSI-Audits sowie relevanten Zertifizierungen (z. B. PK-DML), mit dem Ziel, das bestehende Sicherheitsniveau der BA dauerhaft zu gewährleisten und kontinuierlich zu verbessern.
5.6 Abstimmungsformate
Hinsichtlich eines kontinuierlichen Informationsaustausches haben die Parteien (BA und AN) mit Vertragsbeginn, spätestens jedoch ab Servicebeginn, die verantwortlichen Personen in nachfolgend aufgeführten Abstimmungsformate zu benennen und zu dokumentieren. Änderungen sind dem jeweiligen Vertragspartner, mit ausreichend zeitlichem Vorlauf, vor Inkrafttreten mitzuteilen. Die unten aufgeführten Abstimmungsformate sind Mindestanforderungen. Den Parteien steht es frei, in gegenseitiger Abstimmung weitere Formate (z. B. ein Transitionsstatusmeeting, s. Kapitel 8.2) einzurichten. Folgende Meeting-Formate sind geplant:
• Anlassbezogenes Fehlermeeting, s. Kapitel 5.6.1 • Zweiwöchentliches Review-Meeting, s. Kapitel 5.6.2 • Monatsmeeting, s. Kapitel 5.6.3 • Release-Meeting, s. Kapitel 5.6.4 • Steuerungskreis, s. Kapitel 5.6.5
5.6.1 Anlassbezogenes Fehlermeeting
| Häufigkeit | Bei Bedarf, maximal 25x jährlich |
|---|---|
| Location | Virtuell (Skype/Teams) |
| Beschreibung der Schwerpunkte | Aktuelle, von der BA priorisierte Fehler in den Vorumgebungen und Produktion Verbindliche Vorstellung von Lösungsvorschlägen inkl. der dazugehörigen Zeitpläne durch den AN Gemeinsame Klärung der Installationspakete, inkl. dazugehöriger Umgebung und Installationszeitpunkte |
| Vorbereitung | Vorbereitung (inkl. Fehlerbericht und Versenden der Einladung) durch die BA. |
| Teilnehmerkreis | Im Regelfall mindestens zentrale Ansprechperson des AN sowie der Fehlermanager der BA. Vollumfängliche Vertretungsregel ist zu gewährleisten. |
| Dokumentation | Kein Protokoll, aber Eintragung in Jira-Dokument durch AN. |
5.6.2 Zweiwöchentliches Review-Meeting
| Häufigkeit | 1 x jede 2. Woche |
|---|---|
| Location | Virtuell (Skype/Teams) |
Seite 42 von insgesamt 81 Seiten
[Seite 43]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Beschreibung der Schwerpunkte | Statusbericht: Storys und Änderungen sowie Grundfunktionalität der E-AKTE Verbindliche Vorstellung von Arbeitsergebnissen (Inkremente) durch den AN |
|---|---|
| Vorbereitung | Vorbereitung (inkl. Versenden der Einladung) durch den AN. |
| Teilnehmerkreis | Im Regelfall mindestens zentrale Ansprechperson und Verantwortlicher für die Änderungen vonseiten des AN sowie vonseiten der BA: Qualitätsmanager, Applikationsverantwortlicher, fachlicher und technischer Verantwortlicher sowie T-SV und Vertreter, der die Abnahme aus Sicht der BA durchführen kann. Vollumfängliche Vertretungsregel ist zu gewährleisten. |
| Dokumentation | Kein Protokoll, aber Erstellung einer Agenda des jeweiligen Meetings durch AN sowie ausführlicher Statusbericht |
5.6.3 Monatsmeeting
| Häufigkeit | zum achten Arbeitstag eines Kalendermonats |
|---|---|
| Location | Vor Ort |
| Beschreibung der Schwerpunkte | zentrales Steuerungsboard für taktische Belange im Leistungsumfeld monatliche Überprüfung und Feststellung der erbrachten Leistung anhand der definierten Kennzahlen (s. Kapitel 5.10) inkl. fachlicher Abnahme der Werkleistung gemäß Kapitel 5 und 8.2 Planung der anstehenden Leistungen für den Folgemonat bzw. die weiteren Folgemonate sowie Umpriorisierungen (s. Kapitel 8.5.3) Umgang und Konsequenzen mit Service- Einschränkungen bzw. -Störungen Klärung vertraglicher Nachfragen Klärung allgemeiner Punkte zur Leistungserbringung Abstimmung (inkl. Priorisierung) zu den ITIL-Prozessen |
| Vorbereitung | Vorbereitung (inkl. Versenden der Einladung) durch den AN, BA stellt dem AN die Kennzahlen (s. Kapitel 5.10) des zu beurteilenden Vormonats zur Verfügung. |
| Teilnehmerkreis | Im Regelfall mindestens zentrale Ansprechperson und vertraglicher Projektleiter des AN sowie vonseiten der BA: Fachlicher und technischer Verantwortlicher sowie vertragliche Ansprechperson Vollumfängliche Vertretungsregel ist zu gewährleisten. |
Seite 43 von insgesamt 81 Seiten
[Seite 44]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Dokumentation Ergebnisprotokoll vom AN erstellt und nachträglich (max. 5 Arbeitstage nach Meeting) an einen festgelegten Verteiler per E-Mail versendet.
5.6.4 Release-Meeting
| Häufigkeit | Voraussichtlich 3x pro Jahr, im Zeitraum von zwei Wochen vor Deployment eines Releases |
|---|---|
| Location | vor Ort |
| Beschreibung der Schwerpunkte | Vor dem Release erfolgt eine Präsentation der durchgeführten Änderungen/Weiterentwicklungen für den Release, inkl. Antworten auf Fragen wie „Worauf muss der Betrieb achten?“ bzw. Vermittlung von Hintergrundwissen für das Tagesgeschäft bzw. die Ticketbearbeitung. Verbindliche Vorstellung von Änderungen im Release durch den AN |
| Vorbereitung | Vorbereitung (inkl. Versenden der Einladung) durch den AN. |
| Teilnehmerkreis | Im Regelfall mindestens zentrale Ansprechperson und Verantwortlicher für die Änderungen vonseiten des AN sowie vonseiten der BA: Betriebsverantwortlicher und Applikationsverantwortlicher. Vollumfängliche Vertretungsregel ist zu gewährleisten. |
| Dokumentation | Kein Protokoll, aber schriftliche Zusammenfassung der Änderungen und Handlungsempfehlungen durch den AN. |
5.6.5 Steuerungskreis Der Steuerungskreis tagt bei Bedarf. Er stellt die höchste verantwortliche Ebene des Managed Service zwischen den Parteien dar. Die Angehörigen sind von den jeweiligen Parteien mit einem vollumfänglichen Mandat (also die Befugnis zur Vertretung und Abgabe verbindlicher Erklärungen) auszustatten. Jede Partei bestimmt einen mandatierten Vertreter im Steuerungskreis. Den Vorsitz führt der Vertreter der BA. Weitere Teilnehmer sind zu Vertragsbeginn von den Parteien abzustimmen. Der Steuerungskreis umfasst die nachfolgenden Verantwortlichkeiten:
• Ausrichtung der beauftragten Leistungserbringung des AN den Zielen und Erfordernissen der BA bzw. der Leistungsbeziehung • Nutzenbewertung der Services sowie Dokumentation der Zufriedenheit mit den Services • Finale Entscheidungsebene für Eskalationen der vorgelagerten Ebene.
Entscheidungen und Protokollierung:
• Der Steuerungskreis wird in Form eines Ergebnisprotokolls durch die einladende Stelle protokolliert.
Seite 44 von insgesamt 81 Seiten
[Seite 45]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Die einladende Stelle verteilt den Protokollentwurf zeitnah, spätestens jedoch 5 Arbeitstage nach dem Tag der Tagung des Steuerungskreises an alle eingeladenen Teilnehmer. • Aufgaben und Entscheidungen werden als solche kenntlich gemacht. • Das Protokoll wird anschließend in seiner finalen Fassung an alle eingeladenen Teilnehmer verteilt.
5.7 Deployments / Pflege
Der AN hat sämtliche Leistungen im Zusammenhang mit Deployment, Pflege, Administration und Betriebsvorbereitung der Anwendungssysteme vollständig und fristgerecht (s. Kapitel 8.3) gemäß dem aktuellen Stand der Technik sowie anerkannten Industriestandards zu erbringen. Die Pflege- und Administrationsleistungen fallen fortlaufend während des gesamten Leistungszeitraums an. Die Leistungen im Zusammenhang mit Deployment orientieren sich an den mehrmals im Jahr stattfindenden Releases und deren Planungen (s. Kapitel 8.3).
5.7.1 Datenpflege Der AN hat die kontinuierliche Pflege und Bereinigung von Testdaten und Umgebungen (z. B. Postkörbe) sicherzustellen. Gleichzeitig obliegt ihm die Pflege und Konfiguration der Testkennungen auf den Vorumgebungen.
5.7.2 System- und Service-Betreuung (Administration) Der AN hat die kontinuierliche Betreuung, Pflege und Administration der Systemlandschaft sicherzustellen, um zu gewährleisten, dass die Systeme jederzeit in einem konsistenten und funktionsfähigen Zustand betrieben werden können. Dies umfasst die Umgebungen SDST, EDST und LTU und folgende Leistungen:
• Konfigurationsanpassungen umsetzen • Betriebsfähigkeit und Verfügbarkeit der Systeme sicherstellen • Störungen eigenständig analysieren und beheben • die übergebenen Microservices pflegen und weiterentwickeln • die Interoperabilität der Systemkomponenten sicherstellen • den aktuellen Code-Stand pflegen und versionsgeführt vorhalten • Vorumgebungen der Verfahren starten, beenden, bereinigen und wiederherstellen • Schemapflege, Datenmigration und Wiederholungsläufe im IT-Verfahren E-AKTE durchführen
5.7.3 Build- und Release-Management Der AN hat sämtliche Build- und Release-Prozesse, die nicht auf der Produktivumgebung stattfinden, zu planen, zu steuern und durchzuführen. Dies umfasst insbesondere folgende Leistungen:
• Build-Prozesse planen und koordinieren • reproduzierbare Builds erstellen und verwalten • Build- und Deployment-Skripte erstellen, pflegen und weiterentwickeln • Release-Notes vollständig und nachvollziehbar erstellen • Deployments in SDST, EDST und LTU eigenständig vorbereiten und durchführen • Deployments in IDST, Produktions- und Schulungsumgebungen unterstützen • Softwarepakete zur Verteilung bereitstellen (SCCM oder gleichwertig) ➢ für den Client ➢ für den generischen Druckertreiber
Seite 45 von insgesamt 81 Seiten
[Seite 46]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
➢ für das Outlook-Plugin • sämtliche Deployment-Artefakte (sowie eine Liste der sonstigen Anpassungen, wie z. B. DB-Skripte) vollständig, geprüft und freigegeben übergeben
Der AN hat sicherzustellen, dass alle abhängigen Microservices synchron zu den festgelegten Release-Terminen bereitgestellt werden. Der AN hat die Durchführung von Generalproben auf vorgelagerten Umgebungen technisch zu unterstützen. Für geplante Deployments hat der AN qualifizierte Ressourcen bereitzustellen. Dies umfasst bei Bedarf Rufbereitschaft sowie Vor-Ort-Unterstützung während der Deployment-Zeiträume. Der AN hat an der Abnahme der Deployments mitzuwirken und den geordneten Verantwortungsübergang an den Betrieb sicherzustellen.
5.7.4 Datenbank-Management Der AN hat die kontinuierliche Pflege und Optimierung der Datenbanksysteme durchzuführen, dies beinhaltet insbesondere:
• Datenbankstrukturen anpassen und weiterentwickeln • regelmäßige Reorganisationsmaßnahmen durchführen • Performanceparameter analysieren und optimieren • Datenkonsistenz und Systemstabilität sicherstellen • die Übergabe von Datenbankänderungen an den Betrieb vorbereiten
Alle Maßnahmen sind unter Beachtung der FileNet-Anforderungen im Verbund mit dem System der E-AKTE sowie unter Minimierung von Betriebsunterbrechungen sowie unter Einsatz geeigneter Sicherungs- und Wiederherstellungsverfahren durchzuführen.
5.7.5 Sicherheit und Infrastruktur-Hygiene Der AN hat die Sicherheit und Aktualität der Systemlandschaft sicherzustellen. Dies beinhaltet insbesondere folgende Leistungen:
• Base-Image-Updates regelmäßig durchführen • kritisch Fehlern oder Sicherheitslücken durch Hotfixes unverzüglich beheben • Werkzeuge zur Code- und Artefaktprüfung einbinden und betreiben • eingesetzte Bibliotheken und Komponenten kontinuierlich auf Aktualität und Sicherheitslücken analysieren • Risiken bewerten und geeignete Maßnahmen (insbesondere Updates und Upgrades) umsetzen • Umgebungen für Penetrationstests bereitstellen und betreiben • die Durchführung von Sicherheitstests technisch unterstützen
Sicherheitsrelevante Maßnahmen sind mit der BA abzustimmen und nachvollziehbar zu dokumentieren.
5.7.5.1 vSiko-Freigabe Zusätzlich hat der AN die BA bei der Freigabe des vSikos (einmal jährlich bzw. bei Bedarf unterjährig) zu unterstützen. Dies umfasst:
• Bedrohungsanalysen (AMSEL-Tool) • Risikoanalysen bezüglich der im vSiko erfassten Anwendungen (Zielobjekte) • IT-Grundschutz-Check
Seite 46 von insgesamt 81 Seiten
[Seite 47]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• NTPL
5.7.6 Software-Anpassung und Konfiguration Der AN hat erforderliche Softwareanpassungen und Konfigurationsarbeiten gemäß den Vorgaben der BA umzusetzen. Dies beinhaltet u. a. die Durchführung von Installation und Konfiguration von Software-Releases und Patches von durch die BA bereitgestellter und in der E-AKTE implementierter Kauf-Software, aber auch die Installation, Änderung, Konfiguration und Unterstützung aller Software, die für den Verfahrensbetrieb der E-AKTE notwendig ist. Falls die Software sowohl aus einer Server-Komponente als auch aus einer Client- Komponente besteht, so wird durch den AN beides unterstützt. Dies beinhaltet insbesondere folgende Leistungen:
• Softwarekomponenten (z. B. Datengeneratoren einschließlich V-Post) anpassen • EUE-Daten konfigurieren und pflegen • fachliche und technische Anforderungen in den Systemen umsetzen • Servlets pflegen und weiterentwickeln
Alle Änderungen sind versionsgeführt, kontrolliert und nachvollziehbar durchzuführen.
5.7.7 Dokumentation und Nachvollziehbarkeit Der AN hat sämtliche Tätigkeiten vollständig und nachvollziehbar zu dokumentieren (s. Kapitel 5.8). Die Dokumentation muss so beschaffen sein, dass die BA jederzeit in der Lage ist, Betrieb, Wartung und Weiterentwicklung eigenständig durchzuführen.
5.8 Dokumentation und Ablage
Der AN erstellt, pflegt und aktualisiert sämtliche im Rahmen der Leistungserbringung erforderlichen Dokumentationen in mit der BA abgestimmten Formaten. Dies umfasst u. a. die Erstellung und Pflege von Skripten, z. B. zur Automatisierung von Softwareinstallation und Verfahrensmonitoring. Hierzu gehören insbesondere:
• Eindeutige Dokumentation von Änderungen im Quellcode der E-AKTE • Protokollierung von Änderungen an Systemen, Konfigurationen und Datenbanken • Darstellung betriebsrelevanter Entscheidungen • Kundeninformationen • Schulungsunterlagen • Versionsinformationen • Online-Hilfe • Installationsanleitungen • Betriebshandbücher und technische Dokumentationen • How-to-Dokumentationen, FAQ und Fehlerbeschreibungen • Dokumentation von Deployments und Releases • Dokumentation von Entwicklungs- und Infrastrukturkomponenten • Dokumentation von Änderungen im Testframework TAMARA • Dokumentation sicherheitsrelevanter Anforderungen und Vorgaben sowie umgesetzter und nicht umgesetzter Maßnahmen • Konzepte, u. a. … ➢ Technisches Berechtigungskonzept ➢ Protokollierungs- und Monitoring-Konzept
Sämtliche erstellten Dokumentationen, Quellcodes, Skripte, Routinen und Testergebnisse sind fachgerecht zu kommentieren und mit den zur Nachvollziehbarkeit und Weiterbearbeitung
Seite 47 von insgesamt 81 Seiten
[Seite 48]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
erforderlichen Informationen zu versehen und zu versionieren. Hierzu zählen insbesondere Beschreibungen relevanter Systemparameter, Konfigurationen, Schnittstellen, Testdaten, Testbasis, Testkennungen und Testdokumente. Die Ergebnisse sind grundsätzlich in Form strukturierter Dokumente (z. B. »Word«-Dokumente bzw. »Confluence«-Dokumente) zu dokumentieren. Abweichende Formate können durch die BA vorgegeben werden. Ergänzend sind Quellcodes und Testskripte angemessen zu dokumentieren und zu versionieren. Testergebnisse sind revisionssicher in den von der BA vorgegebenen Testmanagementwerkzeugen zu hinterlegen. Wenn die Tests nicht in einem Testmanagementwerkzeug gepflegt werden können, hat eine Dokumentation der Ergebnisse in »Word« oder »Confluence« zu erfolgen. Lösungswege (s. Kapitel 5.2.6) sind zu dokumentieren. Alle Anforderungen sind kontinuierlich im »Innovator« zu modellieren. Jedes Release wird im »Innovator« als Stand des Releases versioniert. Bei der Umsetzung werden alle Tasks und User-Stories in »Jira« dokumentiert. Der AN hat sämtliche geänderten oder neu erstellten Arbeitsergebnisse spätestens zum Ende jedes Arbeitstages (s. Kapitel 13) gemäß den fachlichen Vorgaben der BA abzulegen. Die Ablage erfolgt in den durch die BA bereitgestellten Systemen, insbesondere:
• Repository bzw. Versionsverwaltungssystem • zentrale Dateisystemablage • Atlassian Jira
Die BA prüft die Arbeitsergebnisse im Rahmen ihrer Qualitätssicherungsprozesse formal und fachlich. Festgestellte Mängel oder Beanstandungen sind durch den AN innerhalb der von der BA vorgegebenen Frist, spätestens jedoch bis zum nächsten Abstimmungstermin, zu beheben. Die Dokumentation ist so auszugestalten, dass die BA eine eigenständige Nachvollziehbarkeit, Wartung und Weiterentwicklung der erstellten Ergebnisse sicherstellen kann.
5.9 Nutzung Hard- und Softwareinfrastruktur der BA
Der AN muss sicherstellen, dass es hinsichtlich der jeweils seitens der AN angebotenen Leistungen keine Einschränkungen bzgl. der in der BA zu nutzenden Hard- und Softwareinfrastruktur gibt. Folgende Voraussetzungen sind in der BA aktuell gegeben:
• Standard Arbeitsplatz, basierend auf Windows 11 • Architekturübersicht (s. Kapitel 2.3.6) und • Eingesetzte Werkzeuge und Standards/Frameworks (s. Kapitel 2.9).
Die Leistungen sind auf Basis der von der BA bereitgestellten Umgebungen zu erbringen, alle Arbeitsergebnisse sind in den aktuell in der BA eingesetzten Versionen der BA zur Verfügung zu stellen.
5.10 Vereinbarte Kennzahlen zur Leistungserbringung
5.10.1 Qualitätssicherung der Softwareentwicklung Die Leistungsfähigkeit der E-AKTE wird über vorab definierte Kennzahlen gemessen. Dieses Kapitel regelt verbindliche Anforderungen an die Prozess- und Codequalität sämtlicher durch den AN im Rahmen des Abnahme-Zyklus (s. Kapitel 13) erbrachten Softwareentwicklungsleistungen an der E-AKTE.
Seite 48 von insgesamt 81 Seiten
[Seite 49]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.10.2 Leistungsübergabepunkte Die maßgeblichen Leistungsübergabepunkte sind wie folgt:
• Erfolgreicher Abschluss der Tests gemäß Kapitel 5.4 • Teilnahme an den Abstimmungsformaten gemäß Kapitel 5.6 • Nachweis der KPIs gemäß Kapitel 5.10.3.1
Die Verantwortung des AN endet allerdings nicht mit Übergabe der Software an diesem Punkt.
Die Leistungsübergabepunkte sind essenziell für die SLAs (s. Kapitel 5.10.3). Die vereinbarten Leistungskennzahlen wie Verfügbarkeit, Latenz oder Reaktionszeiten, etc. werden an diesen Punkten gemessen.
Zweck: Die Leistungsübergabepunkte dienen dazu, schnell festzustellen, ob das Problem primär im Verantwortungsbereich des AN oder der BA liegt.
5.10.3 SLA zwischen AN und BA Für die Verfügbarkeit der E-AKTE gelten folgende Verfügbarkeiten zwischen AN und BA. Die Werte gelten als Mindestanforderungen. Der AN hat durch seine Leistungen die Einhaltung der vereinbarten Qualitätslevels der BA für die E-AKTE sicherzustellen, soweit die Störungsursachen in seiner Verantwortung liegen:
| Umgebung | Dialogzeiten | Maximale Ausfallzeit pro | ||
|---|---|---|---|---|
| Kalendermonat | ||||
| Produktion / DST | Montag bis Freitag von 6:30 – 20:00 Uhr, ausgenommen sind bundeseinheitliche Feiertage (Verfügbarkeit der IT-Verfahren) | 120 min |
Tabelle 9: SLA E-AKTE
Die folgenden Kennzahlen sind durch den AN einzuhalten. Die Daten werden dem AN offengelegt. Ihm steht es frei, eigene Auswertungen im ESM durchzuführen. Die Auswahl der Kennzahlen orientiert sich an den KPI der entsprechenden Prozesse, deren allgemeine Prozessvorgaben weiter gelten. Zusätzlich werden mehrere Qualitätskriterien als weitere KPI definiert.
Die zu bearbeitenden Incidents (INC) werden in verschiedene Prioritätsstufen eingeteilt:
| Klassifizierung | Dringlichkeit | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Hoch | Mittel | Niedrig | ||||||||
| Auswirkung | Hoch | 1(-Major) | 2 | 3 | ||||||
| Mittel | 2 | 3 | 4 | |||||||
| Niedrig | 3 | 4 | 4 |
Tabelle 10: Klassifizierung der Incidents (Prioritätsstufen)
5.10.3.1 KPI Die Leistungserbringung des AN wird anhand definierter »Key Performance Indicators« (KPIs) gemessen und bewertet. Die KPIs dienen der transparenten, objektiven und kontinuierlichen Überwachung der vereinbarten Leistungen sowie der Einhaltung der »Service Level Agreements« (SLA) zwischen AN und BA.
Seite 49 von insgesamt 81 Seiten
[Seite 50]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Der AN ist verpflichtet, die zur KPI-Erhebung notwendigen Daten vollständig, korrekt und fristgerecht bereitzustellen. Die Auswertung erfolgt in regelmäßigen Intervallen und wird der BA zur Verfügung gestellt.
Die KPIs werden von der BA festgelegt und können bei Bedarf angepasst werden, sofern sich Anforderungen, Rahmenbedingungen oder regulatorische Vorgaben ändern.
Zur einheitlichen Bewertung der KPI-Ergebnisse wird eine Ampellogik verwendet:
• Grün: Der KPI wird vollständig erfüllt oder übertroffen.
Die Leistungserbringung entspricht den vertraglichen Anforderungen. Es besteht kein Handlungsbedarf.
• Gelb: Der KPI wird teilweise erfüllt oder befindet sich in einem tolerierbaren Grenzbereich.
Es besteht ein erhöhter Beobachtungs- und ggf. Steuerungsbedarf. Der Auftragnehmer analysiert die Ursachen und leitet geeignete Maßnahmen zur Stabilisierung ein.
• Rot: Der KPI wird nicht erfüllt.
Es liegt eine Abweichung von den vertraglichen Anforderungen vor. Der Auftragnehmer ist verpflichtet, unverzüglich eine Ursachenanalyse durchzuführen, geeignete Gegenmaßnahmen einzuleiten und deren Umsetzung sowie Wirksamkeit gegenüber der Auftraggeberin nachzuweisen. Je nach Schweregrad können vertraglich definierte Rechtsfolgen zur Anwendung kommen.
Bei wiederholten oder schwerwiegenden Abweichungen (Status »Gelb« oder »Rot«) sind durch den AN geeignete Maßnahmen zur nachhaltigen Verbesserung der Leistungserbringung zu definieren und umzusetzen. Die BA behält sich vor, bei anhaltender Nichterfüllung weitere vertraglich geregelte Eskalations- und Sanktionsmechanismen anzuwenden.
In den Kapiteln 5.11.2.2 (für Freigabe) und 5.11.3.3 (für Abnahme) ist eine Übersicht der durch den AN einzuhaltenden Kennzahlen und deren Schwellenwerte zu finden.
Bezugspunkt des Schwellwerts ist ausschließlich der jeweilige Messpunkt, nicht die Messreihe bzw. Gesamtmessung.
5.10.3.2 Prozessqualität (Nachvollziehbarkeit von Änderungen) Sämtliche durch den AN vorgenommenen Codeänderungen (insbesondere »Git-Commits«) müssen eindeutig einem fachlichen Arbeitspaket (zzt. »Jira Issue«) zugeordnet sein. Die Zuordnung ist erfüllt, wenn mindestens eine der folgenden Bedingungen vorliegt: • Referenz des »Jira Issues« in der »Commit«-Message, oder • Referenz des »Jira Issues« in der »Merge-Commit«-Message, oder • Referenz des »Jira Issues« im Namen des verwendeten »Git«-Branches.
Codeänderungen ohne entsprechende Zuordnung gelten als nicht vertragskonform. Die Einhaltung dieser Anforderungen wird automatisiert mittels der »Seerene«-Plattform überprüft. Maßgebliche Kennzahl ist der KPI »Below-the-Radar Coding Effort«. Der AN stellt sicher, dass dieser KPI den zwischen den Parteien vereinbarten Schwellenwert nicht überschreitet. Sofern kein spezifischer Schwellenwert vereinbart wurde, gilt ein Wert von 0 % als Zielvorgabe.
Seite 50 von insgesamt 81 Seiten
[Seite 51]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.10.3.3 Fachliche Abnahme und Rechtsfolgen Die definierten Kriterien stellen verbindliche Freigabe- bzw. Abnahmekriterien (s. Kapitel 5.11.2.2 und Kapitel 5.11.3.3) dar.
Die Messung erfolgt jeweils zum Beginn und zum Ende eines Abnahme-Zyklus auf Basis der zzt. in den Systemen »GitHub Enterprise« bzw. »Bitbucket«, »Jira«, »SonarQube« und »Seerene« vorliegenden Daten.
Werden die definierten Qualitätsanforderungen nicht erfüllt, gilt die Leistung insoweit als mangelhaft und eine Freigabe bzw. fachliche Abnahme kann nicht erfolgen.
Die BA ist in diesem Fall berechtigt, die fachliche Abnahme ganz oder teilweise zu verweigern sowie Nachbesserung innerhalb einer angemessenen Frist zu verlangen.
Weitergehende gesetzliche und vertragliche Rechte der BA bleiben unberührt.
5.11 Freigabe und fachliche Abnahme
5.11.1 Unterscheidung Im Rahmen des Managed Services finden statt:
• Freigabe (monatlich) • zahlungsbegründende fachliche Abnahme (alle vier Monate; bezogen auf den Leistungszeitraum des Managed Service; Leistungszeitraum 2)
Die durch den AN erbrachten Leistungen des Managed Service werden im monatlichen Rhythmus durch die BA freigegeben.
Die fachliche Abnahme (im Folgenden: »Abnahme«) dient der Feststellung, dass die Leistungen ordnungsgemäß, vollständig sowie vertrags- und spezifikationskonform erbracht wurden. Mit der Abnahme bestätigt die BA die vertragsgemäße Leistungserbringung des jeweiligen Abnahmezeitraums.
Die alle vier Monate (=Abnahme-Zyklus) stattfindende Abnahme stellt hingegen die leistungs- und vergütungsrelevante Gesamtbewertung des Abnahmezeitraums dar. Die monatliche Freigabe entfaltet keine abschließende Wirkung hinsichtlich der Abnahme. Die Abnahme bleibt unabhängig von zuvor erteilten Freigaben einer vollständigen Gesamtbewertung vorbehalten. Beide Verfahren dienen der Steuerung, Qualitätssicherung und der nachvollziehbaren Bewertung der Leistungserbringung des AN.
Die Freigaben und Abnahmen erfolgen auf Basis der nachfolgend beschriebenen Kriterien und Nachweise.
5.11.2 Freigabe Die BA erteilt einmal monatlich im Rahmen des Monatsmeetings eine Freigabe über die im Betrachtungszeitraum erbrachten Leistungen des AN.
Die monatliche Freigabe dient der Bewertung der Leistungserbringung sowie der Sicherstellung eines stabilen Betriebs und stellt keine Abnahme dar. Sie hat hinsichtlich der Abnahme jedoch vorbereitenden und steuernden Charakter.
5.11.2.1 Grundlage der Freigabe Die monatliche Freigabe erfolgt auf Basis insbesondere folgender Bewertungs- und Nachweisgrundlagen:
• Quantitative Kriterien gemäß Leistungsbeschreibung
Seite 51 von insgesamt 81 Seiten
[Seite 52]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Bearbeitung (sowie Abschluss) sämtlicher von der BA im Betrachtungszeitraum übergebenen Demands • Bearbeitung und ggf. Abschluss sämtlicher von der BA im Betrachtungszeitraum übergebenen Incidents • Erfüllung der Pflege- und Supportleistungen im Betrachtungszeitraum • Durchführung und Nachweis der im Betrachtungszeitraum notwendigen Deployments und Releases
• Qualitative Kriterien
• Erfüllung der vereinbarten KPI gemäß Kapitel 5.11.2.2. • Vollständigkeit und Nachvollziehbarkeit der technischen Dokumentation • Stabilität der Systeme in den Vorumgebungen
Der AN hat die für die Freigabe erforderlichen Nachweise in einem monatlichen Ergebnisreport zusammenzustellen und der BA spätestens zum Zeitpunkt des Monatsmeetings (s. Kapitel 5.6.3) bereitzustellen.
5.11.2.2 KPIs der Freigabe Die folgenden KPI sind für die Freigabe maßgeblich und werden kalendermonatlich erhoben:
5.11.2.2.1 Code-Qualität
| Code-Fehlerquote (Seerene / Code Quality Metrics) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil fehlerhaften Codes im Verhältnis zum Gesamtcode. | ≤ 3 % | > 3 % bis 7 % | > 7 % |
| SonarQube Violations (Blocker / Critical / Major / Minor) | Grün | Gelb | Rot |
|---|---|---|---|
| Bewertung neuer Verstöße gegenüber definiertem Ausgangswert (Baseline bei Übergabe). | Blocker / Critical: 0 neue Verstöße Major: ≤ +2 % Reduktion zur Baseline Minor: kontinuierliche Reduktion | Blocker / Critical: ≤ +2 % zur Baseline Major: ± 0 % Veränderung Minor: stabil | Blocker / Critical: > +2 % Major: Verschlechterung > 0 % Minor: steigender Trend über 2 Intervalle |
| Code-Komplexität | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil des Codes mit Refactoring- /Wartungsbedarf (Toolgestützte Erhebung) | Durchschnitt ≤ 10 % | > 10 bis ≤ 15 % | > 15 % |
Codequalität – Erfassungs-Reifegrad
Seite 52 von insgesamt 81 Seiten
[Seite 53]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Für die Vermessung der E-AKTE ist sie logisch in Module unterteilt. Diese Modulstruktur wird in der »Seerene«-Plattform definiert und ist für die Bewertung maßgeblich. Der AN stellt sicher, dass sämtliche Codeartefakte aller Module, für die das Codeanalysewerkzeug »SonarQube« technisch anwendbar ist, mindestens 1x täglich durch »SonarQube« erfasst und analysiert werden. (Die vollständige Erfassung gilt als erfüllt, wenn der »Seerene«-KPI »SonarQube Availability« je Modul zu 100% erreicht wurde). Codebereiche, die nicht durch »SonarQube« erfasst werden, gelten als Qualitätsmangel. Codequalität – Reduktion von Regelverletzungen (»Violations«) Für jedes Modul werden zu Beginn und zum Ende eines Abnahme-Zyklus die durch »SonarQube« ermittelten Regelverletzungen (»Violations«) der »Severity«-Stufen …
• Blocker • Critical • Major • Minor
… ermittelt.
Seite 53 von insgesamt 81 Seiten
[Seite 54]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Fehler- klasse | Priorität im ESM | Beschreibung | Reaktionszeit | Wiederherstellun gszeit |
|---|---|---|---|---|
| 1 | 1 | Blocker: Die Nutzung eines Teiles des IT- Systems oder des IT-Gesamtsystems ist nicht möglich oder unzumutbar eingeschränkt. Der Fehler hat schwerwiegenden Einfluss auf die Geschäftsabwicklung und/oder den Datenschutz und/oder IT-Sicherheit. | 15 min | 90 min |
| 2 | 2 | Critical: Die Nutzung eines Teiles des IT- Systems oder des IT-Gesamtsystems ist wesentlich bzw. massiv eingeschränkt. Der Fehler hat wesentlichen Einfluss auf die Geschäftsabwicklung und/oder den Datenschutz und/oder IT-Sicherheit, lässt aber eine Weiterarbeit prinzipiell zu. Im Einzelfall existieren sehr aufwändige Umgehungslösungen. | 25 min | 180 min |
| 3 | 3 | Major: Die Nutzung eines Teiles des IT- Systems oder des IT-Gesamtsystems ist eingeschränkt. Der Fehler hat Einfluss auf die Geschäftsabwicklung und/oder den Datenschutz und/oder IT-Sicherheit. Das System kann genutzt werden, aber die Nutzung führt zu erheblichem Mehraufwand. Umgehungslösungen können noch mit vertretbarem Aufwand verwendet werden. | 90 min | 500 min |
| 4 | 4 | Minor: Die Nutzung eines Teiles des IT- Systems oder des IT-Gesamtsystems ist leicht eingeschränkt. Der Fehler hat unwesentlichen Einfluss auf die Geschäftsabwicklung und/oder Datenschutz und/oder IT-Sicherheit, lässt jedoch eine weitere Verarbeitung uneingeschränkt zu. | 240 min | 1440 min |
Grundlage der Bewertung ist das durch die BA vorgegebene »SonarQube«-Ruleset.
Der AN verpflichtet sich, sicherzustellen, dass die Anzahl der »Violations« je »Severity«-Stufe pro Modul nicht ansteigt. Die KPI-Werte werden in der »Seerene«-Plattform je Modul berechnet und sind dort transparent einsehbar.
Darüber hinaus verpflichtet sich der AN zur Behebung von Fehlern der Fehlerklasse 1 und 2 (»Blocker« sowie »Critical«) vor dem Go-Live in der Produktion und zur kontinuierlichen Verbesserung der Codequalität nach dem Prinzip: »Verlasse den Code in einem besseren Zustand, als er vorgefunden wurde.« Dies beinhaltet insbesondere die angemessene Behebung bestehender »Violations« im Zuge von Codeänderungen. Ein Anstieg der »Violations« stellt einen Qualitätsmangel dar.
Codequalität – Absicherung durch Unit-Tests
Seite 54 von insgesamt 81 Seiten
[Seite 55]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Für jedes Modul werden die Codebereiche definiert, die durch Unit-Tests automatisiert überprüfbar sind. Diese Definition erfolgt über die »Seerene«-Plattform und ist verbindlich.
Der AN stellt sicher, dass:
• Initial eine Continuous-Integration-(CI)-Pipeline eingerichtet und betrieben wird, • der Code regelmäßig (mindestens 1x pro Arbeitstag oder bei Änderungen am Hauptentwicklungszweig) gebaut wird, • sämtliche Unit-Tests automatisiert ausgeführt werden, • und die resultierenden »Code-Coverage«-Werte (»Line-Coverage« und »Branch«- Coverage) an »SonarQube« und hierüber an »Seerene« übermittelt werden.
Für jedes Modul werden zu Beginn und zum Ende eines Abnahme-Zyklus folgende Kennzahlen erhoben:
• Line-Coverage • Branch-Coverage
Der AN verpflichtet sich, sicherzustellen, dass diese Kennzahlen je Modul im Verlauf eines Abnahme-Zyklus nicht absinken.
Darüber hinaus ist der AN verpflichtet, bei Änderungen am Code die Codeabdeckung durch Unit-Tests angemessen zu verbessern oder mindestens beizubehalten. Ein Absinken der Coverage-Werte stellt einen Qualitätsmangel dar.
5.11.2.2.2 Code-Compliance & Tooling
| Coding Violations (allgemein) | Grün | Gelb | Rot |
|---|---|---|---|
| Anzahl und Schwere von Regelverstößen (Blocker/Critical/Major) | ≤ 5 Verstöße / 1.000 LOC | > 5 bis ≤ 10 / 1.000 LOC | > 10 / 1.000 LOC |
| Deaktivierter Code | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil von auskommentiertem / deaktiviertem Code | ≤ 2 % | > 2 % bis ≤ 5 % | > 5 % |
5.11.2.2.3 Testing & Stabilität
| Unit-Test-Abdeckung (feingranular) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil Code mit dedizierten Unit-Tests | ≥ 85 % | ≥ 75 % – 85 % | < 75 % |
| Code-Abdeckung | Grün | Gelb | Rot |
|---|---|---|---|
| Entwicklung von Line- und Branch-Coverage je Modul im Abnahme- Zyklus (gemessen via »SonarQube«/»Seerene«) | Nicht sinkend oder steigend | Gleich bleibend | Sinkend |
Seite 55 von insgesamt 81 Seiten
[Seite 56]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.11.2.2.4 Transparenz & Steuerbarkeit
| Below-the-radar Work (Traceability über Ticketsystem, z. B. Jira) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil der Arbeiten ohne Ticket / Nachverfolgbarkeit (toolgestützte Erhebung) | 100 % aller Änderungen nachvollziehbar | : ≥ 95 % bis < 100 % | < 95 % |
| Dokumentationsgrad | Grün | Gelb | Rot |
| Vollständigkeit der Dokumentation je Feature (inkl. Systeme wie Innovator) | ≥ 95 % vollständig dokumentiert | ≥ 85 % bis < 95 % | < 85 % |
| Fehlerstand (Jira- basierte Fehlerentwicklung) | Grün | Gelb | Rot |
|---|---|---|---|
| Entwicklung der Gesamtfehleranzahl | sinkender Trend / stabile niedrige Anzahl | stagnierend | steigender Trend über 2 Monate |
5.11.2.3 Ergebnis der Freigabe Die monatliche Freigabe kann erteilt werden als:
• Freigabe ohne Einschränkung • Nicht-Freigabe aufgrund von Auflagen / Nachforderungen
Auflagen / Nachforderungen sind durch den AN innerhalb von maximal 10 Arbeitstagen abschließend zu bearbeiten.
5.11.3 Abnahme (zahlungsbegründend) Alle vier (Kalender-)Monate erfolgt eine zusammenfassende, zahlungsbegründende Abnahme der im Zeitraum erbrachten Leistungen.
5.11.3.1 Phasenbasierter Abnahmeprozess Der vertraglich verbindliche Abnahmeprozess orientiert sich am Releaseplan (s. Kapitel 8.3) und durchläuft zwingend folgende Phasen, um eine systematische und dokumentierte Prüfung sicherzustellen:
• Bereitstellungsanzeige und Prüfung der Dokumentation: Der AN übergibt das Testobjekt formal zur Abnahme und reicht den vollständigen Testabschlussbericht sowie alle Testprotokolle ein. Die BA prüft die formale Vollständigkeit.
• Prüfung und Stichprobentests: Nach Bestätigung der Vollständigkeit führt die BA (oder ein von ihr beauftragter Dritter) eigene Stichprobentests durch, um die Ergebnisse des ANs zu verifizieren und die qualitativen Kriterien zu bewerten.
• Bewertungsentscheidung: Die BA bewertet auf Basis der Dokumentation und der Stichprobentests, ob die Abnahmekriterien vollumfänglich erfüllt sind.
Seite 56 von insgesamt 81 Seiten
[Seite 57]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Formale Abnahmeerklärung: Bei Erfüllung aller Kriterien erfolgt die schriftliche und rechtsverbindliche Abnahmeentscheidung durch die BA.
• Verfahren bei Nicht-Abnahme (Nachbesserung): Werden Kriterien nicht erfüllt, verweigert die BA die Abnahme in Textform unter Angabe der festgestellten Mängel. Der AN ist verpflichtet, diese Mängel innerhalb einer Frist von maximal zehn (10) Arbeitstagen kostenfrei nachzubessern und das Testobjekt erneut zur Abnahme bereitzustellen. Schlägt die erneute Abnahme fehl, behält sich die BA das Recht vor, vom Vertrag zurückzutreten oder Minderung geltend zu machen.
5.11.3.2 Grundlage der Abnahme Die Abnahme wird erteilt, wenn sämtliche nachfolgenden Kriterien erfüllt sind:
• Vollständigkeit der Leistungserbringung
Alle im Abnahmezeitraum vereinbarten Leistungen wurden vollständig erbracht. Erfüllung liegt vor, wenn keine offenen, dem AN zuzuordnenden Leistungen bestehen.
• Erfüllung der fachlichen Anforderungen
Die umgesetzten Funktionen und Änderungen entsprechen den fachlichen Anforderungen gemäß Abstimmung mit der BA. Erfüllung liegt vor, wenn keine fachlichen Abweichungen oder Fehlinterpretationen festgestellt werden.
• Einhaltung der vereinbarten Qualitätsstandards (KPIs)
Die definierten KPI-Zielwerte (s. Kapitel 5.11.3.3) wurden im Abnahmezeitraum eingehalten. Erfüllung liegt vor, wenn keine KPI-Bewertung im Status »Rot« vorliegt und maximal tolerierbare »Gelb«-Abweichungen entsprechend begründet und adressiert wurden. Bei Abweichungen gelten die Regelungen der Anlage »KPI- Erfüllung« zu dieser LB.
• Fehlerfreiheit / Defect-Status
Es bestehen keine kritischen oder »Blocker«-relevanten Fehler in den gelieferten Leistungen. Erfüllung liegt vor, wenn keine offenen Fehler der Kategorie »Blocker« oder »Critical« vorhanden sind und die Anzahl verbleibender Fehler im akzeptierten Rahmen liegt.
• Erfolgreiche Tests und Qualitätssicherung
Die vereinbarten Testmaßnahmen wurden erfolgreich durchgeführt. Erfüllung liegt vor, wenn alle definierten Testfälle erfolgreich durchlaufen wurden und keine kritischen Abweichungen bestehen.
• Dokumentation
Die erforderliche Dokumentation wurde vollständig, aktuell und nachvollziehbar bereitgestellt. Erfüllung liegt vor, wenn die Dokumentation den vereinbarten Standards entspricht und eine Übergabe bzw. Weiterbetrieb durch Dritte ermöglicht.
• Nachvollziehbarkeit (Traceability)
Sämtliche Änderungen, Entwicklungen und Leistungen sind vollständig dokumentiert und nachvollziehbar. Erfüllung liegt vor, wenn jede produktive Änderung einem Demand oder Incident zugeordnet werden kann.
• Termingerechte Lieferung
Seite 57 von insgesamt 81 Seiten
[Seite 58]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Die Leistungen wurden innerhalb der vereinbarten Fristen bereitgestellt. Erfüllung liegt vor, wenn die vereinbarten Liefertermine eingehalten wurden oder Abweichungen vorab abgestimmt und genehmigt wurden.
• Betriebliche Stabilität (sofern relevant)
Die gelieferten Änderungen führen zu keiner Beeinträchtigung des laufenden Betriebs. Erfüllung liegt vor, wenn keine durch den AN verursachten Störungen im Produktivbetrieb auftreten.
Sofern einzelne Kriterien nicht vollständig erfüllt sind, kann die Abnahme unter Vorbehalt erfolgen, sofern:
• keine kritischen Mängel vorliegen und
• eingebaute Funktionen deaktivierbar sind und
• die Nutzung der Leistungen nicht wesentlich eingeschränkt ist.
Offene Punkte sind in diesem Fall vom AN verbindlich zu dokumentieren und innerhalb einer mit der BA abgestimmten Frist durch den AN zu beheben.
Für Abstimmungen sind die in Kapitel 5.6 genannten Abstimmungsformate zu nutzen.
Diese Abnahme bildet die Grundlage für die Abrechnung der im Abnahmezeitraum erbrachten Leistungen.
Die Abnahme erfolgt auf Basis einer aggregierten Bewertung der im Zeitraum erbrachten Leistungen insbesondere hinsichtlich:
• vollständiger und vertragsgemäßer Leistungserbringung gemäß LB
• kumulierter KPI-Erfüllung über den Abnahmezeitraum
Die konkrete Ausgestaltung der Abnahmekriterien erfolgt in Anlage 6.
5.11.3.3 KPIs der Abnahme 5.11.3.3.1 Testing & Stabilität
| Testabdeckung (automatisiert) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil des Codes mit automatisierten Tests | ≥ 80 % | 60 % – 80 % | < 60 % |
| Erfolgsquote | Grün | Gelb | Rot |
|---|---|---|---|
| Prozentualer Anteil der erfolgreich durchgeführten Testfälle beim finalen Durchlauf (ohne Workarounds) | ≥ 95 % | 80 % – 95 % | < 80 % |
| Fehlerfreiheit kritischer Klassen | Grün | Gelb | Rot |
|---|---|---|---|
| Offene Fehler der Störungsklassen 1 und | 0 | 0 (Störungsklasse 1) | > 0 (Störungsklasse 1) |
Seite 58 von insgesamt 81 Seiten
[Seite 59]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| 2 zum Zeitpunkt der Abnahmeübergabe | 1 (Störungsklasse 2) | > 1 (Störungsklasse 2) | |
|---|---|---|---|
| Fehlerfreiheit Klasse 3 | Grün | Gelb | Rot |
| Offene Fehler der Störungsklassen 3 zum Zeitpunkt der Abnahmeübergabe | ≤ 4 Fehler | 5 – 6 Fehler | > 6 Fehler |
Hinweis: Im Bereich »Barrierefreiheit« gelten andere Fehlertoleranzen (s. Kapitel 5.4.2.8) 5.11.3.3.2 Lieferung & Qualität der Übergabe
| Termintreue (On- Time Delivery) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil fristgerecht gelieferter Features zum FTNF | ≥ 95 % | 85 % – 95 % | < 85 % |
| Nachbearbeitungsquote (Post-FTNF) | Grün | Gelb | Rot |
|---|---|---|---|
| Anteil der Features mit Nacharbeit nach Übergabe | ≤ 5 % der Features | 6 % – 15 % der Features | > 15 % der Features |
5.11.3.3.3 Performance
| Antwortzeitverhalten (Lasttest) | Grün | Gelb | Rot |
|---|---|---|---|
| Entwicklung der System-Performance über die letzten Releases | stabile oder verbesserte Antwortzeiten | leichte Verschlechterung der Antwortzeiten (bis zu 5%) | signifikante Verschlechterung der Antwortzeiten (5% oder mehr) |
5.11.3.4 Abnahmeverfahren Die Abnahme kann erfolgen als:
• uneingeschränkte Abnahme
• Abnahme unter Vorbehalt einzelner Mängel (Erfüllungsgrad „gelb“ bei maximal zwei KPIs)
• Zurückweisung der Abnahme bei wesentlichen Leistungsabweichungen (Erfüllungsgrad „gelb“ bei mehr als zwei KPIs bzw. „rot“ bei mindestens einer KPI)
Im Falle von Mängeln ist der AN verpflichtet, diese innerhalb maximal 5 Arbeitstage zu beseitigen und die Abnahme erneut herbeizuführen.
Seite 59 von insgesamt 81 Seiten
[Seite 60]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
5.12 Bedienter Betrieb und Programmversion /
Wartungsfenster
| Leistung | Tag | Zeitraum | Anmerkung | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Zeiten des bedienten Betriebs (Servicezeit E- AKTE) = Servicezeit 1 | Mo – Do | 6:30 Uhr - 18:00 Uhr | Nicht an bundeseinheitlichen Feiertagen | ||||||||
| Fr | 6:30 Uhr – 16:00 Uhr | ||||||||||
| Programmversion / Wartungsfenster | Fr - So | Nach Ende des Dialogs | 3-9 Wochenenden/Kalenderjahr: Die Programmversion ist zu unterstützen und abzunehmen. |
Reguläre Arbeitszeiten innerhalb der BA sind an Arbeitstagen gemäß Kapitel 13 von 06:00 Uhr bis 21:00 Uhr. In diesem Zeitraum steht die Infrastruktur für die Aufgabenerledigung dem AN zur Verfügung. Außerhalb dieser Zeiten ist eine Verfügbarkeit des Arbeitsplatzes nicht garantiert.
6 Beistellleistungen der BA / Leistungsabgrenzung
• Im Falle von Vor-Ort-Tätigkeiten stellt die BA die Räumlichkeiten entsprechend den BA- Standards kostenneutral in den Liegenschaften der BA zur Verfügung. Die BA stellt dem AN grundsätzlich keine Endgeräte zur Verfügung. Es kann jedoch davon ausgegangen werden, dass innerhalb der BA-Räumlichkeiten an den Arbeitsplätzen Tastatur, Monitor und Maus verfügbar sind. Die für die Remotearbeit erforderliche technische Ausstattung muss durch den AN zur Verfügung gestellt werden. Dies erfolgt für die BA kostenneutral. • Notwendige Benutzerkennungen, Zugriffsrechte und Zutrittsberechtigungen werden durch die BA eingerichtet. • Die BA stellt grundsätzlich einen zentralen 1st Level Support (UHD der BA, siehe Kapitel 13) zur Verfügung, über den alle Incidents der Anwender erfasst und qualifiziert werden. Darüber hinaus können Anfragen des Fachbereiches für Controlling und Statistik auftreten, die über Mitarbeiter der BA an den Managed Service weitergeleitet werden. Fachliche- oder Softwarefehler werden durch die BI-Systementwicklung behoben.
7 Sonstige Leistungen
7.1 Vorlaufende Transition (Werkleistung)
Die vorlaufende Transition umfasst sämtliche Tätigkeiten des AN von der Einarbeitung bis zur verantworteten Übernahme des Managed Service der E-AKTE. Der Leistungszeitraum dieser Leistung beträgt bis zu drei Kalendermonate und endet mit der fachlichen Abnahme der Leistung. Der AN übernimmt die vorlaufende Transition in eigener Verantwortung. Die BA steht ergänzend als Unterstützung für Fragen, Einzelthemen oder Probleme in der Zusammenarbeit mit dem Vorgänger bereit und wirkt zudem als Eskalationsinstanz mit. Der Vorgänger ist vertraglich nicht verpflichtet, die Transition zu unterstützen und steht somit höchstens eingeschränkt für Einzelfragen zur Verfügung. Daher obliegt dem AN hier eine besondere Planungs- und Durchführungsverantwortung. Der Beginn der vorlaufenden Transition erfolgt voraussichtlich in Abstimmung zwischen BA und AN direkt nach Zuschlagserteilung. Den Abschluss der Transition muss der AN der BA in Textform vor dem Beginn des Managed Service gemäß Kapitel 8.2 anzeigen. Die vorlaufende Transition wird als Werkleistung fachlich abgenommen.
Seite 60 von insgesamt 81 Seiten
[Seite 61]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Sollten die Abstimmungsformate nicht ausreichen, etabliert der AN in Absprache mit der BA ein »Transitionstatusmeeting« (vor Ort bzw. digital) mit der BA für die Steuerung der Transition. Er erstellt das Protokoll und sorgt für einen angemessene Vorbereitung des Meetings inkl. Einladung. Sollten dem AN Erkenntnisse vorliegen, die den Erfolg der Transition in Frage stellen oder die terminliche oder fachliche Verletzung der vereinbarten »Quality Gates« nach sich ziehen könnten, informiert er die BA unverzüglich, welche Maßnahmen eingeleitet werden, um die Ziele doch noch zu erreichen, und prüft ständig die Wirksamkeit der Maßnahmen. Der AN führt ein Risikoregister mit Maßnahmen, um erhebliche Risiken zu vermeiden oder zu minimieren. Sollten erhebliche Risiken eintreten, so bewerten die Parteien umgehend, ob die Übernahme des »Managed Service« noch erreicht werden kann. Zu den vorgesehenen »Quality Gates« entscheidet die BA anhand des Risikoregisters, ob die Transitionsphase verlängert werden muss. Vorbereitende Tätigkeiten: Für die ordnungsgemäße Übernahme der Leistung vom Vorgänger ist Folgendes zu erstellen:
• ein Transitionsplan • eine »Knowledge Transfer Checkliste« • ein Qualitätsplan und • ein Risikoregister. Die Dokumente beschreiben alle für den ordnungsgemäßen Übergang erforderlichen Termine und allgemein üblichen Maßnahmen. Sie sind vom AN zur Steuerung der entsprechenden Maßnahmen innerhalb der ersten 2 Kalenderwochen nach Beginn der vorlaufenden Transition zu erstellen und der BA zur fachlichen Freigabe vorzulegen. Die Dokumente müssen folgende Inhalte abbilden: • Transitionsplan ➢ Zuordnung von Liefergegenständen zu Meilensteinen ➢ Meilensteine des Qualitätsplans ➢ Aktivitäten je Transitionsteilprojekt ➢ Mitwirkungsaktivitäten der BA • »Knowledge Transfer Checkliste« ➢ Die »Knowledge Transfer Checkliste dient dazu, den Transfer von Know-How vom AN an die BA zu planen und zu steuern. Für jeden Punkt der Checkliste weist der AN nach, dass das Transferziel erreicht wurde. • Qualitätsplan ➢ Der Qualitätsplan enthält Messwerte des AN, die eine Überprüfung des Transitionserfolges zu »Quality Gates« ermöglicht. Der AN schlägt im Rahmen seines Qualitätsplanes vor, welche Meilensteine eingerichtet werden, um den Erfolg des Transitionsverlaufes kontinuierlich zu messen. Der AN nimmt zusätzliche Qualitätsanforderungen der BA in seinen Qualitätsplan auf. • Risikoregister ➢ Das Risikoregister enthält alle potenziellen Risiken, die das Transitionsziel gefährden können. Es zeigt nicht nur Risiken auf und analysiert, sondern enthält auch konkrete Maßnahmen zur Risikominderung. Durchführung der fachlichen Abnahme: Die fachliche Abnahme der Werkleistung umfasst die gegenüber der BA in Textform erklärte vollumfängliche Leistungsübernahme. Die fachliche Abnahme ist zu einem Zeitpunkt
Seite 61 von insgesamt 81 Seiten
[Seite 62]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
abzuschließen, der innerhalb der Transitionsphase liegen muss – dieser wird zwischen der BA und dem AN spätestens 2 Wochen nach Abruf der vorlaufenden Transition festgelegt. In der Zeitplanung ist zu berücksichtigen, dass die BA dazu eine Überprüfung vornehmen wird und ggf. eine Nachbesserung durchzuführen ist, die dann ebenfalls noch einmal zu überprüfen ist. Nach der Erklärung des AN wird die BA die ordnungsgemäße Übernahme der Leistung überprüfen. Die fachliche Abnahme wird von der BA in Textform bestätigt. Die fachliche Abnahme der vorlaufenden Transition kann unter folgenden Voraussetzungen erfolgen: • der AN in Textform erklärt, dass aus seiner Sicht keine übernahmeverhindernden bzw. -behindernden Punkte aus der Übergabe des Service mit dem bisherigen AN mehr vorliegen, bzw. er legt eine mit dem bisherigen AN oder der BA besprochene Übersicht dieser Punkte mit einem abgestimmten Zeitplan vor. • der AN bestätigt, dass die übernommenen Konzepte und Dokumentationen : ➢ die Aufgaben des Managed Service unter Berücksichtigung der in dieser LB, dem Angebot des AN und dem zugehörigen Vertrag dokumentierten Anforderungen vollständig beschreiben, ➢ alle gemäß der LB relevanten Themen in hinreichender Detailtiefe (Vollständigkeit, Detaillierungsgrad) beschrieben sind, ➢ keine formalen Fehler aufweisen (Aufbau, Sprache o. ä.), ➢ in sich logisch, nachvollziehbar und widerspruchsfrei sind (Plausibilität). • die Übernahme der offenen INC bzw. PRO vollständig durch den AN erfolgt ist und es für die hochprioren Tickets beider Prozesse abgestimmte Maßnahmen und Zeitplanungen gibt. • die fachliche Freigabe der Dokumente (Transitionsplan, Knowledge Transfer Checkliste, Qualitätsplan und ein Risikoregister) durch die BA erfolgt ist. Wichtig: Im Falle einer Nichtabnahme wird durch die BA unter Berücksichtigung eines angemessenen Zeitrahmens für die Mängelbeseitigung ein neuer Termin für die Bereitstellung zur fachlichen Abnahme gesetzt. Der AN muss diesen Aspekt in seiner eigenen Zeitplanung angemessen berücksichtigen. Es wird nochmals betont, dass die vorlaufende Transition einen zeitlichen Fixtermin in Bezug auf den Endzeitpunkt beinhaltet. Sollte die fachliche Abnahme nicht rechtzeitig vor dem Übergabestichtag möglich sein, so kann die BA die Transitionsphase einseitig verlängern oder die Transition für gescheitert erklären und die fachliche Abnahme gänzlich verweigern. In diesen Fällen trägt der AN die Kosten, die mit der Nicht-Abnahme der Transition verbunden sind. Dies sind die eigenen Kosten der Transitionsphase und die Mehrkosten einer Weiterbeauftragung bisheriger Servicestellen (z. B. Differenz zwischen eigener angebotener Monatspauschale und den monatlichen Kosten des alternativen ANs). Die Kosten fallen an bis zur eigenen Übernahme oder durch die Übernahme eines neuen ANs, jedoch begrenzt auf maximal 6 Monate.
7.2 Abschließende Transition (Werkleistung)
Die abschließende Transition umfasst alle Tätigkeiten, um bis zum regulären Vertragsende einen neuen von der BA bestimmten AN (=Nachfolger) oder auch BA-eigenes Personal zu befähigen, die in diesem Dokument beschriebenen Tätigkeiten in einer geordneten Art und Weise zu übernehmen und die beschriebenen Tätigkeiten in gleicher Weise fortzuführen. Die Verantwortung zur Übernahme trägt dabei der Nachfolger. Der AN dieses Vertrages
Seite 62 von insgesamt 81 Seiten
[Seite 63]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
verpflichtet sich jedoch, die Übernahme professionell und bestmöglich vorzubereiten und sowohl die BA als auch den Nachfolger in dieser Phase aktiv zu unterstützen. Vorbereitende Tätigkeiten: Für den ordnungsgemäßen Übergang der Leistung auf einen Nachfolger ist ein Transitionskonzept zu erstellen. Nach Aufforderung durch die BA muss der AN das Transitionskonzept innerhalb von 2 Monaten bereitstellen. Das Transitionskonzept beschreibt alle für den ordnungsgemäßen Übergang erforderlichen und allgemein üblichen Maßnahmen. Es ist vom AN zur Steuerung der entsprechenden Maßnahmen vor Beginn der Durchführung der abschließenden Transition zu erstellen und der BA zur fachlichen Freigabe vorzulegen. Durchführung der abschließenden Transition: Die BA geht davon aus, dass die konkrete Durchführung der abschließenden Transition (Einarbeitung eines neuen Leistungserbringers) ca. 2 Monate dauert. Die abschließende Transition endet zeitgleich mit der Leistungserbringung gem. Kapitel 5. Jegliche Verzögerung im Ablauf der abschließenden Transition hat der AN der BA unverzüglich anzuzeigen. Die Leistungen der abschließenden Transition werden als Werkleistung fachlich abgenommen. Die fachliche Abnahme wird von der BA in Textform bestätigt. Die fachliche Abnahme erfolgt, wenn folgende Kriterien erfüllt sind:
• Die Betriebsdokumentation wurde auf den neuesten Stand gebracht, mit dem Nachfolger besprochen und diesem vollständig übergeben sowie die Übergabe protokolliert. • Bis zum Zeitpunkt der Übergabe sind alle offenen bzw. ungelösten Incidents und Problem-Tickets im Detail besprochen worden und der Nachfolger hat die Bearbeitung in jedem Ticket übernommen. • Sämtliche Punkte des Transitionkonzepts wurden abgearbeitet und die gestellten Rückfragen des Nachfolgers wurden beantwortet bzw. ihm in Textform im notwendigen Umfang erläutert. • Dem Nachfolger wurden keine Sachverhalte bewusst oder unbewusst vorenthalten, die ihm die Fortführung des Service kurzfristig oder zu späteren Zeitpunkten in deutlichem Maße erschwert bzw. behindert.
Im Fall einer Nichtabnahme der Leistung wird durch die BA unter Berücksichtigung eines angemessenen Zeitrahmens für die Mängelbeseitigung ein neuer Termin für die Bereitstellung zur fachlichen Abnahme gesetzt, der aber noch innerhalb des geplanten Zeitraumes der Leistungserbringung liegen sollte. Der AN sollte diesen Aspekt in seiner eigenen Zeitplanung angemessen berücksichtigen. Muss die abschließende Transition aus Gründen verlängert werden, die der AN selbst zu verantworten hat, ist er verpflichtet, das notwendige Personal für den Verlängerungszeitraum kostenfrei verfügbar zu halten.
7.3 Exit-Management
Der AN stellt für bis zu zwei Kalendermonate nach Beendigung der Leistungserbringung nach Kapitel 5 sicher, dass kompetente Ressourcen zur Verfügung stehen, um nachträglich noch aufgetretene Rückfragen des Nachfolgers bzw. der BA telefonisch bzw. per Mail kurzfristig zu beantworten. Der Leistungsbestandteil gilt dann als erfüllt, wenn alle innerhalb der zwei Monate eingegangenen Rückfragen zufriedenstellend beantwortet wurden (es treten keine weiteren Rückfragen zu bereits gestellten Fragen auf). Das Exit-Management berechtigt nicht zu separater Vergütung. Hinsichtlich Tests hat der AN der BA zum Beendigungszeitpunkt folgende Artefakte in einem gängigen, maschinenlesbaren Format manipulationssicher zu übergeben:
Seite 63 von insgesamt 81 Seiten
[Seite 64]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
• Den vollständigen, lauffähigen und unverschlüsselten Quellcode aller Testautomatisierungsskripte und Testfälle. • Die komplette Testhistorie (Logs, Metriken) aus den eingesetzten Tools. • Eine aktuelle, detaillierte System- und Testdokumentation. • Sämtliche für Testzwecke erstellten Zugänge und administrativen Rechte. Der AN verpflichtet sich, das BA-Personal oder einen designierten Dritten in die erstellten Teststrukturen, Skripte und spezifischen Problemlösungsverfahren einzuarbeiten und für Rückfragen aussagefähig zu sein.
7.3.1 Exit-Management-Konzept Der AN stellt eine schriftliche Ausarbeitung eines Exit-Management-Konzepts im Rahmen der schriftlichen Beantwortung des B-Kriteriums B7 zu dieser LB bereit. Das Exit-Management- Konzept beschreibt alle für den ordnungsgemäßen Übergang erforderlichen und allgemein üblichen Maßnahmen. Insbesondere muss es folgende Punkte enthalten:
• Konzept zur Migration der Anwendungskonfiguration
• Notwendige Schritte zum Export der Anwendungskonfigurationen und
• Erläuterung der Strukturen der exportierten Anwendungskonfiguration
• Anleitung zur Interpretation der exportierten Anwendungskonfigurationen
• Beschreibung der Software zum Export der Anwendungskonfiguration in einem digital verarbeitbarem Standardformat, die der AN zur Verfügung stellt
• Konzept zur Migration der Anwendungsdaten
• Notwendige Schritte zum Export aller Anwendungsdaten
• Beschreibung der Software zum Export der Anwendungsdaten in einem digital verarbeitbarem Standardformat, die der AN zur Verfügung stellt
• Unterstützungsleistung des AN beim Exit-Management o Wie unterstützt der AN die BA? o Welche Leistungen unterstützt der AN an den neuen AN?
• Welche Möglichkeit werden angeboten, nach Ablauf des Leistungszeitraumes auf die E-AKTE und die darauf entwickelten Anwendungen zuzugreifen ohne Transaktionen auszuführen? Insbesondere gilt dies für Revisions- oder Auswertungszwecke.
• Welche Möglichkeit bietet der AN der BA nach Ablauf des Leistungszeitraumes an, auf den vom AN auf seinen Systemen entwickelten Code der E-AKTE und die dafür entwickelten (und z. B. per WebDAV übertragenen) Anwendungen zuzugreifen bzw. die Anwendungen weiter zu nutzen?
• Sämtliche Punkte des Exit-Management-Konzepts wurden abgearbeitet und die gestellten Rückfragen des neuen ANs wurden beantwortet bzw. ihm in Schriftform im notwendigen Umfang erläutert.
• Dem neuen AN wurden keine Sachverhalte bewusst oder unbewusst vorenthalten, die ihm die Fortführung des Managed Service kurzfristig oder zu späteren Zeitpunkten in deutlichem Maße erschwert bzw. behindert.
Seite 64 von insgesamt 81 Seiten
[Seite 65]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
7.4 Ergänzende Dienstleistungen
Zusätzlich besteht für die BA die Möglichkeit, ein ergänzendes, optionales Dienstleistungskontingent abzurufen, um bei den in der Anlage 4 zur LB dargestellten Skills bei beispielsweiser operativer Notwendigkeit eine vorübergehende Personalverstärkung zu erhalten. Die geschätzte Abrufmenge über den maximal möglichen Leistungszeitraum hinweg beträgt 4.000 Personentage (PT). Dies entspricht 32.000 Personenstunden (PS). Die geschätzte Abrufmenge kann, abhängig von den fachlichen Notwendigkeiten und den haushalterischen Gegebenheiten, über- oder unterschritten werden. Eine Abrufverpflichtung seitens der BA besteht nicht. Die Abrechnung erfolgt nach tatsächlich erbrachtem Aufwand auf Basis des angebotenen Stundensatzes. Gründe für einen Abruf aus dem optionalen Dienstleistungspaket können sein: • Extrem kurzfristige Umsetzungsnotwendigkeit einer fachlichen Anforderung • Dienstzeiten zu Zeiten außerhalb vereinbarter Zeiten der Leistungserbringung • Abfederung des Übergangs zu einem notwendigen Änderungsverlangen wegen eines dauerhaften Mehraufwands Ein bevorstehender Abruf wird dem AN schnellstmöglich signalisiert, z. B. im Rahmen des Monatsmeetings (s. Kapitel 5.6. Die konkreten Skillanforderungen sind der Anlage 4 zu dieser Leistungsbeschreibung zu entnehmen und sind durch den AN in dem zur jeweiligen Aufgabenerfüllung notwendigen Umfang bereitzustellen.
7.4.1 Zeiten der Leistungserbringung bei den ergänzenden Dienstleistungen Für die Leistungserbringung für die optionalen Dienstleistungen gelten die in Kapitel 8.4.2 genannten Servicezeiten (SZ) und Rufbereitschaftszeiten (RBZ). Hierzu sind differenzierte Stundensätze im Preisblatt (Leistungsverzeichnis) auszuweisen.
7.4.2 Vorgehen bei Dienstleistungsabrufen Der AN wird bei Abrufen zum Angebot aufgefordert. Die im Rahmen des Abrufs zu erbringenden Leistungen werden ggf. in Arbeitspaketen beschrieben. Hierzu erfolgt eine Anfrage zur Skill-Bereitstellung an den AN. Die Angebotsaufforderung enthält die wichtigsten Informationen, wie z. B. Aufgaben- beschreibung, Abrufzeitraum und Abrufvolumen. Ein Abruf kann einzelne Skills, mehrere Skills oder Skills für ein vollständiges Team beinhalten. Wird ein vollständiges Team abgerufen, so muss das Angebot alle angeforderten Skills im kompletten geforderten Abrufvolumen für den genannten Abrufzeitraum beinhalten. Angebote, die diese Anforderung nicht erfüllen, werden ausgeschlossen. Zur Einschätzung der vertraglich zugesicherten Qualifikationen erhält die BA die pseudonymisierten Qualifikationsprofile der angebotenen Skillprofile. Bei der Erstellung der Qualifikationsprofile soll der AN sich an dem beigefügten Muster-Qualifikationsprofil (Anlage 5 zur Leistungsbeschreibung) orientieren und hat mitzuteilen, ob es sich bei der angebotenen Person um einen freiberuflich Tätigen (sogenannter Freelancer), der weder bei dem Generalunternehmer noch bei einem der Subunternehmer Arbeitnehmer ist, handelt Der AN hat für jeden Dienstleister, der bei der BA tätig werden soll, im Rahmen des Angebots einschlägige Referenzprojekte aus den letzten 2-3 Jahren zu benennen und zu beschreiben, an denen die Skillprofile maßgebend beteiligt waren. Die BA hat das Recht, diese Referenzprojekte zu überprüfen.
Seite 65 von insgesamt 81 Seiten
[Seite 66]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Das Angebot muss grundsätzlich innerhalb von 10 Arbeitstagen nach Angebotsaufforderung bei der BA vorliegen, es sei denn, in der Angebotsaufforderung wird eine andere Frist genannt. Zusätzliche Anforderungen gehen über die im Skillprofil genannten Mindestanforderungen hinaus und haben einen direkten Bezug zur konkreten gewünschten Tätigkeit bzw. zum Aufgabenpaket: Beispiele (Aufzählung nicht abschließend): • Kenntnisse in bestimmten Programmiersprachen • Kenntnisse in bestimmten Testtools • Erfahrung bei der Erstellung von Dokumentationen • Erfahrung bei der Einführung bestimmter Verfahrensarten (z.B. HR-Tools). Dem Einsatz einer vom AN für die Vertragserfüllung vorgesehenen Person in einem Dienstleistungsabruf kann ein Gespräch durch die BA zum Abgleich des Skillprofils und gegebenenfalls zur Festlegung der Einarbeitung vorausgehen. Die Entscheidung über die Notwendigkeit eines Gespräches trifft die BA. Das Gespräch findet nach Wahl der BA virtuell oder im Großraum Nürnberg statt. Diese Leistung wird nicht gesondert vergütet. Die BA wird den vorgeschlagenen externen Dienstleister ablehnen, wenn dieser nicht dem geforderten Skillprofil entspricht oder andere Gründe in der Person und/oder des Subunternehmers vorliegen, die einem Einsatz entgegenstehen (z.B. Interessenkollision durch Einsatz in der BA, früheres Fehlverhalten bei Einsatz in der BA). Nach Prüfung durch die BA wird der zu AN auf elektronischem Weg (per E-Mail) über die Beauftragung informiert. Spätestens zehn Arbeitstage nach der Einzelbeauftragung stehen die externen Dienstleister zum Einsatz bei der BA zur Verfügung, es sei denn, in der Angebotsaufforderung ist eine andere Frist genannt. Der AN gewährt (pro eingesetzter Person) bei Erstabruf eine kostenneutrale Einarbeitungszeit von im Regelfall 5% des Abrufvolumens, um die Anforderungen und Prozesse der BA kennen zu lernen. Die Leistung ist in einem sicherheitsrelevanten Bereich zu erbringen. Ebenso sind die zu erbringenden Tätigkeiten als sicherheitsempfindlich bewertet. Alle im Produktionsbereich eingesetzten externen Mitarbeiter müssen daher bereits zum Beginn des Leistungszeitraumes über eine gültige, von der BA durchgeführte und abgeschlossene erweiterte Sicherheitsüberprüfung nach § 9 SÜG (Ü2) verfügen. Diese muss bei jedem Mitarbeiter vorliegen und bereits zum Beginn des Leistungszeitraumes erfolgreich abgeschlossen sein. (Ebenso dürfen auch während des Leistungszeitraumes nur Personen tätig werden, die bereits über eine von der BA durchgeführte, abgeschlossene erweiterte SÜG- Prüfung verfügen.) Personen ohne eine entsprechende Sicherheitsüberprüfung dürfen nicht eingesetzt werden. Lediglich in den Vorumgebungen sind Arbeiten bis zum Abschluss der Sicherheitsüberprüfung möglich.
8 Umfang und Dauer der Leistung
8.1 Vertragslaufzeit, Leistungszeitraum,
Kündigungsoptionen
Die Vertragslaufzeit beginnt ab Zuschlagserteilung. Die Leistungen der vorlaufenden Transition (s. Kapitel 7.1) beginnen ebenfalls mit Zuschlagserteilung und enden mit der fachlichen Abnahme der vorlaufenden Transition. Die Erbringung der Managed Service Leistungen (s. Kapitel 5) beginnt sodann ab dem Tag nach
Seite 66 von insgesamt 81 Seiten
[Seite 67]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
der fachlichen Abnahme der vorlaufenden Transition, frühestens jedoch zum 01.06.2027 und endet nach Ablauf von 48 Monaten (Leistungszeitraum 2), gleichzeitig mit der Vertragslaufzeit. Für die BA besteht die Option, den Vertrag jährlich mit einer Frist von 3 Monaten zum Jahresende nach dem 2. und 3. Vertragsjahr zu kündigen. Die ersten Abrufe erfolgen voraussichtlich umgehend nach Zuschlagserteilung. Leistungen, welche innerhalb der Vertragslaufzeit abgerufen werden, sind auch nach Vertragsende zu erbringen. Für sie gelten dieselben Vertragsbedingungen.
8.2 Transitionsphasen
Sofern ein neuer AN den Zuschlag erhält, sind ab Zuschlag zunächst die Leistungen gemäß Kapitel 7.1 zu erbringen, sodass im Anschluss, ab dem Tag nach der fachlichen Abnahme die Leistungen des Managed Service vollumfänglich vom AN erbracht werden. Sofern der Vorgänger erneut den Zuschlag erhalten sollte, beginnt der Leistungszeitraum ab Zuschlag mit den Leistungen des Managed Service. Die Leistungen des Exitmanagements (s. Kapitel 7.3), die optional während der Vertragslaufzeit abgerufen werden, sind erst nach dem Abschluss des Managed Service zu den vertraglichen Bedingungen, zu erbringen.
8.3 Release- und Meilensteinplanung
Ein Entwurf der Release- und Meilensteinplanung findet sich als Anlage Nr. 5 zu dieser LB.
8.4 Ort und Zeiten der Leistungserbringung / Servicezeit /
Rufbereitschaft
8.4.1 Allgemeines Die Leistung ist grundsätzlich remote zu erbringen. Vor-Ort-Tätigkeiten in den Räumen der BA an den Standorten in Nürnberg/Fürth sind ebenfalls bei Bedarf möglich und werden mit dem AN im Detail besprochen. Die Hausordnung der BA (siehe Anlage 1 zur Leistungsbeschreibung) ist vom AN zwingend zu beachten und durch die zum Einsatz kommenden MA zu unterzeichnen. Die BA behält sich vor, für die Kontaktpersonen und zum Einsatz kommenden MA des AN eine Sicherheitsüberprüfung durchzuführen. Remote-Arbeit ist möglich, solange die Qualität der Leistungserbringung hierunter nicht leidet. Dabei ist zu beachten, dass eine vorherige Zustimmung der BA zur Remotearbeit im konkreten Fall über den Ansprechpartner des AN zu erfolgen hat. Sollten sich die Remote-Tätigkeiten jedoch nicht bewähren bzw. gibt es die Gefahr von Serviceeinbrüchen, so muss der AN entsprechend die Tätigkeiten vor Ort verstärken. Gleiches gilt, wenn die Zusammenarbeit zwischen BA und dem Managed-Service-Team nicht den Anforderungen der BA entspricht. Die Möglichkeit des Remote-Zugangs per VDI-Plattform wird dem AN von der BA bereitgestellt. Die für die Remotearbeit erforderliche technische Ausstattung ist durch den AN zur Verfügung zu stellen, eine gesonderte Vergütung hierfür erfolgt nicht. In Zeiträumen, bei welchen beispielsweise die VDI-Plattform nicht zur Verfügung steht bzw. Arbeit außerhalb der Servicezeiten der E-AKTE anfällt, z. B. im Rahmen einer Programmversionsversorgung, kann im Ausnahmefall, temporär für diesen Zeitraum, für Teile des Managed-Service-Teams ein PC der BA in den Räumlichkeiten der BA genutzt werden. Der AN stellt vorab sicher, dass alle Vorgaben der BA für Remote-Tätigkeiten gemäß Kapitel 10.7 und Anlage 3 vollumfänglich erfüllt sind. Bei den Leistungen ist durch den AN sicher zu stellen, dass bei Verbindungsstörungen oder Aktivitäten, die nicht remote durchgeführt werden können, eine kurzfristige Übernahme und Gewährleistung der Leistungserbringung (bei den Betriebsleistungen üblicherweise innerhalb einer Stunde) in den Räumen der BA erfolgen muss.
Seite 67 von insgesamt 81 Seiten
[Seite 68]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Die Anwesenheit eines oder mehrerer Ansprechpartner des AN während der Servicezeit der E-AKTE (s. Kapitel 5.12) vor Ort ist nicht erforderlich. Der AN regelt die Anwesenheit bzw. die Vertretung in eigener Zuständigkeit. Abweichungen von diesen Regelungen sind mit der BA abzustimmen.
8.4.2 Service- und Rufbereitschaftszeiten Der AN beachtet bei der Ausführung seiner Leistungen die vorgegebenen Zeiten des bedienten Betriebs der E-AKTE (s. Kapitel 5.12) und den allgemeinen Vorgaben. Die Zeiten der Leistungserbringung werden in Servicezeit 1 und 2 (im Folgenden »SZ1«und »SZ2«) unterteilt. Innerhalb dieser Zeiten wird die Rufbereitschaft des AN vorausgesetzt; wobei Leistungen innerhalb der SZ2 nur auf Anfrage durch die BA und mit einer Mindestvorlaufzeit von 3 Arbeitswochen zu erbringen sind.
| Leistung | Tag | Zeitraum | Anmerkung | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Servicezeit 1 (SZ1; remote/vor Ort) | Mo – Do | 6:30 Uhr – 18:00 Uhr | Nicht an Feiertagen gem. Kapitel 13 | ||||||||
| Fr | 6:30 Uhr – 16:00 Uhr | ||||||||||
| Servicezeit 2 (SZ2; remote/vor Ort, je nach Bedarf kann auch Rufbereitschaft ausreichend sein) | Fr | 16:01 Uhr – 00:00 Uhr | 3-9 Wochenenden/Kalenderjahr: Die Programmversion ist zu unterstützen und abzunehmen. | ||||||||
| Sa, So | 6:30 Uhr – 22:00 Uhr |
Tabelle 11: Zeiten der Leistungserbringung
Außerhalb der Servicezeiten 1 und 2 werden keine Rufbereitschaftszeiten vorgegeben. Der AN hält sich an entsprechende Vorgaben der BA. Leistungen des AN, die den Betrieb einschränken könnten, sind der BA unverzüglich bekanntzugeben. Er entscheidet bei zu erwartenden Einschränkungen hinsichtlich Tätigkeiten, die die Vorumgebung betreffen, eigenständig, ob und wann die Leistungen durchgeführt werden. Bei Tätigkeiten, die die Produktion betreffen, stellt er der BA Lösungsmöglichkeiten vor. Die Entscheidung liegt anschließend bei der BA. Zusätzliche erforderliche Einsätze werden als optionale Leistungen wie in Kapitel 7.4 »Ergänzende Dienstleistungen« beschrieben, abgerufen und vergütet. Hierbei kann es sich beispielsweise um Unterstützung bei IT-Notfällen (K-Fall, s. Kapitel 4.2.2) handeln.
8.5 Flexibilisierung des Leistungsumfangs
Die Umsetzung der Leistungen sieht grundsätzlich eine flexible Aufgabendurchführung vor. Die Nutzung formaler Änderungsverfahren soll auf ein unbedingt notwendiges Niveau begrenzt bleiben. Die Notwendigkeit eines formalen Änderungsverfahren bleibt vorgesehen. Die Zielsetzung der BA ist es, die zu erwartenden; auftretenden Leistungsschwankungen soweit möglich ohne Änderungsverlangen und ohne Mehrkosten abzufedern. Eine Veränderung im vereinbarten Leistungsumfang kann vom AN und der BA in der Vertragslaufzeit beantragt werden. Das Änderungsbegehren mit konkreter Beschreibung ist spätestens eine Woche vor dem nächsten Monatsmeeting (s. Kapitel 5.6.3) in Textform darzustellen und wird grundsätzlich zunächst im Monatsmeeting besprochen und das weitere Vorgehen an dieser Stelle beschlossen. In den operativen Besprechungen des Betriebsteams kann das Änderungsbegehren (vor-)besprochen werden, um beispielsweise einen gemeinsamen Vorschlag einzubringen. Das primäre Ziel der partnerschaftlichen Zusammenarbeit ist eine einvernehmliche Verständigung auf die Umsetzung des Änderungsbegehrens ohne formalen
Seite 68 von insgesamt 81 Seiten
[Seite 69]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Änderungsprozess. Der formale Prozess bleibt aber als finales Instrument erhalten. Sollte keine Einigung erzielt werden können, definiert das Eskalationsgremium (s. Kapitel 5.6.5) das weitere Vorgehen. Der AN beschreibt dazu mögliche Konsequenzen bzw. Auswirkungen einer angeforderten Leistungsveränderung. Eine Leistungsanpassung kann sowohl erweiternder oder/als auch reduzierender Natur sein, in beiden Fällen gelten die gleichen Abläufe. Bei rückläufigen Leistungsmengen kann die BA eine Kompensation durch Mehrtätigkeiten an anderer Stelle ablehnen und stattdessen eine anteilige Reduzierung der monatlichen Kosten verlangen. Eine Grenze findet dieses Vorgehen dann, wenn diese hinzukommenden Tätigkeiten für den AN unzumutbar wären (z. B. es werden zur Durchführung oder Umsetzung neuer Tätigkeiten bislang nicht bereitgestellte Skills (z. B. Expertenskills) benötigt).
Abbildung 2 Grundverständnis Veränderungsmanagement
Folgende Regelungen im Umfeld der Leistungsanpassung sind vorgesehen:
8.5.1 Änderungen im Vertragsverlauf Die BA kann jederzeit mittels einer Auftragsänderung Änderungen am Umfang der Services vornehmen, indem sie den hier definierten Leistungsumfang modifiziert. Sie räumt dem AN eine angemessene Zeit ein, um sich auf die Änderungen einzustellen und stimmt Termine, zu denen die Änderungen wirksam werden, rechtzeitig mit ihm ab.
8.5.2 Spontane Umpriorisierungen Durch das flexible Vorgehensmodell sind sich AN und BA einig, operative Leistungsschwankungen zuerst durch Umpriorisierungen abzufangen. Die Umpriorisierungen werden zunächst zwischen BA und AN abgestimmt, vereinbart und diese Vereinbarung in Textform (z. B. per E-Mail) festgehalten. Dies soll primär kurzfristige Spitzen abfangen, ohne die Stabilität des Services zu gefährden. Sollte sich im Weiteren erweisen, dass die ursprüngliche Planung vom tatsächlichen IST deutlich auseinanderfällt und für mindestens 3 Monate fortlaufend anhalten wird, und darüber hinaus keine Kompensation (z. B. durch Wegfall anderer Tätigkeiten) möglich ist, kommt dieses Verfahren an die Grenzen und bedingt eine Verständigung mit anderen Modellen. Sollte sich keine Verständigung zwischen den beiden Seiten ergeben, so sind die Tätigkeiten zunächst durchzuführen, parallel wird der Sachverhalt dem Steuerungskreis als Eskalationsgremium (s. Kapitel 5.6.5) übergeben. Die Entscheidung des Steuerungskreises
Seite 69 von insgesamt 81 Seiten
[Seite 70]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
gilt dann als neue Vorgabe. Wichtig ist der BA an dieser Stelle, dass zunächst die vereinbarte Monatspauschale eingehalten werden kann.
8.5.3 Planbare Umpriorisierungen Im Monatsmeeting (s. Kapitel 5.6.3) werden vorgesehene bzw. absehbare Entwicklungen angesprochen und die daraus möglichen Konsequenzen abgeleitet und abgestimmt. Der AN überprüft die Konsequenzen auf seine Leistungsgrenzen und gibt der BA dazu eine kurzfristige Rückmeldung. Auch hier wird zunächst davon ausgegangen, dass die vereinbarte Monatspauschale eingehalten werden kann. Der AN erhält die notwendigen Informationen für seine Planungen möglichst frühzeitig und vollständig, um seinerseits zu belastbaren Abschätzungen zu kommen. Sollten diese Einschätzungen später korrigiert werden müssen, weil die ursprünglichen Informationen lückenhaft bzw. unvollständig waren, so ist eine Neuplanung möglich.
8.5.4 Ausgleich von operativen Leistungsschwankungen Die bisherigen Erfahrungen haben gezeigt, dass eine völlige Gleichverteilung von Leistungen im Jahresverlauf nicht erwartet werden kann. Neben Spitzenzeiten (z. B. bei termingebundenen Beauftragungen) gibt es auch lastarme Zeiten, die eine zeitliche Kompensation von Leistungsspitzen ermöglichen. Operative Schwankungen sind durch den AN selbständig zu einem Ausgleich zu nutzen. Innerhalb des vorgegebenen Leistungsumfangs regelt der AN dies in eigener Zuständigkeit, die BA ist vorab zu informieren. Dies entlastet den AN aber nicht von der Einhaltung der Kennzahlen, der Sicherstellung der Stabilität des Betriebs oder von Aufgabenumsetzungen, die in diesem Zeitraum abgeschlossen werden sollen.
8.5.5 Ausgleich von mittelfristigen Leistungsschwankungen Auf Basis der durchschnittlichen Leistung über den Leistungszeitraum wird eine flexible Leistungsumfangsober-/-untergrenze (flexible Leistungsumfangsgrenze) von 10% festgelegt, die ein flexibles Agieren innerhalb dieser Grenzen zulässt. Dieses Vorgehen ist dafür vorgesehen, Schwankungen in der operativen Leistungserbringung zu managen. Sollte sich jedoch zeigen, dass …
• diese Schwellen in zwei aufeinanderfolgenden Kalendermonaten wiederholt erreicht bzw. über- oder unterschritten werden • und die gemeinsame Prognose bzw. Planungen weiterhin keine Veränderung erwarten lässt … wird ein Änderungsverlangen gestellt.
8.5.6 Änderungsverlangen
8.5.6.1 Allgemeine Änderungsverlangen Die BA behält sich vor, zusätzliche werkvertragliche Leistungen mittels eines Änderungsverlangens zu beauftragen. Zur Anwendung kommt ein entsprechendes Anforderungsdokument. Die zusätzlichen Leistungen dürfen nur beauftragt werden, soweit sie in sachlichem Zusammenhang mit dem Vertragsgegenstand stehen, der Gesamtcharakter des Vertrages nicht verändert wird und die vergaberechtlichen Voraussetzungen für Auftragsänderungen während der Vertragslaufzeit erfüllt sind. Neue Releases von Produkten und Tools, die im Rahmen des Managed Service E-AKTE eingesetzt werden, stellen keine Änderungen am Service dar. Der vereinbarte Service ist auch für diese Releases zu erbringen.
Seite 70 von insgesamt 81 Seiten
[Seite 71]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Dazu konsultiert die BA den AN mit einer detaillierten Beschreibung der zu erbringenden Leistung in Textform (»Anforderungsdokument«). Aus dieser Konsultation ist schließlich ersichtlich, ob der AN in der Lage ist, die beabsichtigten Werkleistungen zum Pauschalfestpreis auszuführen. Wenn dies der Fall ist, hat der AN das Angebot schriftlich einzureichen. Die Art des Dokumentes (z.B. Konzept, Protokoll) richtet sich nach Umfang und Menge der jeweils zu erbringenden Leistungen. Es wird von der BA erstellt und enthält grundsätzlich folgende Angaben:
• Beginn der Leistungserbringung • detaillierte Beschreibung der Leistung • Zieltermin für die Umsetzung • Zeitvorgaben und Meilensteine • Darstellung der Mitarbeit der BA • Test- und Abnahmemodalitäten • Qualitäts- und Abnahmekriterien Das Anforderungsdokument wird an den dauerhaften Ansprechpartner (s. Kapitel 9.1) des AN schriftlich übergeben. Der Termin für die Abgabe wird bei Übergabe des Anforderungsdokuments nach Art und Umfang des Auftrags festgelegt und beträgt zwischen 10 und 30 Arbeitstagen. Auf Basis des Anforderungsdokuments erstellt der AN eine verbindliche Aufwandsabschätzung. Diese hat grundsätzlich folgende Inhalte aufzuweisen:
• grundsätzlicher Lösungsweg (Konzept, Mittel und Methoden der Umsetzung) • Gesamtpreis • Benennung von eingesetzten Subunternehmern (soweit zutreffend) • Mitwirkungspflichten der BA • Festlegung und Bestätigung der Zeitschiene • Anforderungsabdeckung (im Kontext des Test-Managements) Die Auftragserteilung erfolgt durch die BA in der Regel innerhalb von 15 Arbeitstagen nach dem Abgabetermin des Angebots. Der AN beginnt die Leistungserbringung spätestens 10 Arbeitstage nach Beauftragung, sofern im Anforderungsdokument nichts anderes vereinbart wird. Das Instrument des Änderungsverlangens kann zudem beispielweise in den folgenden Fällen genutzt werden:
• Die notwendigen Leistungen haben die flexible Vertragsgrenze wiederholt überschritten/unterschritten und der Bedarf zur Definition einer Leistungsanpassung ist erkannt worden. • Die notwendige Leistung muss in größeren Teilen anders bzw. neu definiert werden, beispielsweise aufgrund von neu hinzugekommenen Leistungsanteilen.
8.5.6.2 Änderungsverlangen bei notwendigen Änderungen an der E-AKTE Die BA behält sich außerdem vor, während der Vertragslaufzeit (s. Kapitel 8.1) zusätzliche werkvertragliche Leistungen zu beauftragen, soweit diese aufgrund nach Zuschlag eintretender oder bekanntwerdender gesetzlicher, behördlicher oder regulatorischer Änderungen erforderlich werden und infolgedessen Anpassungen des Quellcodes oder der Funktionalität der E-AKTE notwendig sind. Der AN ist verpflichtet, auf Anforderung der BA ein Angebot über Art, Umfang, Aufwand, Termine und Vergütung der erforderlichen Anpassungsleistungen gemäß Vorgaben des Kapitels 8.5.6.1 vorzulegen. Die Beauftragung erfolgt ausschließlich nach schriftlicher
Seite 71 von insgesamt 81 Seiten
[Seite 72]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Freigabe des jeweiligen Änderungsverlangens durch die BA, z. B. im Rahmen einer Auftragsänderung.
8.5.6.3 Abnahme von Werkleistungen Die vom AN zu erbringenden Werkleistungen werden von der BA jeweils schriftlich fachlich abgenommen. Die fachliche Abnahme der Werkleistungen setzt voraus, dass der AN den Abschluss der entsprechenden Leistung schriftlich erklärt und die jeweils erforderlichen Nachweise beifügt (Bereitstellung zur fachlichen Abnahme). Der AN ist für den rechtzeitigen Eingang der Fertigstellerklärung an den fachlichen Ansprechpartner der BA nachweispflichtig. Zum Zeitpunkt der Bereitstellung müssen zur schriftlichen fachlichen Abnahme die Voraussetzungen erfüllt sein. Der abgestimmte Termin für die jeweilige Bereitstellung zur fachlichen Abnahme durch den AN wird nach Zuschlagserteilung zwischen Auftraggeber und Auftragnehmer schriftlich vereinbart. Grundlage hierfür bildet die vereinbarte Zeitschiene. Der AN hat sicherzustellen, dass alle für den ordnungsgemäßen Übergang erforderlichen und allgemein üblichen Maßnahmen den gestellten Anforderungen der BA entspricht. Die fachliche Abnahme erfolgt, wenn die zwischen AN und BA vereinbarten fachlichen Abnahmekriterien erfolgreich bestanden sind. Mängel werden in den jeweiligen fachlichen Abnahmeprotokollen als Mängel festgehalten und vom AN im Rahmen seiner Verantwortung für Sach- und Rechtsmängel unverzüglich beseitigt, sofern nicht eine Frist für die Beseitigung zwischen der BA und dem AN vereinbart wurde. Das jeweilige fachliche Abnahmeprotokoll mit den darin aufgeführten Mängeln gilt gleichzeitig als Anzeige des Mangels an den AN. Die fachliche Abnahmeerklärung erfolgt durch den Fachbereich der BA. Voraussetzung für eine fachliche Abnahme der Leistungen ist die Anzahl der Mängel je Störungsklasse. Durch die BA erfolgt die Abnahme, wenn der Gegenstand der fachlichen Abnahme keinen (0) Mangel der Störungsklasse 1, höchstens zwei (2) Mängel der Störungsklasse 2 und höchstens fünf (5) Mängel der Störungsklasse 3 aufweist und auch die sonstigen Anforderungen gemäß Kapitel 5.10 erfüllt bleiben. Die Mängel werden in der fachlichen Abnahmeerklärung als Mängel festgehalten und vom AN unverzüglich beseitigt, sofern nicht eine Frist für die Beseitigung vereinbart wurde. Im Falle einer Nichtabnahme durch die BA wird dem AN eine angemessene Frist zur Mängelbeseitigung und ein neuer Termin für die Bereitstellung zur fachlichen Abnahme gesetzt. Details werden im jeweiligen Anforderungsdokument beschrieben.
9 Vertragsabwicklung
9.1 Allgemeines
9.1.1 Ansprechpartner Für die Auftragsabwicklung muss der BA ein dauerhafter Ansprechpartner des AN, sowie ein entscheidungsbefugter Stellvertreter zur Verfügung stehen. Dieser muss an Arbeitstagen (s. Kapitel 13) mit einem der gängigen Kommunikationsmittel (E-Mail, Festnetz- bzw. Mobiltelefon ohne kostenpflichtige Sonderrufnummern) zur Servicezeit 1 (s. Kapitel 8.4.2) für die BA erreichbar sein.
Dieser Mitarbeiter des AN hat die Aufgabe, ständiger Ansprechpartner für die BA zur Abwicklung des Vertrages zu sein. Alle Fragen, Abstimmungen, Vorgespräche und Weisungen etc. im Rahmen der Vertragsabwicklung laufen über diesen Mitarbeiter. Er muss diesbezüglich
Seite 72 von insgesamt 81 Seiten
[Seite 73]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
formal und inhaltlich entscheidungsbefugt sein. Des Weiteren muss die namentliche Benennung des Ansprechpartners sowie des entscheidungsbefugten Stellvertreters direkt nach Zuschlagserteilung erfolgen.
10 Datenschutz / Auftragsverarbeitung
Bei diesem Auftrag ist nicht ausgeschlossen, dass der Auftragnehmer Kenntnis von personenbezogenen Daten im Sinne von Art. 4 Nr. 1 Datenschutzgrundverordnung (DS-GVO), Sozialdaten im Sinne von § 67 Abs. 2 Zehntes Buch Sozialgesetzbuch (SGB X) sowie Betriebs- und Geschäftsgeheimnissen i. S. d. § 35 Abs. 4 Erstes Buch Sozialgesetzbuch (SGB I) erlangt. Besonders schützenswerte Daten (z. B. ärztliche Gutachten) sind hiervon ausgeschlossen.
10.1 Gegenstand und Dauer der Verarbeitung
10.1.1 Gegenstand der Verarbeitung Gegenstand des Auftrags zum Datenumgang ist die Durchführung folgender Aufgaben durch den Auftragnehmer: Pflege und Weiterentwicklung des BA-spezifischen Codes des Basisdienstes E-AKTE mittels Managed Service.
10.1.2 Dauer der Verarbeitung Die Dauer der Verarbeitung wird auf das notwendige Maß beschränkt und endet spätestens mit Ende des Leistungszeitraums (siehe Kapitel 8.1).
10.2 Konkretisierung des Auftragsinhalts
10.2.1 Art und Zweck der vorgesehenen Verarbeitung von Daten
Art der Verarbeitung
Die Verarbeitung ist folgender Art: Erfassen, Organisation, Speicherung, Vertragsmäßige Verwendung, Löschung von Daten.
Zweck der Verarbeitung
Die Verarbeitung dient folgendem Zweck: siehe Kapitel 4 der Leistungsbeschreibung
10.2.2 Art der Daten Gegenstand der Verarbeitung personenbezogener Daten sind folgende Datenarten/- kategorien (Aufzählung/Beschreibung der Datenkategorien):
• Personenstammdaten (Name, Vorname, Kd.-Nr., BG-Nr., Geburtsdatum, Geburtsort, Anschrift, Familienstand, Staatsangehörigkeit, BankverbindungDaten zur Vermittlung/Integration in Arbeit und Beratung (Lebenslauf, Nachweis über Abschlüsse, Angaben zu Kenntnissen und Fähigkeiten)
• Kommunikationsdaten (z.B. Telefonnummer, E-Mail-Adresse - freiwillige und nicht freiwillige Angaben von MA der BA), beispielsweise durch Einsicht in das Outlook- Verzeichnis der Bundesagentur für Arbeit oder auf sonstige Weise im Rahmen der Erbringung der Dienstleistung.
• Sozialdaten (z. B. Gesundheits-, Einkommensdaten und Daten zur Leistungsgewährung) bei der Arbeit an der E-AKTE, im Rahmen von Fehlerbehebungen an der Software kann es notwendig sein, auf Echtdaten aus der
Seite 73 von insgesamt 81 Seiten
[Seite 74]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
Produktion (Metadaten, Sozialdaten) zuzugreifen. Diese Dateien werden im Vorfeld durch die BA anonymisiert werden. Fehler werden nur im Auftrag der BA durch den AN analysiert und ggf. behoben.
10.2.3 Kategorien betroffener Personen Die Kategorien der durch die Verarbeitung betroffenen Personen umfassen:
• Mitarbeiter • Ansprechpartner
10.3 Kundinnen und Kunden der BAtechnische und
organisatorische Maßnahmen und deren Kontrolle
Der Auftragnehmer hat die Umsetzung der im Vorfeld der Auftragsvergabe dargelegten und erforderlichen technischen und organisatorischen Maßnahmen vor Beginn der Verarbeitung, insbesondere hinsichtlich der konkreten Auftragsdurchführung zu dokumentieren und dem Auftraggeber zur Prüfung zu übergeben. Bei Akzeptanz durch den Auftraggeber werden die dokumentierten Maßnahmen Grundlage des Auftrags. Die Vertragsparteien vereinbaren die in der Anlage 3 zu dieser Leistungsbeschreibung nieder-gelegten konkreten technischen und organisatorischen Sicherheitsmaßnahmen. Die Anlage 3 ist Gegenstand dieser Leistungsbeschreibung. Soweit die Prüfung/ein Audit des Auftraggebers einen Anpassungsbedarf ergibt, ist dieser einvernehmlich umzusetzen.
Der Auftragnehmer hat die Sicherheit gem. Artt. 28 Abs. 3 lit. c), 32 DS-GVO insbesondere in Verbindung mit Art. 5 Abs. 1, Abs. 2 DS-GVO herzustellen. Insgesamt handelt es sich bei den zu treffenden Maßnahmen um Maßnahmen der Datensicherheit und zur Gewährleistung eines dem Risiko angemessenen Schutzniveaus hinsichtlich der Vertraulichkeit, der Integrität, der Verfügbarkeit sowie der Belastbarkeit der Systeme. Dabei sind der Stand der Technik, die Implementierungskosten und die Art, der Umfang und die Zwecke der Verarbeitung sowie die unterschiedliche Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen im Sinne von Art. 32 Abs. 1 DS-GVO zu berücksichtigen [Einzelheiten in Anlage 3].
Technische und organisatorische Maßnahmen unterliegen dem technischen Fortschritt und der Weiterentwicklung. Insoweit ist es dem Auftragnehmer gestattet, alternative adäquate Maßnahmen umzusetzen. Dabei darf das Sicherheitsniveau der in der Anlage 3 festgelegten Maßnahmen nicht unterschritten werden. Wesentliche Änderungen sind zu dokumentieren.
10.4 Berichtigung, Einschränkung und Löschung von
Daten
Soweit vom Leistungsumfang umfasst, sind Löschkonzept, Recht auf Vergessenwerden, Berichtigung, Datenportabilität und Auskunft nach dokumentierter Weisung des Auftraggebers unmittelbar durch den Auftragnehmer sicherzustellen.
10.5 Beachtung zwingender gesetzlicher Pflichten durch
den Auftragnehmer
Qualitätssicherung und sonstige Pflichten des Auftragnehmers
Der Auftragnehmer hat zusätzlich zu der Einhaltung der Regelungen dieses Auftrags gesetzliche Pflichten gemäß Art. 28 bis 33 DS-GVO; insofern gewährleistet er insbesondere die Einhaltung folgender Vorgaben:
Seite 74 von insgesamt 81 Seiten
[Seite 75]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
a) Die Umsetzung und Einhaltung aller für diesen Auftrag erforderlichen technischen und organisatorischen Maßnahmen gemäß Artt. 28 Abs. 3 S. 2 lit. c), 32 DS-GVO [Einzelheiten in Anlage 3] b) Nachweisbarkeit der getroffenen technischen und organisatorischen Maßnahmen gegenüber dem Auftraggeber im Rahmen seiner Kontrollbefugnisse nach § … des Vertrages.
10.6 Mitteilung bei Verstößen des Auftragnehmers
Der Auftragnehmer unterstützt den Auftraggeber bei der Einhaltung der in Artt. 32 bis 36 DS- GVO genannten Pflichten zur Sicherheit personenbezogener Daten, Meldepflichten bei Datenpannen, Datenschutz-Folgenabschätzungen und vorherige Konsultationen. Hierzu gehören u. a.
a) die Unterstützung des Auftraggebers für dessen Datenschutz-Folgenabschätzung b) die Unterstützung des Auftraggebers im Rahmen vorheriger Konsultationen mit der Aufsichtsbehörde.
10.7 Regelungen bei Remote-Zugriff und Tele-/Heimarbeit
Die BA behält sich vor, bei Bedarf die Erbringung von Dienstleistungen mit Remote-Zugriff anzufordern. Der Einsatzort wird im Rahmen des jeweiligen Abrufs festgelegt.
Nachfolgend sind die Regelungen zu Remote-Zugriff beschrieben:
Soweit die Dienstleistungen in den BA-Räumlichkeiten erbracht werden, erfolgt dies auf Basis der von der BA bereitgestellten Umgebungen vor Ort in Nürnberg. Auf Anforderung der BA kann unter Berücksichtigung folgender Rahmenbedingungen die Dienstleistung remote erfolgen.
MA des AN, die im Rahmen der Leistungserbringung die Leistungen über einen Remote- Zugriff außerhalb der Geschäftsräume der BA erbringen, tragen eine besondere datenschutzrelevante Verantwortung. Sie verpflichten sich zur Einhaltung der geltenden Datenschutzbestimmungen
Der Remote-Zugriff bzw. die Tele-/Heimarbeit darf ausschließlich im Hoheitsgebiet der Bundesrepublik Deutschland, in einem Mitgliedstaat der Europäischen Union oder in einem anderen Vertragsstaat im Sinne des Abkommens über den Europäischen Wirtschaftsraum stattfinden. Dies gilt auch für etwaige weitere Auftragsverarbeiter.
Der Remotearbeitsplatz muss den datenschutzrechtlichen Anforderungen entsprechen. Voraussetzung ist, dass die Arbeitsbedingungen des Remotearbeitsplatzes mit einem separaten, verschließbaren Arbeitsbereich vergleichbar sind. Ein gesondertes Zimmer zur ausschließlichen Nutzung für die Remotearbeit ist dabei nicht erforderlich, vielmehr muss ein getrennter, verschließbarer Bereich zum Arbeiten zur Verfügung stehen.
Der Transport dienstlicher Unterlagen muss in einem verschlossenen Behältnis (z.B. verschließbarer „Pilotenkoffer“) erfolgen. Außerhalb der Aufgabenerledigung sind dienstliche Unterlagen in der Arbeitsstätte verschlossen und gegen den Zugriff Dritter, dies gilt auch für Familienangehörige und Haushaltsangehörige, gesichert aufzubewahren.
Fehlausdrucke dürfen nicht im Hausmüll entsorgt werden, sondern sind in der Dienststelle einer datenschutzkonformen Vernichtung durch Einwurf in die entsprechenden Behälter zuzuführen.
Seite 75 von insgesamt 81 Seiten
[Seite 76]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
11 Schriftliche Aufgabenstellung
Die Leistung des Bieters wird im Zuge von schriftlichen Aufgabenstellungen geprüft. Die Bearbeitung der Aufgaben hat schriftlich zu erfolgen bzw. sind diese schriftlich umzusetzen.
Eine detaillierte Aufgabenbeschreibung inklusive aller weiteren relevanten Angaben wie z. B. Bewertungshorizont findet sich im Dokument »E.5 Bewertungsmatrix Leistung«.
12 Verifizierende Bieterpräsentation
Die BA behält sich vor, die schriftliche Ausarbeitung der Aufgabenstellungen bzw. Leistungskriterien im Rahmen einer verifizierenden Präsentation vorstellen zu lassen. Hält die BA Bieterpräsentationen für notwendig, werden alle geeigneten Bieter hierzu aufgefordert. Die Präsentation wird in diesem Fall nicht gesondert bewertet. Das Ergebnis der Bewertung ist Bestandteil der Wertungsentscheidung (Wirtschaftlichkeitsberechnung anhand der einfachen Richtwertmethode). Die Erwartungshaltung der BA ist dem Dokument E.5, »Bewertungsmatrix Leistung« zu entnehmen. Die Präsentation muss sich inhaltlich auf die vom Bieter beantworteten Fachaufgaben / Leistungskriterien beziehen. Die Bewertung der Präsentation erfolgt in Form einer Nachbewertung der schriftlichen Angebote. Die Bewertung richtet sich maßgeblich danach, inwieweit ein Bieter die geforderten Inhalte der BA in verständlicher und schlüssiger Weise beschreiben, erläutern und insgesamt darstellen kann. Auch die Beantwortung der Fragen des BA-seitigen Bewerter-Gremiums fließt in die Bewertung mit ein. Bitte beachten Sie: Es dürfen ausschließlich Inhalte des schriftlichen Angebots präsentiert werden! Die Präsentation darüber hinausgehender Inhalte führt zum Ausschluss. Um die Vergleichbarkeit zwischen Bietern sicherzustellen, werden folgende Rahmenbedingungen für die bewertende Präsentation vorgegeben:
• Zeitrahmen: 150 Min. (davon ca. 10 Min. Einleitung / Firmenpräsentation; ca. 90 Min. Lösungspräsentation; ca. 50 Min. Beantwortung von Fragen) • Es wird eine PowerPoint-Präsentation mit Schaubildern sowie ausführliche Demonstrationen im Testsystem des AN erwartet. • Die technische Ausstattung für die Präsentation selbst (Beamer, etc.) stellt die BA zur Verfügung. • Sonstige Ausstattung ist vom Bieter mitzubringen (Laptop etc.). • Die Aufforderung erfolgt voraussichtlich im Dezember 2026 mit einem Vorlauf von mind. 1 Woche. • Die Präsentation findet in den Räumlichkeiten der BA in Nürnberg (Örtlichkeiten und genaue Termine werden noch mitgeteilt) statt. • Für die Präsentation wird seitens der BA weder eine Vergütung, noch eine Aufwandsentschädigung entrichtet
Seite 76 von insgesamt 81 Seiten
[Seite 77]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
13 Abkürzungen / Glossar
| Abkürzung/Begriff | Bemerkung | ||||
|---|---|---|---|---|---|
| Abnahme-Zyklus | Zwischen den Parteien vereinbarter Zeitraum, innerhalb dessen definierte Arbeitspakete umgesetzt und anschließend einer Qualitätsprüfung unterzogen werden. | ||||
| ALLEGRO | Durch ALLEGRO wird der Leistungssachbearbeitung und den | ||||
| angrenzenden Gebieten innerhalb des Wirkungsbereichs SGB | |||||
| II ein Anwendungssystem bereitgestellt, das Arbeitsprozesse | |||||
| durch (Teil-) Automatisierung unterstützt. | |||||
| AMSEL | AutoMatisches Tool zur SicherhEitsüberprüfung von AppLikationen ist ein Werkzeug zur Unterstützung der Bedrohungsanalyse. Dieses Tool zeigt den SIA-Fragenkatalog und durch Beantwortung der darin enthaltenen Fragen werden die für die Anwendung relevanten Bedrohungen und Maßnahmen ermittelt | ||||
| AN | Auftragnehmer | ||||
| Arbeitstag | Montag bis Freitag, außer an bundeseinheitlichen und an nicht bundeseinheitlichen Feiertagen am Erfüllungsort (Nürnberg), sowie am 24. Dezember und 31. Dezember. | ||||
| BA | Bundesagentur für Arbeit | ||||
| BACF | BA-Client- Framework | ||||
| Barrierefreiheit | Gesetzliche Vorgaben gemäß → BITV 2.0 | ||||
| Barrierefreiheitstests | Diese Tests prüfen, ob das System für Menschen mit Behinderungen gem. → BITV 2.0 zugänglich und nutzbar ist. | ||||
| »Below the radar«-Coding | Unter dem Begriff »Below the radar«-Coding laufende | ||||
| Programmierarbeiten umfassen oft wichtige, unscheinbare | |||||
| Aufgaben wie den Abbau technischer Schulden, Wartung, | |||||
| Sicherheitsupdates und Refactoring, die außerhalb der | |||||
| eigentlichen Produktentwicklung stattfinden. Diese Aufgaben | |||||
| sind für die langfristige Stabilität unerlässlich, werden aber vom | |||||
| Management, das sich auf die sichtbaren Produktmerkmale | |||||
| konzentriert, oft übersehen. | |||||
| Betriebliche Abnahmetests | Diese Tests überprüfen, ob das System den betrieblichen Anforderungen entspricht und bereit für den Produktiveinsatz ist. | ||||
| BG-Nr. | Nummer der Bedarfsgemeinschaft | ||||
| BITV 2.0 | Barrierefreie Informationstechnik-Verordnung | ||||
| BSI | Bundesamtes für Sicherheit in der Informationstechnik | ||||
| DB | Datenbank | ||||
| Deployment | Deployment im IT-Bereich bezeichnet die Bereitstellung, | ||||
| Installation und Konfiguration von Softwareanwendungen in | |||||
| einer Zielumgebung (z.B. Produktionsserver). |
Seite 77 von insgesamt 81 Seiten
[Seite 78]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| DIANA | DIANA ist der BA-intern verwendete Oberbegriff für die Verfahren zur "geregelten" Datenübertragung. Im Kontext E- AKTE kommt das Produkt Synchrony Transfer zum Einsatz | ||||
|---|---|---|---|---|---|
| Dienststelle | Sammelbegriff für alle Lokationen der BA u. a. | ||||
| Arbeitsagenturen und Geschäftsstellen. | |||||
| DS-GVO | Datenschutz-Grundverordnung | ||||
| DST | Produktionsumgebung der Anwender | ||||
| E-AKTE | Dokumentenmanagement der BA in den Rechtskreisen SGB3, SGB 2 und Familienkasse | ||||
| E-ARCHIV | Das elektronische Archiv ist ein Basisdienst und dient der | ||||
| rechts -und revisionssicheren Speicherung von Dokumenten | |||||
| und Signaturen | |||||
| ESB | Enterprise Service Bus | ||||
| ESM | Enterprise Service Monitoring | ||||
| EVB-IT | Ergänzende Vertragsbedingungen für die Beschaffung von IT- Leistungen | ||||
| Failover | Automatischer Prozess in der IT, der bei Ausfall eines | ||||
| Primärsystems (Server, Netzwerk) nahtlos auf ein redundantes | |||||
| Standby-System umschaltet. Er dient der Hochverfügbarkeit | |||||
| (High Availability), minimiert Ausfallzeiten und sichert die | |||||
| Geschäftskontinuität ohne manuelles Eingreifen. | |||||
| FBA | Führungsakademie der BA | ||||
| Feiertage | Als Feiertage gelten bundeseinheitliche und nicht | ||||
| bundeseinheitliche Feiertage am Erfüllungsort (Nürnberg), | |||||
| sowie der 24. Dezember und der 31. Dezember. | |||||
| Finding | Ergebnisse/Befunde | ||||
| Freelancer | Freiberuflich Tätiger, der weder bei dem Generalunternehmer | ||||
| noch bei einem der Subunternehmer Arbeitnehmer ist. | |||||
| Geschäftsprozesstests | Hier werden die Geschäftsprozesse und -anforderungen getestet, um sicherzustellen, dass das System die Anforderungen der Geschäftsprozesse erfüllt. | ||||
| GuI | Graphical user Interface | ||||
| Happy-Path-Tests | Diese Tests simulieren den normalen, erwarteten Ablauf des Systems, um sicherzustellen, dass es wie erwartet funktioniert. | ||||
| Health Checks | Diese Tests überwachen den Zustand und die Leistung des | ||||
| Systems im laufenden Betrieb, um sicherzustellen, dass es | |||||
| korrekt funktioniert und keine Probleme auftritt | |||||
| Hochverfügbarkeit (High Availability) | Fähigkeit eines IT-Systems, trotz Komponentenausfällen oder Störungen einen nahezu unterbrechungsfreien Betrieb zu gewährleisten. Dies wird durch Redundanz, Fehlertoleranz und automatische Failover-Mechanismen erreicht, um Ausfallzeiten zu minimieren. Ein gängiger Standard ist eine Verfügbarkeit von ≥99,9%, was eine Ausfallzeit von weniger als einer Stunde pro Jahr bedeutet. |
Seite 78 von insgesamt 81 Seiten
[Seite 79]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| IAB | Institut für Arbeitsmarkt- und Berufsforschung | ||||
|---|---|---|---|---|---|
| ILO | Kernarbeitsnormen der Internationalen Arbeitsorganisation | ||||
| Invaris | Dokumentenerzeugung | ||||
| IT-GeSiko | IT-Gesamtsicherheitskonzept der BA | ||||
| ITIL | IT Infrastructure Library | ||||
| Kd.-Nr. | Kundennummer | ||||
| Komponententest | Nachdem die Unit-Tests erfolgreich waren, werden die | ||||
| Komponenten getestet, um sicherzustellen, dass sie wie | |||||
| erwartet funktionieren | |||||
| KPI | Key Performance Indicator, dt. Leistungskennzahl, eine messbare Größe, die den Erfolg von Unternehmensaktivitäten, Prozessen oder Zielerreichungen abbildet. Sie helfen, Fortschritte zu bewerten und datenbasierte Entscheidungen zur Optimierung zu treffen. Definition: Ein guter KPI ist spezifisch, messbar, erreichbar, relevant und zeitgebunden (SMART) | ||||
| Last- und Performancetests | Diese Tests messen die Leistung und Belastbarkeit des | ||||
| Systems unter verschiedenen Lasten und Bedingungen. | |||||
| LBK | Leistungs-Basis-Komponenten | ||||
| Leistungsübergabepunkt | Ein Leistungsübergabepunkt (oft als »Übergabepunkt« oder | ||||
| »Handover Point« bezeichnet) ist der definierte Punkt, an dem | |||||
| die Verantwortung für eine Leistung, eine Dienstleistung oder | |||||
| ein Produkt vom AN oder Auftragnehmer auf den Kunden oder | |||||
| Auftraggeber übergeht. | |||||
| LoC | Lines of Code | ||||
| MDM | Mobile Devise Management | ||||
| NTPL | Netztopologieplan | ||||
| PeP | Public Electronic Procurement | ||||
| Penetrationtests | Hier werden die Sicherheitsmaßnahmen des Systems getestet, indem versucht wird, das System zu hacken oder zu kompromittieren. | ||||
| PI Planning | „Program Increment Planning“, ein zentraler Bestandteil des | ||||
| Scaled Agile Frameworks (SAFe). Es handelt sich um eine | |||||
| Veranstaltung, bei der alle beteiligten Teams eines agilen | |||||
| Produktbereichs zusammenkommen, um die Ziele, Prioritäten | |||||
| und den Umfang für das nächste Program Increment | |||||
| festzulegen. | |||||
| Produktionsdaten | Alle echten personenbezogenen oder geschäftskritischen Daten der BA. Deren Nutzung im Test ist strengstens untersagt und löst Pönalen aus. | ||||
| PS | Personenstunde, 8 Personenstunden ergeben 1 → PT | ||||
| PT | Personentag, bestehend aus 8 → PS. | ||||
| Quality Gate | Definierter Kontrollpunkt im Projektmanagement, der als | ||||
| Entscheidungstor (Gate) fungiert, um Zwischenergebnisse vor |
Seite 79 von insgesamt 81 Seiten
[Seite 80]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| dem Übergang in die nächste Phase zu validieren. Quality | |||||
|---|---|---|---|---|---|
| Gates stellen sicher, dass definierte Qualitätsstandards erfüllt | |||||
| sind, um Fehler frühzeitig zu erkennen, Risiken zu minimieren | |||||
| und die Produktqualität nachhaltig zu steigern. | |||||
| Regressionstests | Diese Tests werden durchgeführt, um sicherzustellen, dass Änderungen oder Updates am System keine neuen Fehler oder Probleme verursachen. | ||||
| Remote | Leistungen unter Inanspruchnahme von technischen | ||||
| Einrichtungen zur Fernkommunikation von einem Standort | |||||
| außerhalb des Einsatzortes der Leistungen. | |||||
| RIM | Regionalen Infrastrukturmanagements | ||||
| Root-Cause-Analyse | Die Root-Cause-Analyse gehört zum Qualitätsmanagement: | ||||
| Nach dem Auftreten eines Problems, einer Frage oder eines | |||||
| Vorfalls wird nach der Ursache gesucht. | |||||
| RPA | Robotic Process Automation | ||||
| Rückverfolgbarkeitsmatrix | → Traceability Matrix | ||||
| SERA | disziplinübergreifender Softwareentwicklungsrahmenprozess | ||||
| SETF | Test-Factory-Plan (Softwareentwicklung Testfactory) | ||||
| SGB | Sozialgesetzbuch | ||||
| SLA | Service Level Agreement | ||||
| Slave | Ein "Incident Ticket Slave" ist ein IT-Support-Ticket, das funktional an ein übergeordnetes Master-Ticket gebunden ist. | ||||
| StGB | Strafgesetzbuch | ||||
| STEP | Das zentrale Stammdatensystem der BA. Das beinhaltet die Erfassung und Pflege von Betriebe- und Personendaten. STEP fungiert als zentrales System für fast alle BA-IT-Verfahren, die Stammdaten zu ihrer Aufgabenerfüllung benötigen. | ||||
| SUD-Test (Sicherheits-, Usability- | Diese Tests bewerten die Sicherheit, Benutzerfreundlichkeit | ||||
| und Datenschutztest) | und den Datenschutz des Systems. | ||||
| SV | Sozialversicherung | ||||
| SW | Software | ||||
| SWEP | Softwareentwicklungsprozess | ||||
| Systemintegrationstest | Diese Tests überprüfen, ob die verschiedenen Komponenten | ||||
| und Module eines Systems korrekt miteinander interagieren | |||||
| und funktionieren. | |||||
| Systemverbundtest | Hier werden die Integrationen und Schnittstellen zwischen verschiedenen Systemen getestet, um sicherzustellen, dass sie reibungslos kommunizieren. | ||||
| TDST | Schulungsumgebung für die Anwenderschulungen | ||||
| TEBIT | elektronisches Bestellsystem der BA zur Abwicklung von Bestellungen | ||||
| TOM | Technische und organisatorische Maßnahmen |
Seite 80 von insgesamt 81 Seiten
[Seite 81]
[e-Vergabe-Nr.: 12-26-00305] – [Managed Service E-AKTE 2027]
| Traceability-Matrix | Tabellarische Darstellung, die Beziehungen zwischen Projektanforderungen, Designelementen, Code und Testfällen visualisiert. Sie stellt sicher, dass alle Anforderungen umgesetzt und geprüft wurden. Typische Anwendungsbeispiele sind die Verknüpfung von Anforderungen mit Testfällen (Forward Traceability) oder die Prüfung, ob Tests ursprünglichen Anforderungen entsprechen (Backward Traceability). Synonyme sind »Requirements Traceability Matrix« (»RTM«), »Anforderungsrückverfolgbarkeitsmatrix« oder »Trace Matrix«. | ||||
|---|---|---|---|---|---|
| UAC | Usability Accessibility Center | ||||
| UC4 | Batchsteuerung (in BA – nur vom Betrieb verwendet) | ||||
| Unit-Test | Diese Tests werden auf der Ebene einzelner Code-Module | ||||
| oder -Einheiten durchgeführt, um sicherzustellen, dass jede | |||||
| Einheit korrekt funktioniert. | |||||
| UfAB | Unterlage für Ausschreibung und Bewertung von IT-Leistungen | ||||
| UI | User Interface (Benutzerschnittstelle) | ||||
| Umgehungslösung | → Workaround | ||||
| VERBIS | Das zentrale Vermittlungs-, Beratungs- und | ||||
| Informationssystem der Bundesagentur für Arbeit und bildet | |||||
| u.a. zusammen mit der Internet-Anwendung JOBBÖRSE das | |||||
| IT-Verfahren VAM (Virtueller Arbeitsmarkt). | |||||
| vSiko | IT-Sicherheitskonzept der BA (Verfahrens-Sicherheitskonzept) | ||||
| WebDAV | Web-based Distributed Authoring and Versioning | ||||
| Workaround | Eine temporäre Lösung für einen Fehler, die den fachlichen Prozess ermöglicht, ohne signifikanten manuellen Mehraufwand zu erzeugen. Workarounds für Fehler der Klasse 1 und 2 verhindern grundsätzlich die formale Abnahme, es sei denn, die BA stimmt ausdrücklich schriftlich zu. | ||||
| ZAV | Zentrale Auslands- und Fachvermittlung |
Seite 81 von insgesamt 81 Seiten