I 22 - Anlage_15_Softwareentwicklung_Reportingplattform_V.0.9.pdf

Konzeption, Implementierung und Weiterentwicklung einer Reporting-Plattform für die WIBank

Extrahierter Dokumenttext · Stand: 14.09.2026, 15:38 (Europe/Berlin)

Herkunft: www.deutsche-evergabe.de

Tabellen, Layout und Zeichen können bei der Extraktion abweichen. Maßgeblich ist die Originaldatei.

Originaldatei öffnen

[Seite 1]

Anlage 15

Softwareentwicklung

zum Rahmenvertrag vom TT.MM.JJJJ

zwischen

Landesbank Hessen-Thüringen Girozentrale

Neue Mainzer Straße 52 - 58

60311 Frankfurt

- nachfolgend Helaba oder Auftraggeber genannt -

und

[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]

[Adresszeile 2: Straße des Auftragnehmers]

[Adresszeile 3: PLZ und Stadt des Auftragnehmers]

- nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer genannt -

– zusammen auch „Vertragspartner“, „Vertragsparteien“

oder „Parteien“ genannt

Version 0.9

[Seite 2]

Anlage 15 – Softwareentwicklung

Abkürzungsverzeichnis

AbkürzungErklärung
BAITBankaufsichtliche Anforderungen an die IT
BITV 2.0Barrierefreie-Informationstechnik-Verordnung 2.0
BSIBundesamt für Sicherheit in der Informationstechnik
CERT-BundComputer Emergency Response Team des BSI
CSSCascading Style Sheets
DORADigital Operational Resilience Act
DRYDon't Repeat Yourself
DSGVODatenschutz-Grundverordnung
GoBDGrundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Bü- chern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff
HTMLHypertext Markup Language
HTTPHypertext Transfer Protocol
IKTInformations- und Kommunikationstechnik
ISO/IECInternationale Organisation für Normung/Internationale Elektrotechnische Kommission
KISSKeep It Simple, Stupid
KPIKey Performance Indicator
MaRiskMindestanforderungen an das Risikomanagement
OCIOpen Container Initiative
OWASPOpen Web Application Security Project
S-CertSecurity Certificate
SLAService Level Agreement
SBOMSoftware Bill of Materials (Software-Stückliste)
SOLIDSingle Responsibility, Open/Closed, Liskov Substitution, Interface Segre- gation, Dependency Inversion
URLUniform Resource Locator
W3CWorld Wide Web Consortium

Seite 2 von 13

[Seite 3]

Anlage 15 – Softwareentwicklung

INHALTSVERZEICHNIS

Abkürzungsverzeichnis ....................................................................................................... 2

1 Gegenstand dieser Anlage .................................................................................... 4

2 Anforderungsmanagementprozess ...................................................................... 4

3 Anforderungen an die Softwareentwicklung ........................................................ 5 3.1 Entwicklungsumgebung ........................................................................................... 5 3.2 Standards des Auftraggebers ................................................................................... 5 3.3 Coding-Richtlinien .................................................................................................... 5 3.4 Sicherheitsanforderungen ........................................................................................ 7 3.5 Fortbildungsmaßnahmen........................................................................................ 11 3.6 Quellcodeverwaltung .............................................................................................. 11 3.7 Dokumentationsanforderungen .............................................................................. 12

4 Überprüfung und Kontrolle ................................................................................. 13

Seite 3 von 13

[Seite 4]

Anlage 15 – Softwareentwicklung

1 Gegenstand dieser Anlage

Gegenstand dieser Anlage ist die Festlegung der Anforderungen, die der Auftrag- nehmer bei der Erbringung von Softwareentwicklungsleistungen für den Auftragge- ber zu erfüllen hat.

Werden durch den Auftragnehmer Anpassungen technischer und/oder fachlicher Art an produktiven IT-Systemen des Auftraggebers vorgenommen oder bereitgestellt (entwickelt), so finden die regulatorischen Vorgaben MaRisk, BAIT und DORA sowie für rechnungsrelevante Systeme der GoBD Anwendung.

Die Nutzungsrechte in Bezug auf die im Rahmen dieser Anlage zu erstellende Soft- ware ergeben sich ausschließlich aus den maßgeblichen Bestimmungen des Rah- menvertrags. (siehe Ziffer 5 Nutzungsrechte). Diese Anlage sowie darauf beru- hende Beauftragungen (Einzelverträge), einschließlich Abrufe oder Erstellungs- scheine, enthalten hierzu keine abweichenden oder ergänzenden Bestimmungen.

2 Anforderungsmanagementprozess

Die Parteien haben in Anlage 18 Anforderungsmanagement ein standardisiertes Verfahren für die Abwicklung von Änderungsanforderungen vereinbart. Softwareent- wicklungen erfolgen ausschließlich gemäß diesem Prozess.

Die Installation der vom Auftragnehmer entwickelten Software in die Produktionsum- gebung des Auftraggebers ist erst nach erfolgreichem Abschluss eines Abnahme- und Freigabeverfahrens gemäß Anhang 19.4 Release und Deployment Manage- ment zulässig.

Dies beinhaltet insbesondere die Prüfung und Bestätigung durch den Auftraggeber, dass die Software den vereinbarten funktionalen und qualitativen Anforderungen entspricht. Für jede Softwareentwicklung werden daher vor Beginn der Umsetzung Abnahmekriterien festgelegt. Die Einhaltung dieser Kriterien ist vom Auftragnehmer nachzuweisen.

Seite 4 von 13

[Seite 5]

Anlage 15 – Softwareentwicklung

3 Anforderungen an die Softwareentwicklung

3.1 Entwicklungsumgebung

(1) Die Entwicklung von Software erfolgt ausschließlich in der Entwicklungsumge- bung des Auftraggebers. Die nachfolgenden Anforderungen sind vom Auftrag- nehmer verbindlich einzuhalten.

(2) Durch den Auftragnehmer sind angemessene Prozesse und Vorgaben in Bezug auf sichere Entwicklungsumgebungen inklusive sicherer Entwicklungsverfah- ren zu etablieren.

(3) Die Entwicklungs- und Testumgebung (ungesteuerte Umgebung) ist strikt von Abnahme- und Produktionsumgebung (gesteuerter Umgebung) zu trennen.

(4) Alle Zugriffe und Änderungen in der Entwicklungsumgebung sind durch den Auftragnehmer zu protokollieren und regelmäßig auf Unregelmäßigkeiten zu überprüfen. Die Protokolle sind dem Auftraggeber auf Anforderung zur Verfü- gung zu stellen.

(5) Der Auftragnehmer stellt sicher, dass Entwicklungsaktivitäten keine Auswirkun- gen auf die Produktionsumgebung haben. Insbesondere dürfen Tests keine produktiven Daten enthalten oder auf produktive Systeme zugreifen.

(6) Die Entwicklungsfunktionen sind so zu gestalten, dass keine Änderungen in Test-, Abnahme- oder Produktionsumgebungen aus der Entwicklungsumge- bung heraus vorgenommen werden können.

(7) Der Auftragnehmer gewährt dem Auftraggeber auf dessen Anforderung hin Zu- griff auf die Entwicklungsumgebung ausschließlich im erforderlichen Umfang nach dem Need-to-know-Prinzip. Jeder Zugriff des Auftraggebers ist zu doku- mentieren und zu protokollieren. Ein administrativer Zugriff ist ausgeschlossen, sofern nicht ausdrücklich schriftlich vereinbart.

3.2 Standards des Auftraggebers

(1) Der Auftraggeber behält sich vor dem Auftragnehmer seine Entwicklungs-, Test- und Qualitätsstandards für die Softwareentwicklung zur Verfügung zu stel- len. Der Auftragnehmer verpflichtet sich, ab dem Zeitpunkt der Bereitstellung sicherzustellen, dass alle Softwareentwicklungsaktivitäten gemäß diesen Stan- dards durchgeführt werden. Änderungen oder Aktualisierungen der Standards werden dem Auftragnehmer unverzüglich mitgeteilt und sind ab Zugang ver- bindlich umzusetzen. Die Einhaltung der Standards ist vom Auftragnehmer zu dokumentieren und dem Auftraggeber auf Anforderung nachzuweisen.

3.3 Coding-Richtlinien

(1) Der Auftragnehmer verpflichtet sich, verbindliche Coding-Richtlinien zu erstel- len, regelmäßig zu aktualisieren und während der gesamten Laufzeit des Rah-

Seite 5 von 13

[Seite 6]

Anlage 15 – Softwareentwicklung

menvertrags einzuhalten. Die Richtlinien müssen Anforderungen an Code-Qua- lität, Lesbarkeit, Wartbarkeit, Sicherheitsstandards und Dokumentation enthal- ten.

(2) Die Coding-Richtlinien umfassen mindestens folgende Aspekte:

• Einhaltung von Sicherheitsstandards gemäß OWASP, ISO/IEC 27001 sowie relevanten branchenspezifischen Vorschriften, • Anwendung etablierter Best Practices, wie DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) und SOLID-Prinzipien, • Strukturierung des Codes nach Clean Code-Prinzipien, • Vorgaben für Verzeichnisstrukturen und Dateinamen der im Rahmen der Programmierung erstellten Artefakte, • Namenskonventionen, • Vorgaben für die Strukturierung von Code und den Einsatz von Kontroll- strukturen (Bedingungen, Schleifen), sofern sie von anerkannten Best Practice Standards abweichen, • Vorgaben für Kommentierung und Dokumentation innerhalb des Codes. (3) Die Richtlinien müssen auch Vorgaben enthalten, die sich auf das Design der Anwendung und die Erfüllung übergeordneter nicht-funktionaler Anforderungen beziehen, insbesondere:

• Hinweise auf besonders ressourcenintensive bzw. -schonende Berech- nungs- oder Datenzugriffsverfahren, • Nutzung von Abstraktionsschichten beim Zugriff auf Datenbanken, • Nutzung von Logging-Mechanismen, • Festlegung von fachlichen Konstanten und Look-Up-Mechanismen, • Festlegung des Fehlerhandlings, • Entkopplung von Komponenten, • Validierung und Bereinigung von Benutzereingaben (User-Input). (4) Zur Gewährleistung eines einheitlichen Coding-Stils stellt der Auftragnehmer innerhalb der Entwicklungsumgebung eine geeignete Konfiguration bereit und setzt entsprechende Werkzeuge, beispielweise zur statischen Codeanalyse, ein.

(5) Sämtlicher entwickelte Quellcode und zugehörige Konfigurationsdateien sind vom Auftragnehmer in einem für den Auftraggeber zugänglichen Sourcecode- Repository mit Versionsverwaltung und Rechtesteuerung abzulegen.

(6) Zur Sicherung der Integrität von Code und Ressourcen sowie zum Schutz vor Manipulationen oder unbeabsichtigten Änderungen der Ablauflogik sind vom Auftragnehmer geeignete Source Code Control Systeme einzusetzen.

(7) Die Coding-Richtlinien sind vom Auftragnehmer regelmäßig auf Aktualität zu prüfen und bei Bedarf anzupassen, da sich anerkannte Standards und auf- sichtsrechtliche Richtlinien im Bereich der Softwareentwicklung und -sicherheit ständig weiterentwickeln.

(8) Der Auftragnehmer stellt sicher, dass alle an der Softwareentwicklung beteilig- ten Personen entsprechend geschult werden und die Richtlinien verbindlich an- wenden.

Seite 6 von 13

[Seite 7]

Anlage 15 – Softwareentwicklung

(9) Zur Überprüfung der Einhaltung führt der Auftragnehmer regelmäßige (mindes- tens einmal jährlich) Audits durch. Die Ergebnisse sind zu dokumentieren und dem Auftraggeber auf Anforderung vorzulegen.

(10) Abweichungen von den Coding-Richtlinien sind dem Auftraggeber unverzüglich mitzuteilen und in Abstimmung mit diesem zu korrigieren.

3.4 Sicherheitsanforderungen

(1) Bei der Entwicklung oder Anpassung von Software auf Anforderung des Auf- traggebers ist die durchgängige Berücksichtigung der Informationssicherheit über den gesamten Entwicklungsprozess hinweg von wesentlicher Bedeutung. Die nachstehenden Sicherheitsprüfungen und -maßnahmen sind vom Auftrag- nehmer daher verpflichtend durchzuführen.

(2) Der Auftragnehmer erstellt Nachweise der durchgeführten Sicherheitsprüfun- gen und -maßnahmen. Die Dokumentation umfasst die Ergebnisse der Prüfun- gen sowie die daraus abgeleiteten Folgemaßnahmen. Die Nachweise sind dem Auftraggeber in dem zwischen den Parteien vereinbarten Format und innerhalb der vereinbarten Frist (in der Regel vor Auslieferung der entwickelten Software) bereitzustellen.

(3) Wird im Rahmen der Sicherheitsprüfungen ein sicherheitsrelevanter Mangel festgestellt, informiert der Auftragnehmer den Auftraggeber innerhalb von 24 Stunden schriftlich. Geeignete Korrekturmaßnahmen sind innerhalb von 48 Stunden nach Meldung umzusetzen, sofern keine abweichende Frist einver- nehmlich vereinbart wurde.

(4) Die Sicherheitsprüfungen und -maßnahmen sind regelmäßig an den aktuellen Stand der Technik anzupassen. Änderungen, die zur weiteren Optimierung der Sicherheitsprüfungen und -maßnahmen führen, werden vom Auftragnehmer zeitnah und in Abstimmung mit dem Auftraggeber umgesetzt.

(5) Auf Anforderung des Auftraggebers setzt der Auftragnehmer zusätzliche Si- cherheitsprüfungen und -maßnahmen um. Solche Anforderungen sind über das vertraglich vereinbarte Änderungsverfahren (siehe Ziffer 11 des Rahmenver- trags) zu adressieren.

Seite 7 von 13

[Seite 8]

Anlage 15 – Softwareentwicklung

3.4.1 Konformitätstests (1) Der Auftragnehmer verpflichtet sich, im Rahmen der Softwareentwicklung die Einhaltung der relevanten technischen, branchenspezifischen und regulatori- schen Standards sowie gesetzlichen Vorschriften zu prüfen und sicherzustel- len. Dazu zählen insbesondere:

• ISO/IEC-Normen (z. B. ISO/IEC 27001 für IT-Sicherheit), • Webstandards gemäß W3C (z. B. HTML/CSS-Konformität), • Datenschutzvorgaben (z. B. DSGVO), • Barrierefreiheitsrichtlinien (z. B. BITV 2.0).

3.4.2 Externe Bibliotheken (1) Externe Bibliotheken dürfen ausschließlich aus vertrauenswürdigen Quellen be- zogen werden. Vor deren Einsatz ist die Integrität sicherzustellen. Es dürfen keine Komponenten verwendet werden, die vom Hersteller nicht mehr gewartet oder als unsicher eingestuft wurden.

(2) Unbekannte externe Komponenten, deren Sicherheit nicht durch etablierte und anerkannte Peer-Reviews oder vergleichbare Methoden sichergestellt werden kann, müssen auf Schwachstellen und auf potenzielle Konflikte überprüft wer- den.

3.4.3 Sicherheitsfunktionstests (1) Mindestens die folgenden Sicherheitsfunktionen sind während der Entwicklung nach gängigen Verfahren zu testen und zu dokumentieren:

• Authentifizierungs- und Authentisierungsmechanismen, • Zugriffsschutz und Schutz sensibler Daten, • Protokollierung kritischer Ereignisse, • Sicherheitskonfigurationen (z.B. Schutz vor Default-Passwörtern), • Verhalten bei fehlerhaften Eingaben (Input Validation), • Verhalten von Schnittstellen bei Eingang fehlerhafter Daten (unexpected Input). (2) Bei Entwicklung von webbasierten IT-Systemen, die aus dem Internet erreich- bar sind, müssen zusätzlich die folgenden Funktionen getestet werden:

• Mechanismen zum Session Management, • Schutz vor Verarbeitung manipulierter Daten über Schnittstellen (z.B. im Rahmen von Cross-Site-Scripting), • Absicherung von Implementierungsobjekten (z. B. Dateien, Ordner), so- fern diese von außen zugänglich sind (Unsichere direkte Objektreferen- zen), • Umgang mit manipulierten HTTP-Requests, • Absicherung von Weiterleitungen und Ziel-URLs, • Schutz vor Einspielung manipulierter Daten als Teil von Kommandos oder einer Abfrage (Injection-Angiffe).

Seite 8 von 13

[Seite 9]

Anlage 15 – Softwareentwicklung

3.4.4 Softwaretests und Qualitätssicherungsmaßnahmen (1) Der Auftragnehmer führt während des gesamten Entwicklungsprozesses regel- mäßige und systematische Softwaretests sowie Qualitätssicherungsmaßnah- men durch, um sicherzustellen, dass die Software nach dem Stand der Technik möglichst frei von Schadsoftware und bekannten Schwachstellen ist.

(2) Folgenden Maßnahmen sind verpflichtend:

a. Code Reviews

Jede Codeänderung ist durch eine zweite qualifizierte Person zu prüfen (Vier-Augen-Prinzip). Die Reviews sind zu dokumentieren.

b. Statische Code-Analysen

Es ist ein marktübliches, fachlich anerkanntes Tool zur statischen Ana- lyse einzusetzen. Die Analyse ist für alle auszuliefernden Programmpa- kete durchzuführen und zu dokumentieren. Bei festgestellten Mängeln ist der Auftragnehmer zur Behebung verpflichtet.

c. Dynamische Analysen (Oberflächentests)

Automatisierte Laufzeittests sind mit einem anerkannten Tool durchzu- führen. Die Ergebnisse sind zu dokumentieren. Fehlerhafte Ergebnisse sind zu beheben.

d. Unit Tests

Für alle funktionalen Softwareeinheiten sind Unit Tests mit einem markt- üblichen Framework zu erstellen und durchzuführen. Die Tests müssen eine angemessene Testabdeckung sicherstellen. Fehlerhafte Funktiona- litäten sind zu korrigieren.

3.4.5 Software-Stückliste (SBOM) (1) Der Auftragnehmer verpflichtet sich, für jede entwickelte Software eine Soft- ware-Stückliste (SBOM - Software Bill of Materials) zu erstellen und fortlaufend zu pflegen.

(2) Die SBOM listet sämtliche zur Erstellung der Software verwendeten Kompo- nenten auf, einschließlich, aber nicht beschränkt auf Softwarepakete, Bibliothe- ken, Module, Frameworks und Plug-ins sowie deren Versionen, Lizenzen und Abhängigkeiten.

(3) Die SBOM ist in einem standardisierten und branchenüblichen Format bereit- zustellen. Sie muss folgende Informationen vollständig und nachvollziehbar ent- halten:

• Vollständige und genaue Informationen zu jeder Komponente, • Quellen der Komponenten, • Lizenztypen und Lizenzbedingungen jeder Komponente, • Versionsnummern und andere relevante Identifikationsdaten.

Seite 9 von 13

[Seite 10]

Anlage 15 – Softwareentwicklung

(4) Der Auftragnehmer stellt sicher, dass die SBOM stets aktuell ist und spätestens mit jedem Software-Release aktualisiert wird. Die aktuelle Version der SBOM ist dem Auftraggeber zeitgleich mit der Bereitstellung jedes neuen Software- Releases zu übergeben.

(5) Der Auftragnehmer verpflichtet sich, auf Anforderung des Auftraggebers, min- destens jedoch einmal jährlich, eine Überprüfung und Aktualisierung der SBOM vorzunehmen und dem Auftraggeber einen detaillierten Bericht über die Ände- rungen und Aktualisierungen vorzulegen.

(6) Die Pflicht zur Bereitstellung und Pflege der SBOM erstreckt sich über die ge- samte Dauer des Vertragsverhältnisses und gilt auch nach Beendigung der Softwareentwicklungsleistungen für alle während der Laufzeit des Rahmenver- trags gelieferten Softwarestände.

3.4.6 Quality Gate (1) Die Auslieferung einer Softwareentwicklung an den Auftraggeber erfolgt aus- schließlich, wenn die vom Auftraggeber definierten und freigegebenen Kriterien für Sicherheitsprüfungen und Qualitätssicherung vollständig erfüllt sind. Diese Kriterien bilden die verbindlichen Quality Gates für jede Software-Auslieferung.

(2) Aktuell umfassen die Quality Gates des Auftraggebers folgende Anforderungen:

• Code Reviews: Alle Code-Änderungen wurden einem dokumentierten Code-Review un- terzogen. • Statische Code-Analysen: Es liegen keine Meldungen mit dem Schweregrad „mittel“ oder „hoch“ vor. • Dynamische Analysen: Alle Oberflächentests wurden erfolgreich durchgeführt. • Unit Tests: Es liegen keine fehlgeschlagenen Unit Tests vor. (3) Die Einhaltung der Quality Gates ist durch den Auftragnehmer nachweislich zu dokumentieren. Die Dokumentation ist dem Auftraggeber mit jeder Auslieferung bereitzustellen und umfasst insbesondere die Ergebnisse der Prüfungen.

(4) Abweichungen von diesen Quality Gates sind in gegenseitigem Einvernehmen je Auslieferung möglich. Diese Abweichungen werden im Nachweis der Quali- tätssicherungsprüfungen und -maßnahmen durch den Auftragnehmer entspre- chend dokumentiert.

Seite 10 von 13

[Seite 11]

Anlage 15 – Softwareentwicklung

3.5 Fortbildungsmaßnahmen

(1) Der Auftragnehmer stellt sicher, dass seine Entwickler regelmäßig an geeigne- ten Fortbildungsmaßnahmen im Bereich der sicheren IT-Entwicklung teilneh- men. Diese Maßnahmen sollen dem aktuellen Stand der Technik und den je- weils geltenden Sicherheitsstandards entsprechen.

(2) Die Fortbildungsmaßnahmen sind so zu planen und durchzuführen, dass die vertraglich vereinbarten Leistungspflichten des Auftragnehmers nicht beein- trächtigt werden.

(3) Der Auftragnehmer dokumentiert die Teilnahme an relevanten Fortbildungs- maßnahmen in geeigneter Weise und legt dem Auftraggeber auf Anforderung entsprechende Nachweise vor.

(4) Die Kosten für anerkannte Fortbildungsmaßnahmen trägt grundsätzlich der Auf- tragnehmer.

(5) Auf Verlangen des Auftraggebers ist die Teilnahme ausgewählter Mitarbeiter des Auftragnehmers an vom Auftraggeber angebotenen Programmen zur Sen- sibilisierung für IKT-Sicherheit sowie an Schulungen zur digitalen operationalen Resilienz zu ermöglichen.

3.6 Quellcodeverwaltung

(1) Der Auftragnehmer verpflichtet sich, den Quellcode der entwickelten Software in einem geeigneten, marktüblichen und revisionssicheren Codeverwaltungs- system zu administrieren. Das eingesetzte System muss die Nachvollziehbar- keit aller Änderungen, die Verwaltung von Versionen sowie die Kontrolle von Zugriffsrechten ermöglichen.

(2) Der Auftragnehmer stellt sicher, dass jede produktiv genutzte Version der Soft- ware jederzeit aus dem gespeicherten Quellcode reproduzierbar und wieder- herstellbar ist. Die Versionsverwaltung ist durch ein Datensicherungskonzept abzusichern, das regelmäßige Backups und Wiederherstellungsmechanismen umfasst.

(3) Die Archivierung des Quellcodes sowie der zugehörigen technischen Doku- mentation erfolgt gemäß den jeweils geltenden gesetzlichen und aufsichtsrecht- lichen Anforderungen und Aufbewahrungsfristen.

(4) Auf Verlangen des Auftraggebers hat der Auftragnehmer den vollständigen Quellcode nebst zugehöriger Dokumentation innerhalb einer angemessenen Frist zugänglich zu machen und die erforderlichen Auskünfte zu erteilen. Der Auftraggeber ist berechtigt, die Einhaltung dieser Anforderungen jederzeit zu überprüfen oder durch Dritte prüfen zu lassen.

(5) Der Auftragnehmer verpflichtet sich, mindestens einmal jährlich eine systema- tische Überprüfung der Quellcodeverwaltung durchzuführen. Das Ergebnis ist in einem detaillierten Prüfprotokoll zu dokumentieren und dem Auftraggeber als Nachweis für die ordnungsgemäße Durchführung vorzulegen.

Seite 11 von 13

[Seite 12]

Anlage 15 – Softwareentwicklung

3.7 Dokumentationsanforderungen

(1) Der Auftragnehmer erstellt und pflegt für jede Softwareentwicklung eine umfas- sende Dokumentation auf der Grundlage der vom Auftraggeber vorgegebenen Templates.

(2) Die vom Auftragnehmer zu erstellende Software-Dokumentation, die zur ord- nungsgemäßen Erbringung von Softwareentwicklungsleistungen erforderlich ist, umfasst mindestens:

a. Technische Dokumentationen • Technische Spezifikationen und Architekturkonzept (DV-Konzept) • Schnittstellenbeschreibungen • Entwicklungs- und Umsetzungsdokumentationen • SBOM (Software Bill of Materials). b. Sicherheitsdokumentationen und -protokolle c. Betriebliche Dokumentationen • Betriebsführungshandbuch • Jobabläufe. d. Fachliche Dokumentationen • Benutzer- und Administrationshandbuch • Fachliches Berechtigungskonzept. (3) Der Auftragnehmer ist darüber hinaus für die laufende Pflege der Software-Do- kumentation verantwortlich, d.h. bei Änderungen an der Software durch den Auftragnehmer ist dieser verpflichtet die vorliegenden Dokumentationen, auf ihre Aktualität und Anwendbarkeit hin zu überprüfen und bei Bedarf anzupas- sen.

(4) Die Dokumentation ist vollständig und so verständlich auszugestalten, dass sie für einen sachverständigen Dritten in angemessener Zeit prüfbar bzw. nachvoll- ziehbar ist.

(5) Die Dokumentation ist zu versionieren und der Verfasser namentlich zu auszu- weisen.

(6) Die Dokumentation ist in deutscher Sprache zu verfassen, sofern nicht anders vereinbart.

(7) Die Übergabe der Dokumentation an den Auftraggeber muss gemäß dem ver- einbarten Deployment-Prozess (siehe Anhang 19.4 Release und Deployment Management) vor der Auslieferung der jeweiligen Softwareentwicklung erfol- gen.

Seite 12 von 13

[Seite 13]

Anlage 15 – Softwareentwicklung

4 Überprüfung und Kontrolle

(1) Der Auftraggeber hat das Recht den Entwicklungsprozess des Auftragnehmers sowie alle relevanten Umgebungen und implementierten Sicherheitsmaßnah- men zu überprüfen und Kontrollmaßnahmen durchzuführen. Dies beinhaltet auch die uneingeschränkte Zusammenarbeit des Auftragnehmers bei der Durchführung von Kontrollmaßnahmen, einschließlich Vor-Ort-Inspektionen und Audits, durch den Auftraggeber, durch zuständige Behörde oder durch be- auftragte Dritte.

(2) Der Auftragnehmer ist verpflichtet, dem Auftraggeber auf Verlangen alle erfor- derlichen Nachweise über die ordnungsgemäße Durchführung der Entwick- lungstätigkeiten und Sicherheitsmaßnahmen vorzulegen. Dies umfasst insbe- sondere technische Dokumentationen, Prüfprotokolle, Zertifizierungen und Au- ditberichte.

Seite 13 von 13

Alle Unterlagen dieser Ausschreibung