206008 - 2.1 - Los 1 - Leistungsbeschreibung.pdf

[Seite 1]

22.07.2026 i.d.F.v. Datum: 30.07.2026

Az: 10 233/00077

Leistungsbeschreibung

Thema: „Entwicklung und Wartung des DEHSt-Software-Development Kits zur Erstel- lung von Fachanwendungen für Vollzugsverfahren der DEHSt (Los 1)“

Umweltbundesamt Das Umweltbundesamt begrüßt die Verwendung von Referat Z 1.5 - Zentrale Vergabestelle Umweltfreundlichem Recyclingpapier.

[Seite 2]

Inhalt

1. Hintergrund und Problemstellung ................................................................... 3

1.1 Die DEHSt als Softwareentwicklungshaus .................................................... 3

2. Ziel und Gegenstand des Projektes ................................................................. 4

2.1 Überblick über wesentliche Beteiligte ......................................................... 4

3. Aufgabenstellung .......................................................................................... 6

3.1 Softwareentwicklung und -Wartung im Auftrag der DEHSt ............................. 6 3.1.1 Übergreifende Aufgaben in Entwicklungsprojekten ................................. 6 3.1.2 Störungsmanagement ........................................................................... 8 3.1.3 Eingesetzte Technologien und Ansätze ................................................... 9 3.1.4 Standards und Werkzeuge für die Softwareentwicklung ........................ 10 3.1.5 Betrieb von Test- und Entwicklungsumgebungen durch den AN ............. 11 3.1.6 Feature-Entwicklung im Downstream .................................................... 11 3.2 SDK-Weiterentwicklung, Wartung und -Management .................................. 11 3.2.1 Aufgaben des Auftragnehmers ............................................................. 12 3.2.2 Pflichten des Auftraggebers ................................................................. 13

4. Projektorganisation ..................................................................................... 14

4.1 Zeitplan ................................................................................................... 14 4.2 Besprechungen ........................................................................................ 14 4.3 Projektsprache ......................................................................................... 14

5. Anforderungen an das Angebot/die Leistungsausführung .............................. 15

5.1 Allgemeine Anforderungen an das Angebot................................................ 15 5.2 Anforderungen an die Leistungserbringung ............................................... 16 5.2.1 Allgemeine Anforderungen .................................................................. 16 5.3 Kostendarstellung .................................................................................... 16

6. Eignung des/der Auftragnehmers/in ............................................................. 17

7. Zuschlags-/Wertungskriterien ...................................................................... 17

Seite 2 von 17

[Seite 3]

1. Hintergrund und Problemstellung

Die DEHSt betreibt seit ca. 20 Jahren Ende-zu-Ende digitalisierte Fachverfahren. Zentrale Komponenten der eingesetzten IT-Landschaft der DEHSt befinden sich in einer Phase der Erneuerung. Die Anzahl der von der DEHSt zu entwickelnden Softwareartefakte wächst kon- tinuierlich an – Zeitpläne werden dadurch stetig enger und die Parallelisierung und Kom- plexität nimmt zu. Mehrere Altsysteme müssen zudem vollständig abgelöst werden.

Um Abhilfe zu schaffen, hat die DEHSt ein Software-Development-Kit (SDK) entwickelt, das aus Software und einer umfangreichen Dokumentation etwa für die Inbetriebnahme einer Test- und Integrationsumgebung besteht. Ziel des SDK ist dabei einerseits eine technolo- gische Erneuerung durchzuführen, andererseits die Entwicklungsgeschwindigkeit deutlich zu erhöhen bei gleichzeitiger Wahrung von Standards.

Das SDK stellt dabei Dokumentation, Software-Bibliotheken, mehrere eigenständige Dienste für die zentralisierte Steuerung (Workflowsteuerung) der Fachanwendungen sowie eine Basis- und eine Beispielanwendung bereit, die sich in die bestehende Software- und Prozesslandschaft der DEHSt integriert (also etwa bestehende Zentrale Dienste anspricht, die sog. „DEHSt-Plattform“).

Das SDK und die DEHSt-Plattform setzen auf eine Trennung von Frontend (Angular, NgRx, Material), Backend (Spring-Boot), verteilten Webservices und einer Build-Strecke in GitLab sowie einem skalierbaren Betrieb auf Containern-Basis (Docker Images auf RedHat OKD).

1.1 Die DEHSt als Softwareentwicklungshaus

Im Auftrag der DEHSt werden seit 20 Jahren Ende-zu-Ende digitalisierte Fachverfahren ent- wickelt und Prozesse in Software implementiert. Die in der Basisanwendung des SDK etab- lierten Verfahren haben sich bewährt. Dennoch gibt es weiter ungelöste Herausforderun- gen, die gemeinsam mit dem AN zu bewältigen sind. Insbesondere zu nennen ist die not- wendige Umsetzungsgeschwindigkeit von neuer Software auf einer bestehenden Basis aber mit einer jeweils neuen, komplexen Fachlichkeit in wenigen Monaten von Konzeption, Spezifikation bis zum Go-Live. Das erfordert ein tiefes Verständnis der vorhandenen Basis aber genauso Kreativität für neue Ideen und Exzellenz bei der Umsetzung seitens der DEHSt und der hier geforderten AN.

Seite 3 von 17

[Seite 4]

2. Ziel und Gegenstand des Projektes

Mit dieser Beschaffungsmaßnahme wird eine Rahmenvereinbarung ausgeschrieben, die eine Laufzeit von 4 Jahren umfasst. Die Rahmenvereinbarung kann zweimal um je ein Jahr verlängert werden.

Das Projekt soll die Entwicklung und Pflege des gesamten Software Development Kits (SDK) sowie die Entwicklung von darauf aufbauenden Fachanwendungen umfassen. Dabei unter- scheiden wir zwischen drei verwandten, aber parallelen Aufgabenbereichen:

1. Los 1: SDK-Wartung und -Management

2. Los 2: Neuentwicklung von Fachanwendungen

3. Los 3: Migration und Ablösung von Altsystemen

Für das SDK-Team gilt das Ziel, den Nutzen für die Sachbearbeitung zu Erhöhen aber ge- nauso, die Entwicklungsdauer der Entwicklerteams positiv zu beeinflussen (vgl. 1.1).

Für die Entwicklerteams muss es ein Ziel sein, basierend auf einer ausgearbeiteten Spezi- fikation, eine qualitativ hochwertige Anwendung in möglichst geringer Zeit zu entwickeln. Messbare Kennziffern sind für uns etwa die Anzahl der PT bis zur einer ersten startbaren Fachanwendung mit vollständigem Datenmodel.

Positiv bei allen Bietern zu bewerten sind daher Konzepte oder effektive oder kreative An- sätze für die Beschleunigung der Software-Entwicklung.

2.1 Überblick über wesentliche Beteiligte

SDK- Team (das sind Sie): Entwicklung und Wartung des SDKs, Auslieferung der weiterver- wendbaren Artefakte durch die Fachanwendungs-Entwickler-Teams, Community-Manage- ment, Hilfe für andere Entwickler-Teams bei der Integration und Entwicklung auf Basis von der von Ihnen gepflegten Dokumentation und best practices.

Kundin (DEHSt):

 Fachgebiet V 4.5 IT-Anwendungen der DEHSt (SDK und DEHSt-Plattform „Product Owner“): Definition der Anforderungen und Ziele des SDKs (und der DEHSt-Platt- form), die IT-Expert*innen in der DEHSt sind verantwortlich für das UBA-interne Pro- jektmanagement und die Abnahmetests.

Seite 4 von 17

[Seite 5]

 Fachgebiet V 2.7 Fachliches Datenmanagement und Qualitätssicherung der DEHSt („Product Owner“ der Fachanwendungen): Die fachlichen Expert*innen der DEHSt mit IT-Expertise sind für die Erstellung der Spezifikationen für die Fachanwendungen verantwortlich. Daraus ergeben sich bei Fachanwendungs-übergreifenden Anforde- rungen auch Anforderungen für das SDK, die mit V 4.5 abgestimmt werden. Über- prüfen die Fachanwendungen auf ihre Konformität mit den Spezifikationen und sind an den Abnahmetests beteiligt.

Andere wichtige Beteiligte und ihre Aufgaben:

 Fachanwendung-Entwickler-Teams (AN von Los 2 und 3): Entwicklung und Wartung der Fachanwendungen auf Basis des SDKs und der Vorgaben von V 2.7. Sie erstellen Auslieferungen von fertigen Docker Images für den Betrieb.

 Entwickler der DEHSt-Plattform (externer Dienstleister): Wartung der zentralisier- ten Dienste und anderer Softwarekomponenten (wie etwa den bestehenden Legacy- Fachanwendungen), Hilfe bei der Integration in die Plattform

 Hostingdienstleister/Betrieb (externer Dienstleister): Betrieb der DEHSt-Plattform und der Fachanwendungen in einer Abnahme- und einer Produktiv-Umgebung

Seite 5 von 17

[Seite 6]

3. Aufgabenstellung

3.1 Softwareentwicklung und -Wartung im Auftrag der DEHSt

3.1.1 Übergreifende Aufgaben in Entwicklungsprojekten

Obwohl die Entwicklungsaufgaben unterschiedliche Schwerpunkte (z.B. SDK-Entwicklung, Neuentwicklung oder Migrationsprojekte) haben werden, gibt es dennoch übergreifende Anforderungen, die von allen Teams erfüllt werden müssen.

Die Aufgaben aller Teams umfassen:

1. Technische Umsetzung: Das Team ist für die technische Umsetzung der Ziele und Anforderungen des Auftraggebers verantwortlich.

2. Qualitätssicherung und Fehlerbehebung inklusive:

a. Durchführung funktionaler, Integrations- und ggf. Lasttests

b. Zusätzlicher Einsatz automatisierter Verfahren für Tests (CI)

c. Dokumentation von Fehlern, Umsetzung von Fehlerbehebungen und Durch- führung von Regressionstests

3. Incident-Management: Nach Produktivsetzung der Software ist jedes Team ver- pflichtet, einen strukturierten Incident-Management-Prozess für Fehlerfälle bereit- zustellen. Dies umfasst die Erreichbarkeit über einen vereinbarten Kommunikati- onskanal, die Priorisierung, Fehleranalyse und Behebung und transparente und durchgängige Kommunikation während der Bearbeitung und der Dokumentation des Falles bei Abschluss. Es gelten hier die Details im Kapitel „Störungsmanage- ment“.

4. Wartung und Aktualisierung: Regelmäßige Überprüfung und Aktualisierung, um si- cherzustellen, dass die Anwendung auf dem neusten Stand ist und mit den not- wendigen Technologien und Plattformen kompatibel ist.

5. Aktualisierung der Software, sowie Build- & Test-Automatisierung inklusive

a. Aktualisierung der in der Fachanwendung (FA) enthaltenen, importierten Software (etwa die Basisanwendung aus dem SDK) auf die jeweils neuste Version

Seite 6 von 17

[Seite 7]

b. Einsatz automatisierter Verfahren für die Bereitstellung von Artefakten und Images (CI, CD), Einrichtung und Pflege von Build-Skripten, Container- Images oder Deployment-Pipelines für eine automatisierte Erstellung der Software-Artefakte und nachfolgenden Tests

6. Dokumentation:

a. Erstellung und Pflege einer technischen Dokumentation der umgesetzten fachlichen Anforderungen

b. Sicherstellung, dass die Dokumentation die spätere Inbetriebnahme, Instal- lation, Wartung und Weiterentwicklung ermöglicht

7. Sicherheitsüberprüfung: Automatisierte Überprüfung auf Sicherheitslücken und Schwachstellen durch statische Code-Analyse oder entsprechende KI-Agenten, um sicherzustellen, dass Softwareartefakte sicher und zuverlässig sind. Wichtig sind hierbei besonders die Kenntnis und Berücksichtigung von relevanten best prac- tices und IT-Sicherheitsvorgaben für Bundesbehörden wie dem „IT-Grundschutz“ vom Bundesamt für Sicherheit in der Informationstechnik (BSI). Die jeweils aktu- elle Version ist auf der Webseite des BSI abzurufen.

8. Barrierefreiheit: Behörden in Deutschland sind durch verschiedene rechtliche Vor- gaben verpflichtet, ihre Online-Angebote barrierefrei zu gestalten. Seit 2019 gilt die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0). Die darin enthaltenen Vorgaben sind in den Entwicklungsprojekten zu beachten und die Umsetzung mit dem Auftraggeber abzustimmen.

9. Kompatibilitätstests: Automatisierte und manuelle Durchführung von Kompatibili- tätstests, um sicherzustellen, dass die Anwendung mit allen aktuell verwendeten Komponenten kompatibel ist.

10. Versionierung, Release- und Rollout-Management:

a. Verwaltung von Versionen und Releases der entwickelten Artefakte,

b. Dokumentation der ausgelieferten Änderungen und Neuerungen des jeweili- gen Entwicklungsstands / Releases für die Durchführung von Abnahme- tests,

Seite 7 von 17

[Seite 8]

c. Bereitstellung der notwendigen Informationen für die Durchführung von In- stallationen

11. Projekt-Management:

a. Planung, Steuerung und Überwachung der Team-internen Aufgaben

b. Termin- und Ressourcenmanagement

c. Verwendung vom Projekt-Management-Werkzeugen zur Unterstützung eines produktiven und konstruktiven Projektverlaufs (etwa durch Methoden von V-Modell XT oder PMflex),

d. Aufwandsschätzungen, Abrechnungen und Vertragsmanagement erfolgen nach Absprache zwischen AG und AN unter Berücksichtigung der jeweils be- stehenden Prozesse und Anforderungen.

e. effiziente Berichterstattung über Projektverlauf ggü. dem AG: Die für die Be- richterstattung notwendigen Informationen wie etwa Ticket-Status und Auf- wände sind in den unter „Standards und Werkzeuge für die Softwareent- wicklung“ erwähnten zu dokumentieren. Berichte werden ebenso dort hin- terlegt und sollten, soweit sinnvoll, auch automatisiert aus den Inhalten der Tickets erzeugt werden.

f. Information an den Auftraggeber, wenn 100 % des Auftragsvolumens ge- mäß Nr. 5.2.1 der Leistungsbeschreibung erreicht sind sowie unaufgefor- dert bei Erreichen von 60 % und 80 %. Die Information kann im Wege der Rechnungsstellung durch Auflistung der bisher abgerufenen Personentage seit Vertragsbeginn erfolgen.

12. Beratung und Unterstützung des Auftraggebers: Der Auftraggeber ist für die stra- tegische Steuerung des Projekts verantwortlich und gibt die Ziele und Anforderun- gen vor. Das SDK-Team unterstützt ihn bei der Umsetzung dieser Ziele und Anfor- derungen und berät ihn bei technischen Aspekten.

3.1.2 Störungsmanagement

Diese Anforderung bezieht sich auf die Aufgaben des Teams der entwickelten Software im Produktiveinsatz im Stör- bzw. Fehlerfall.

Seite 8 von 17

[Seite 9]

3.1.2.1 Service-Zeiten bei Störungen im Produktivbetrieb

Teams müssen Störungen und Fehler (engl. „Incidents“) zumindest Montag-Freitag zwi- schen 09:00 und 17:00 Uhr (MEZ) bearbeiten können, ausgenommen sind bundeseinheit- liche Feiertage. Eine Rufbereitschaft muss nur nach Absprache vorhanden sein.

3.1.2.2 Priorisierung von Vorfällen und Reaktionszeiten

Die Reaktions- und Ziel-Lösungszeiten richten sich nach der Priorität des jeweiligen Vor- falls. Ein Vorfall gilt als kritisch, wenn die Anwendung nicht nutzbar ist oder zentrale Funk- tionen vollständig ausgefallen sind und kein Workaround zur Verfügung steht. In diesem Fall muss die Bearbeitung innerhalb von 2 Stunden aufgenommen und eine Lösung oder ein stabiler Workaround innerhalb von 1 Arbeitstag bereitgestellt werden. Ein Vorfall gilt als nicht kritisch, wenn die Anwendung grundsätzlich nutzbar ist, jedoch mit Einschrän- kungen, oder wenn ein Workaround vorhanden ist. In solchen Fällen beginnt die Bearbei- tung spätestens am folgenden Arbeitstag, und die Ziel-Lösungszeit beträgt maximal 5 Ar- beitstage. Die Ziel-Lösungszeit bezieht sich auf den Zeitraum von Erstellung des Vorfalls bis eine Lösung für ein Rollout auf die Abnahmeumgebung der DEHSt bereitsteht. Ein Vor- fall gilt als gelöst, wenn die Lösung auf die Produktivumgebung ausgerollt wurde.

3.1.2.3 Initiale Fehleranalyse

Bei Eingang eines Vorfalls beteiligen sich Auftragnehmer aller Lose an einer Erstprüfung – insbesondere, um zu klären, ob die Ursache eines Fehlers in der Anwendung, dem zugrun- deliegenden SDK oder im Hosting liegt. Liegt der Fehler außerhalb des Verantwortungsbe- reichs des AN, erfolgt eine Übergabe mit Kurz-Dokumentation durch den AN an den AG. Die Koordination obliegt dem AG.

3.1.3 Eingesetzte Technologien und Ansätze

Die folgende Aufführung der eingesetzten Technologien stellt den aktuellen Stand dar und dient der Orientierung für die AN. Sie sind die aktuelle Basis für alle weitere Entwicklungen und nur in Absprache mit dem AG kann davon abgewichen werden.

3.1.3.1 Frontend

 Angular

 NgRx

 Material

3.1.3.2 Backend

 Spring-Boot

Seite 9 von 17

[Seite 10]

 Java

 PostgreSQL

 Gradle

3.1.3.3 Verteilte Webservices

 REST, OpenAPI

 Self-contained architecture

3.1.3.4 Build-Strecke

 GitLab CI

3.1.3.5 Container und Artefakt-Repository

 Docker Images

 GitLab Artefakt und Container-Repository

 RedHat OKD (OpenShift-Containerplattform)

3.1.4 Standards und Werkzeuge für die Softwareentwicklung

Zur Zusammenarbeit mit dem AG verwenden alle AN, die vom AG bereitgestellten Werk- zeuge zur Softwareentwicklung. Der AN ist nicht verantwortlich für etwaige Schäden, die durch die Bereitstellung der Werkzeuge entstehen. Zum aktuellen Zeitpunkt sind das die Werkzeuge der GitLab Community Edition:

 Git-Repositories: Code-Verwaltung

 Issue-Tracker: Fehler- und Aufgabenverwaltung

 Boards: Projektmanagement über Agile-Board, Kanban-Board, Roadmaps

 Gitlab CI/CD: Continuous Integration für gebaute Artefakte und Docker Images

 Merge Requests / Code-Review: Entwickler-QS, Code-Überprüfung und -Feedback

 Gitlab-Wiki: Dokumentation und Wissensmanagement

 Release-Management: Verwaltung von Releases und Versionen

 Artefakt-Repository: Bereitstellung von Bibliotheken für die Entwicklung

Seite 10 von 17

[Seite 11]

 Container-Repository: Bereitstellung von Docker Images für den Betrieb der Ab- nahme- und Produktivumgebungen

Eigene, interne Werkzeuge und Umgebungen sind erlaubt und teils notwendig, etwa um Systemtest- oder Nightly-Builds anzufertigen und zu speichern. Fertige Arbeitsergebnisse, die auf die Abnahme- oder Produktivumgebung ausgeliefert werden sollen, werden jedoch jeweils auf der Infrastruktur der DEHSt ausgeliefert.

3.1.5 Betrieb von Test- und Entwicklungsumgebungen durch den AN

Der Auftraggeber stellt die Repositories der für die Kompilierung notwendigen Artefakte und Docker Images bereit, sowie jeweils eine Abnahme- und Produktivumgebung über ei- nen Dienstleister. Da für die Entwicklung von Fachanwendungen zentrale Dienste der DEHSt-Plattform (vorliegend als Docker-Images) betrieben und angebunden werden müs- sen, wird durch den Auftragnehmer eine eigene Entwicklungsumgebung betrieben. Der AN setzt darüber hinaus eine Build-Pipeline auf, die ermöglicht, die Software-Abhängigkeiten der vom AN entwickelten Artefakte möglichst automatisiert zu aktualisieren und zu testen, etwa durch ein entsprechendes Dependency Management, das automatisierte Erstellen von Builds und dem Ausführen von Test-Suites in einer Systemtest-Umgebung.

3.1.6 Feature-Entwicklung im Downstream

Manchmal entstehen neue Anforderungen, die downstream entwickelt werden müssen. Dies bedeutet, dass die Teams, die die Fachanwendungen entwickeln, neue Funktionen oder Features entwickeln müssen, die nicht ursprünglich im SDK enthalten waren. Diese neuen Funktionen oder Features müssen dann upstream gemergt werden, um sicherzustel- len, dass sie im SDK integriert werden und für alle Anwender verfügbar sind. Dafür werden git-Prozesse und Code Reviews von allen Beteiligten angewandt. Das SDK-Team trägt über Nachforderungen während des Code Reviews oder eigene Zuarbeit dafür Sorge, dass der Code sich in die durch das SDK vorgegebene Architektur und Code-Richtlinien einfügt und die Dokumentation eine zukünftige Wiederverwendung leicht ermöglichen.

3.2 SDK-Weiterentwicklung, Wartung und -Management

Das SDK-Team arbeitet eng mit dem SDK-Product Owner-Teams (PO) des Auftraggebers zu- sammen. Es entwickelt Software für Entwickler-Teams aus den beiden anderen Arbeitspa- keten (Los 2 und 3), die das SDK nutzen. Das SDK-Team arbeitet mit den Entwicklern und den Betreibern der anderen Softwarekomponenten zusammen, auf die das SDK zugreift, insb. die sog. DEHSt-Plattform.

Seite 11 von 17

[Seite 12]

3.2.1 Aufgaben des Auftragnehmers

Die allgemeinen Aufgaben eines Entwicklungsteams sind in 3.1 beschrieben. Speziell für dieses Los lassen sich die Aufgaben in drei Kategorien teilen: Wartungs- und Entwicklungs- arbeit sowie Community-Betreuung. Die Wartungsarbeiten sollen über eine monatliche Pauschale abgegolten sein, alle anderen Arbeiten werden nach Aufwand abgerechnet.

Unter den pauschal abzurechenden Wartungsaufgaben des SDK-Teams verstehen wir ins- besondere:

1. Aktualisierung der verwendeten Software: die im SDK enthaltene, importierte Soft- ware (etwa die importieren Bibliotheken und Frameworks, Basissoftware wie etwa die verwendeten Datenbanksysteme) müssen in der aktuellen Version verwendet werden und wenn möglich automatisiert, in jedem Fall aber zeitnah integriert, ge- testet und ausgerollt werden. Mit Aktualisierungen sind sowohl Updates und Up- grades aller patch-, bugfix-, security-, minor-, major- oder sonstiger Releases ge- meint.

Die Entwicklungsaufgaben des SDK-Teams umfassen insbesondere:

2. Erweiterung der Funktionalität: neue Features, die durch eine neue Fachanwen- dung nötig werden, können unter Umständen entweder vom SDK-Team oder Fach- anwendungsteam entwickelt werden – je nachdem muss der Code also entweder von Anfang an für die Nachnutzung im SDK entwickelt werden oder es kann not- wendig sein, Features aus einer Fachanwendung zu extrahieren und über die SDK- Basisanwendung allgemein verfügbar zu machen.

3. Kompatibilitätstests: Durchführung von Kompatibilitätstests, um sicherzustellen, dass das SDK mit den DEHSt-Plattform-Diensten kompatibel bleibt. Treten im Rah- men der Tests Probleme auf, wird in enger Abstimmung mit allen Beteiligten die Behebung vom AG koordiniert.

4. Versionierung und Release-Management: Verwaltung von Versionen und Releases des SDKs, um sicherzustellen, dass Entwickler immer die neueste Version verwen- den können.

5. Roadmap-Entwicklung: Anhand der Vorgaben des AG und einer Priorisierung von neuen Aufgaben erfolgt eine Analyse durch den AN und kontinuierliche Ausarbei- tung einer Roadmap über die Weiterentwicklung des SDK.

Die Community-Betreuungsaufgaben des SDK-Teams umfassen insbesondere:

Seite 12 von 17

[Seite 13]

1. Support und Community-Management:

a. Fragen und Anforderungen von SDK-Nutzenden müssen beantwortet werden und evtl. nachverfolgt werden. Ergebnisse aus dem Support müssen wieder in die Verbesserung der Dokumentation einfließen.

b. Information über anstehende Releases, um eine Projektplanung der nutzen- den Teams zu erleichtern.

2. Dokumentation für Entwicklerteams: Erstellung und Pflege von Tutorials und Bei- spielen, um den Teams die Verwendung des SDKs zu erleichtern. Zusätzlich bietet das SDK-Team den Entwicklungsteams Support und Hilfe bei Problemen oder Fra- gen.

3. Richtlinien und Best-Practices: Das SDK enthält Vorgaben für Entwicklungsteams von Fachanwendungen, wie etwa über die Benennung von Variablen, die Verwen- dung von Code-Kommentaren, der Workflow innerhalb der Codeverwaltung sowie Details wie die Darstellung von Zahlenformaten und Einheiten. Diese müssen be- achtet und weiter gepflegt und entwickelt werden.

Der Auftraggeber ist für die strategische Steuerung des Projekts verantwortlich und gibt die Ziele und Anforderungen vor. Das SDK-Team unterstützt ihn bei der Umsetzung dieser Ziele und Anforderungen und berät ihn bei technischen Aspekten.

3.2.2 Pflichten des Auftraggebers

Der Auftraggeber ist für die folgenden Aufgaben verantwortlich:

 Erstellung der Spezifikation für die Fachanwendungen

 First-Level-Support für die Fachanwendungen und das SDK

 Anforderungserhebung für die Fachanwendungen und das SDK

 Bereitstellung von Unterstützungsdienstleistungen rund um das Altsystem für die Migration

Das Entwicklungsteam arbeitet eng mit dem Auftraggeber zusammen, um sicherzustellen, dass die Fachanwendungen korrekt und effizient entwickelt, getestet und gewartet werden.

Seite 13 von 17

[Seite 14]

4. Projektorganisation

Für die Projektorganisation schlägt der AG das Prozessmodell PMflex (agil) vor, ähnliche Methoden sind ebenfalls möglich.

Im Arbeitspaket 1 (SDK) arbeiten wir mit einem agilen Ansatz mit flexiblen Iterationen und enger Zusammenarbeit zwischen AG und AN. Einen Überblick über die wesentlichen Betei- ligten finden Sie unter Abschnitt 2.1.

4.1 Zeitplan

Das Vorhaben beginnt unmittelbar nach Zuschlagserteilung. Die Laufzeit der Rahmenver- einbarung beträgt 48 Monate und kann zweimal jeweils um ein Jahr verlängert werden.

Der folgende Zeitplan ist zu berücksichtigen.

Tabelle 1: Zeitplan und Meilensteine

4.2 Besprechungen

Zu Beginn des Vorhabens ist innerhalb der ersten drei Wochen ein Kick-off Meeting in Ber- lin durchzuführen.

Darüber hinaus sollen regelmäßig weitere Abstimmungen zwischen Auftraggeber und Auf- tragnehmer über den Projektverlauf via Telefon- und vor allem Videokonferenzen stattfin- den.

Im Projektverlauf sind weitere Treffen in Berlin einzuplanen.

4.3 Projektsprache

Die Projektsprache ist Deutsch. Ausnahme stellen Softwareartefakte und ihre Dokumenta- tion im Quellcode dar. Hier wird Englisch verwendet.

Seite 14 von 17

[Seite 15]

Werden Begriffe der DEHSt beim Schreiben von Code durch den AN übersetzt, müssen die Originalbegriffe der DEHSt an der jeweiligen Code-Stelle per Kommentar hinterlegt werden, damit beim Lesen der Zusammenhang zwischen Spezifikation und Code sichergestellt wird.

5. Anforderungen an das Angebot/die Leistungsausführung

5.1 Allgemeine Anforderungen an das Angebot

Dem Angebot sind eine Reihe von Unterlagen und Nachweise beizufügen, die im Anhang „Bewertungsmatrix“ definiert sind. Dabei ist die Erfüllung aller Eignungskriterien (A) Grundvoraussetzung. Sind diese erfüllt, entscheidet die Punktezahl aus den Wertungskri- terien (B).

Voraussetzung für eine hohe Punktzahl ist eine Kenntnis der technischen Basis, die in 3.1.3 aufgezählt wird und in Form unser Softwaredokumentation auf dem GitLab-Server der DEHSt eingesehen werden kann. Zugriff auf unser GitLab wird auf Anfrage erteilt.

Seite 15 von 17

[Seite 16]

5.2 Anforderungen an die Leistungserbringung

5.2.1 Allgemeine Anforderungen

Die Anbietenden werden gebeten, Ihre Angebote digital und inhaltlich sauber strukturiert zu gestalten. Angebote verwenden die beigefügten Formulare als Vorlage und werden als PDF eingereicht. Falls Code mit eingereicht wird, muss dieser als ZIP-Datei (der vom Bieter erstellten git-Repositories) über die eVergabe-Plattform eingereicht werden. Das revisions- sichere Code-Verwaltungssystem der DEHSt (GitLab) dient hier nur als Quelle - etwaige Forks müssen durch den Bieter separat abgelegt werden. Im begleitenden Schreiben kann mit der „Code-Repository“-Vorlage auf das Repository im ZIP verwiesen werden. Zugriff zu unserem GitLab wird auf Anfrage erteilt.

Nach dem aktuellen Planungsstand beabsichtigt der Auftraggeber in den ersten vier Jahren Aufgaben mit bis zu 2.560 Personentage (PT) zu beauftragen. Vorbehaltlich von möglichen Änderungen der Gesetzeslage rund um den europäischen und den nationalen Emissions- handel erwartet der Auftraggeber, dass mindestens 50% der hier genannten Obergrenze für Personentage beauftragt werden wird.

Sollte der Vertrag um jeweils ein Jahr verlängert werden, erwartet der Auftraggeber Aufga- ben in der Höhe von 640 PT je Verlängerung (bis zu 25% des ursprünglichen Umfangs). Zum Zwecke einer ungefähren Kapazitätsplanung sehen wir in etwa einen Bedarf von 960 PT im ersten Jahr und durchschnittlich 500 PT je Folgejahr. Es wird davon ausgegangen, dass die Arbeitslast relativ gleichmäßig über die Monate verteilt werden kann, sodass eine kon- stante Auslastung eines Entwicklungsteams erreicht werden kann.

5.3 Kostendarstellung

Die voraussichtlichen Kosten/Ausgaben der einzelnen Positionen sind durch ein transpa- rentes Preisgerüst für Personal- und Sachkosten darzustellen. Die pauschal abzurechnen- den Wartungsarbeiten werden im Preisblatt unter 1.2.1 als jährlicher Betrag aufgeführt. Als Mengengerüst für das Personal sind die unter den Allgemeinen Anforderungen aufgeführ- ten Personentage zu verwenden.

Ausgefüllt und eingereicht werden muss das den Unterlagen beigefügte Preisblatt für die- ses Los.

Die Gesamtsummen sind als Netto- und Bruttokosten aufzuführen. Der in Ansatz gebrachte Umsatzsteuersatz ist gesondert auszuweisen.

Bei Anbietergemeinschaften müssen die Mengen/Kosten einzelner Kooperationspartner den entsprechenden Leistungen so dargestellt werden, dass eine Zuordnung und Bewer- tung der Mengen/Kosten zu den jeweiligen Arbeitspaketen ermöglicht wird.

Seite 16 von 17

[Seite 17]

6. Eignung des/der Auftragnehmers/in

Die Anbietenden für alle Arbeitspakete haben ihre Eignung zur vertragsgemäßen Bearbei- tung nachzuweisen. Dabei sind Nachweise für die Eignung entsprechend der Arbeitsmappe Bewertungsmatrix, Tabellenblatt „Eignungskriterien (A)“ einzureichen. Darin ist auch fest- gehalten, wenn ein Kriterium unter Verwendung einer entsprechenden Vorlage beantwortet werden muss. Diese Vorlagen sind den Ausschreibungsunterlagen beigefügt.

Dokumente werden als PDF-Dateien über die Vergabeplattform eingereicht. Falls Code mit eingereicht wird, muss dieser als ZIP-Archiv (der vom Bieter erstellten git-Repositories) ebenso über die Vergabeplattform eingereicht werden. Im begleitenden Schreiben kann mit der „Code-Repository“-Vorlage auf das Repository im ZIP verwiesen werden. Zugriff zu unserem GitLab wird auf Anfrage erteilt.

Nachweise dürfen nur in begründeten Ausnahmen älter als 3 Jahre sein.

7. Zuschlags-/Wertungskriterien

Siehe Nr. 16 der Bewerbungsbedingungen

Seite 17 von 17