206008 - 3.1 - Los 2 - Leistungsbeschreibung.pdf

[Seite 1]

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

Az: 10 233/00077

Leistungsbeschreibung

Thema: „Entwicklung und Wartung von Fachanwendungen für Vollzugsverfahren der DEHSt auf Basis des DEHSt-Software-Development Kits mit dem Schwerpunkt auf Neuentwicklungen (Los 2)“

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 Softwareentwicklung und -Wartung von Fachanwendungen (FA) mit Schwerpunkt auf Neuentwicklungen ............................................................................................. 11 3.2.1 Aufgaben des Auftragnehmers ................................................................. 12 3.3 Pflichten des Auftraggebers .......................................................................... 14

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

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

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 Container-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. Dafür soll je- weils eine Rahmenvereinbarung geschlossen werden. Wir unterscheiden demnach zwi- schen 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

Fachanwendung-Entwickler-Teams (das sind Sie): Entwicklung, Wartung und Monitoring der Fachanwendungen auf Basis des SDKs und Vorgaben unseres Fachgebiets für das fach- liche Datenmanagement (Fachgebiet V 2.7, s.u.).

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.

 Fachgebiet V 2.7 Fachliches Datenmanagement und Qualitätssicherung der DEHSt („Product Owner“ der Fachanwendungen): Die fachlichen Expert*innen der DEHSt

Seite 4 von 17

[Seite 5]

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.

 Weitere Fachgebiete: Sie sind die Nutzenden der Software auf der (internen) Bear- beitungsseite und die fachlichen Expert*innen der DEHSt. Sie sind co-verantwortlich für die Ableitung der Anforderungen aus den gesetzlichen Vorgaben mit V 2.7, sowie beteiligt am Test der Software. In Themen-spezifische Branchen- und Vollzugsfach- gebiete unterteilt.

Andere wichtige Beteiligte und ihre Aufgaben:

 SDK-Entwicklungs-Team: Entwicklung und Wartung des SDKs, Auslieferung der weiterverwendbaren Artefakte durch die Fachanwendungs-Entwickler-Teams, Com- munity-Management, Hilfe für andere Entwickler-Teams bei der Integration,

 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

 Mitarbeitende emissionshandelspflichtiger Unternehmen und der von ihnen beauf- tragten Prüforganisationen (externe Nutzende): Nutzen die (externe, öffentliche) sog. Erfassungsseite der jeweiligen Fachanwendung. Deshalb im regelmäßigen Aus- tausch über die Software mit der DEHSt über unseren Kundensupport.

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 strate- gische 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, etwa vor Ende einer gesetzlichen Frist, wenn sich eine Anwendung als störanfällig herausstellt und ein akutes Monitoring der Funktionsfähigkeit und kurzfristige Abhilfe benötigt.

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, sowie wenn Funktionen betroffen sind, die eine Einhaltung von gesetzlichen Fristen akut gefährden. 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 Ein- schränkungen, oder wenn ein Workaround vorhanden ist. In solchen Fällen beginnt die Be- arbeitung spätestens am folgenden Arbeitstag, und die Ziel-Lösungszeit beträgt maximal 5 Arbeitstage. Die Ziel-Lösungszeit bezieht sich auf den Zeitraum von Erstellung des Vor- falls bis eine Lösung für ein Rollout auf die Abnahmeumgebung der DEHSt bereitsteht. Ein Vorfall 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

Seite 9 von 17

[Seite 10]

3.1.3.2 Backend

 Spring-Boot

 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

Seite 10 von 17

[Seite 11]

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

 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 Softwareentwicklung und -Wartung von Fachanwendungen (FA) mit Schwerpunkt auf Neuentwicklungen

Das FA-Team arbeitet eng mit den Fachteams des Auftraggebers zusammen. Es entwickelt Software für den Vollzug der gesetzlichen Aufgaben des Auftraggebers. Es arbeitet zusam- men mit den Entwicklerteams und den Betreiberteam der anderen Softwarekomponenten, insb. dem DEHSt-SDK (Los 1), die die Basis für die Fachanwendungen darstellt, zusammen. Ebenso wichtig ist das Entwicklerteam der sog. DEHSt-Plattform, die zentrale Dienste für

Seite 11 von 17

[Seite 12]

alle Fachanwendungen anbietet und das Ops-Team beim Betreiber der Hosting-Infrastruk- tur.

3.2.1 Aufgaben des Auftragnehmers

Die Aufgaben des FA-Teams mit Schwerpunkt auf Neuentwicklungen umfassen zusätzlich zu den in 3.1 genannten:

1. Umsetzung von fachlichen Anforderungen einer Fachanwendung

a. Aufbauend auf den Vorgaben sowie den Features und Datenmodellen der Basisanwendungen des SDK.

b. Effiziente und fristgerechte Umsetzung der in Tickets oder im Spezifikati- onsdokument festgehaltenen Anforderungen.

2. Inbetriebnahme in der Abnahme- und Produktivumgebung

a. Bereitstellung der Dokumentation für die Installation und den Betrieb

b. Zusammenarbeit mit dem Hostingdienstleister

3. Monitoring im Abnahme- und Produktivbetrieb

a. Nutzung des durch den Hostingdienstleister bereitgestellten zentralisierten Protokoll-Software (Logging) und Benachrichtigungen (Alerts).

b. Aktive Überwachung des Loggings auf Fehler durch das Team und Prüfung, etwa ob eine Störung vorliegt (vgl. Störungsmanagement) und Abstimmung mit der DEHSt über das weitere Vorgehen mit auftretenden Fehlern.

4. Support

a. Verantwortlich für die Beantwortung und Nachverfolgung von Fragen und Anforderungen der DEHSt.

b. Leistet Second-Level Support. Im Regelfall läuft die Kommunikation zu den Nutzenden und Betroffenen über die DEHSt (First-Level-Support). In Einzelfällen unterstützt das Team

Seite 12 von 17

[Seite 13]

die DEHSt und wird durch die DEHSt beauftragt, in direkten Kontakt mit Nut- zenden zu treten, etwa zur Problemanalyse.

c. Abstimmung mit dem Projektmanagement zur Aufnahme relevanter Punkte aus dem Support in die Umsetzung.

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

Seite 13 von 17

[Seite 14]

3.3 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

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

4. Projektorganisation

Im Arbeitspaket 2 (Fachanwendungen) arbeiten wir nach Möglichkeit mit einer fertigen Spezifikation, die an den AN übergeben wird. Demnach wird jeder Entwicklungsprozess ei- ner Software in ein entsprechendes „klassisches“ Prozessmodell mit Phasen eingebettet, etwa V-Modell XT.

Da der Auftragnehmer abhängig von politischen und juristischen Entwicklungen ist, kann im Einzelfall nicht mit einem klassischen Managementansatz gearbeitet werden, sondern wird mit einem agilen Ansatz mit flexiblen Iterationen und enger Zusammenarbeit zwischen AG und AN. Einen Überblick über die wesentlichen Beteiligten finden Sie unter Abschnitt 0.

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 für das erste Auftragsjahr ist zu berücksichtigen.

Tabelle 1: Zeitplan und Meilensteine

Seite 14 von 17

[Seite 15]

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.

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 ist eine Reihe von Unterlagen und Nachweise beizufügen, die im Anhang „Be- wertungsmatrix“ definiert sind. Dabei ist die Erfüllung aller Eignungskriterien (A) Grundvo- raussetzung. Sind diese erfüllt, entscheidet die Punktezahl aus den Wertungskriterien (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 und vom textlichen Umfang her nur so ausführlich wie nötig zu gestalten. Angebote ver- wenden 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 revisionssichere Code-Verwaltungs- system 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“-Vor- lage auf das Repository im ZIP verwiesen werden. Zugriff zu unserem GitLab wird auf An- frage erteilt.

Nach dem aktuellen Planungsstand beabsichtigt der Auftraggeber in den ersten vier Jahren Aufgaben mit bis zu 3.056 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 764 PT je Verlängerung (bis zu 25% des ursprünglichen Umfangs). Zum Zwecke einer ungefähren Kapazitätsplanung sehen wir in der Regel einen Bedarf von 500 PT pro Jahr, aber jeweils in 2028 und 2029 einen erhöhten Bedarf von etwa 1.000 PT. Die Auslastung über den Jahresverlauf kann sehr unterschiedlich ausfallen. Die Bereitstellung der Fachanwendungen muss in den allermeisten Fällen zu fixen gesetzlichen Fristen erfol- gen. Dies hat zur Folge, dass mehrere Entwicklungsprojekte parallel bearbeitet werden müssen. Damit geht ein erhöhter Personalbedarf einher, der vom Auftragnehmer abge- deckt werden muss (z.B. zwei bis vier Entwicklungsressourcen arbeiten an einer Fachan- wendung, zeitgleich müssen bis zu vier Fachanwendungsprojekte bearbeitet werden). Die gesetzliche Fristsetzung kann vom Auftraggeber in der Regel leider nicht beeinflusst wer- den.

5.3 Kostendarstellung

Die voraussichtlichen Kosten/Ausgaben der einzelnen Positionen sind durch ein transpa- rentes Preisgerüst für Personal- und Sachkosten darzustellen. Als Mengengerüst für das Personal sind die unter den Allgemeinen Anforderungen aufgeführten Personentage zu ver- wenden.

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

Seite 16 von 17

[Seite 17]

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.

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 un- serem 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