AUSSCHREIBUNG – Entwicklung und Migration einer Softwarelösung für das Institut Bauen und Umwelt e.V.

1. Auftraggeber

Institut Bauen und Umwelt e.V. (IBU)
Hegelplatz 1
10117 Berlin

Vertreten durch den Geschäftsführer: Florian Pronold
Verantwortlicher Ansprechpartner: Amar Salcinovic
E‑Mail: salcinovic@ibu-epd.com

2. Ziel und Gegenstand der Ausschreibung

Der Auftraggeber beabsichtigt, die Neuaufsetzung/Erneuerung der unter epd-online.com betriebenen Anwendung zu vergeben. Die bestehende Lösung wird technisch abgelöst („Replacement“) und funktional weiterentwickelt.

• Agil Agile Softwareentwicklung (Scrum oder Kanban) mit iterativer Zusammenarbeit. Anforderungen können während des Projekts konkretisiert und angepasst werden (Change-Management, siehe Abschnitt 6).
• Migration Datenmigration ist Bestandteil des Auftrags (siehe Abschnitt 7). Keine 1:1‑Migration sämtlicher Daten – es werden nur fachlich notwendige Daten übernommen, insbesondere unter Berücksichtigung der Verknüpfungen mit IBU.data.
• Flexibel Keine Pflicht zur 100%igen Neuentwicklung: Bestehende, funktionsnahe Systeme dürfen eingebracht bzw. geforkt und adaptiert werden, sofern alle Anforderungen erfüllt sind (siehe Abschnitt 10).

Als funktionale Referenz dient die derzeitige Anwendung unter epd-online.com. Maßgeblich sind das Lastenheft und das im Projekt zu erstellende Pflichtenheft.

3. Leistungsumfang (Scope)

1. Anforderungsanalyse gemäß Lastenheft, Initialisierung des Product Backlogs.
2. Pflichtenheft (Phase 1) als fachliche und technische Spezifikation inkl. Architektur- und Datenmodellskizzen.
3. Agile Implementierung auf Basis des Pflichtenhefts (Sprints/Iterationen).
4. Qualitätssicherung & Tests: Unit-, Integrations-, System- und Abnahmetests; Testdaten; Testprotokolle.
5. Datenmigration inkl. Mapping, ETL‑Prozessen, Testmigration(en), Validierung und Cutover (Details in Abschnitt 7).
6. Technische Dokumentation & Programmbeschreibung, Betriebs-/Administrationshandbuch, Anwenderdokumentation.
7. Bereitstellung des vollständigen Quellcodes in einem privaten GitLab‑Repository des Auftraggebers (siehe Abschnitt 9).
8. Einweisung/Schulung von Administrator:innen und Key‑Usern.
9. Fehlerbehebung bis zur erfolgreichen Abnahme (siehe Abschnitt 8).
10. Wartung & Support nach Abnahme (Pflichtbestandteil, siehe Abschnitt 11).

Optionale Leistungen (im Angebot zu spezifizieren): Hosting/Betrieb, Monitoring, CI/CD‑Setup, Performance-/Lasttests, Accessibility‑Prüfung.

4. Projektphasen und Meilensteine

1. Phase 0 – Kick‑off & Setup: Team, Tools, Repo, CI/CD, Definition of Ready/Done.
2. Phase 1 – Pflichtenheft: Abgestimmte Endfassung als Grundlage für Umsetzung und Abnahme.
3. Phase 2 – Agile Entwicklung: Umsetzung in Sprints mit Review/Demo, fortlaufender Backlog‑Pflege.
4. Phase 3 – Test & Abnahme: System-/UAT‑Tests, Mängelliste, Abnahme gemäß Kriterien (Abschnitt 8).
5. Phase 4 – Rollout & Datenmigration: Cutover-Plan, Go‑Live, Hypercare.
6. Phase 5 – Wartung & Support: SLA‑basierte Betreuung.

5. Projektorganisation & Kommunikation

• Vorgehensmodell: Scrum oder Kanban; Sprints (i.d.R. 2–3 Wochen), Backlog, Sprint Planning, Daily, Review/Demo, Retrospektive.
• Rollen: Product Owner (IBU), Projektleitung/Delivery Lead (AN), Entwickler:in(nen), QA/Tester:in(nen), Architekt:in, ggf. DevOps.
• Tools: Kollaboration (z. B. MS Teams/Jira/Confluence), Codeverwaltung GitLab (privat), CI/CD.
• Kommunikation: Regeltermine (Jour fixe), Protokolle, Entscheidungslog.
• Transparenz: Burn‑Down/Up, Velocity, Risiko-/Issue‑Log, regelmäßige Statusberichte.

5a. Öffentliches GitLab‑Repository für Lastenheft, Fragen & Änderungen

Zur Erhöhung der Transparenz richtet der Auftraggeber ein öffentliches GitLab‑Repository ein (nur Ausschreibungs-/Lastenheft‑Dokumente, kein Quellcode).

Zweck & Nutzung

• Single Source of Truth für das Lastenheft: docs/Lastenheft.md (Quelle) und docs/Lastenheft.pdf (Ausgabe).
• Fragen ausschließlich als GitLab Issues bis zur Fragenfrist (siehe Abschnitt 18). Antworten/Ergänzungen werden dort öffentlich dokumentiert.
• Änderungshistorie über Commits, Tags/Releases (z. B. v0.9, v1.0);
• Bietende abonnieren das Repo (Watch/Release‑Notify), um Änderungen mitzubekommen.

Repo‑Struktur

• /README.md – Kurzbeschreibung, Teilnahmehinweise, Fristen, Link zur PDF.
• /docs/Lastenheft.md – Quelle; /docs/Lastenheft.pdf – Ausgabe.

Governance & Spielregeln

• Keine Angebotsabgabe über GitLab. Angebote werden wie in Abschnitt 18 beschrieben eingereicht.
• Keine vertraulichen Informationen in Issues posten.
• Klarstellungen erfolgen durch den Auftraggeber via Commit/Release und werden im CHANGELOG.md referenziert.
• Nach Zuschlag erfolgt die Quellcode‑Entwicklung in einem privaten GitLab‑Repository des Auftraggebers (siehe Abschnitt 9).

6. Agile Zusammenarbeit & Change‑Management

• Änderungen am Leistungsumfang werden kontrolliert in den Product Backlog eingebracht, priorisiert und über Sprint Planning eingeplant.
• Bei wesentlichen Scope‑Änderungen sind Auswirkungen auf Zeit/Preis zu bewerten (Change Request).
• Akzeptanzkriterien werden pro User Story/Funktion vorab definiert und sind Grundlage für Reviews/Abnahmen.

7. Datenmigration (Bestandteil des Auftrags)

• Zielsetzung: Übernahme der fachlich relevanten Bestandsdaten unter Berücksichtigung bestehender Verknüpfungen mit IBU.data.
• Leistungsinhalte: Dateninventar & ‑klassifizierung, Mapping‑Konzept, ETL‑Prozesse, Testmigrationen, Datenqualitätsprüfungen, Protokolle, Fehlerlisten, Cutover‑Plan (inkl. Downtime‑Fenster), Rückfallstrategie.
• Nicht 1:1: Es werden nur notwendige Daten migriert; Reduktion/Transformation gemäß Pflichtenheft.
• Datenschutz: Umsetzung gemäß DSGVO/BDSG; Pseudonymisierung/Anonymisierung wo möglich; AV‑Vertrag vor Produktivsetzung (siehe Abschnitt 14).
• Abnahme: Formale Bestätigung der Datenqualität anhand definierter Prüfregeln/Stichproben.

8. Abnahme, Qualitätssicherung & Gewährleistung

• Qualitätsstandards: Clean Code, Code Reviews, automatisierte Tests, OWASP Top 10‑Bewusstsein, Logging/Monitoring‑Hooks.
• Abnahmekriterien: Erfüllung Pflichtenheft & vereinbarter Akzeptanzkriterien, Bestehen der Testfälle, Beseitigung wesentlicher Mängel (Schweregrad‑Definitionen im Pflichtenheft).
• Abnahmeprozess: UAT mit Protokoll; ggf. Teilabnahmen sprintweise.
• Gewährleistung: Mängelbeseitigung innerhalb einer Gewährleistungsfrist (im Angebot anzugeben; Mindestvorschlag: 12 Monate ab Abnahme).

9. Quellcode, Repository & Dokumentation

• Repository: Vollständiger Quellcode in einem privaten GitLab‑Repository im Besitz des Auftraggebers. Zugriff für den Auftragnehmer wird projektbezogen gewährt.
• Lizenz & Vertraulichkeit: Code ist streng vertraulich und nicht öffentlich. Weitergabe an Dritte oder Nutzung für Dritte ohne vorherige schriftliche Zustimmung untersagt.
• Dokumentation: Architektur, API‑Spezifikationen, Betriebshandbuch (Runbook), Benutzerhandbuch, Migrations- und Testdokumente im Repo versioniert.
• CI/CD & Qualität: Pipeline‑Konfigurationen, IaC (falls beauftragt), Linter/Formatter‑Regeln, Testberichte.

Rechteübertragung

• Sofern im Angebot nicht anders ausgewiesen, gehen sämtliche Nutzungs- und Verwertungsrechte an allen im Projekt neu geschaffenen Arbeitsergebnissen (inkl. Quellcode) nach vollständiger Zahlung an den Auftraggeber über.
• Vorbestehende Komponenten des Auftragnehmers (inkl. eines eingebrachten Forks) verbleiben im Eigentum des Auftragnehmers; der Auftragnehmer räumt dem Auftraggeber daran eine zeitlich, räumlich und inhaltlich unbeschränkte, übertragbare und unterlizenzierbare Nutzungsrechtelizenz zur Nutzung im Rahmen dieser Lösung ein, inkl. Quellcodeeinsicht, Bearbeitung und Betrieb.
• Der Auftragnehmer sichert zu, dass keine Rechte Dritter verletzt werden und Open‑Source‑Lizenzen (inkl. Copyleft) kompatibel und dokumentiert sind (SBOM/Third‑Party‑Notice). Copyleft‑Lizenzen, die Veröffentlichungspflichten auslösen, sind vorher schriftlich zu genehmigen.

10. Zulässige Wiederverwendung / Forks

• Bietende dürfen bestehende Systeme einbringen und eine Abspaltung (Fork) erstellen, um die Anforderungen des Lastenhefts zu erfüllen.
• Der Fork darf ohne schriftliche Zustimmung des Auftraggebers nicht an Dritte weitergegeben, veröffentlicht oder für Drittprojekte genutzt werden, soweit projektindividuelle Bestandteile betroffen sind.
• Der Auftragnehmer stellt sicher, dass alle eingebrachten Komponenten rechtssicher sind und die in Abschnitt 9 genannten Nutzungsrechte eingeräumt werden.

11. Wartung & Support (Pflichtbestandteil)

• Umfang: Fehlerbehebung, Sicherheitsupdates, kleinere Anpassungen, Performance‑Tuning.
• SLA‑Vorschlag: Reaktionszeiten je Priorität (P1 kritisch – z. B. 4h; P2 hoch – 1 AT; P3 normal – 3 AT), Servicezeiten (werktags xx:xx–xx:xx, Zeitzone Europa/Berlin), Kommunikationswege, Eskalation.
• Release‑Management: Versionierung, Änderungsprotokoll, geplante Wartungsfenster.

12. Angebotsinhalt (Pflichtbestandteile)

Unternehmensbezogene Angaben

• Unternehmensprofil
• Nachweise zu Qualifikation und Fachkunde
• Referenzen vergleichbarer, agiler Softwareprojekte (inkl. Ansprechpartner)
• Verfügbarkeit/Team (Rollen, Kapazität, Qualifikation)

Projektbezogene Angaben

• Beschreibung der geplanten agilen Vorgehensweise (Framework, Sprintlänge, Artefakte)
• Zeitplan & Meilensteine (inkl. Puffer, kritischer Pfad)
• Projektorganisation & Kommunikationsstruktur
• Technisches Konzept inkl. Architektur, Technologie‑Stack, Sicherheitskonzept, CI/CD
• Migrationskonzept (Scope, Mapping, ETL, Validierung, Cutover, Risiken)
• Maßnahmen zur Qualitätssicherung & Teststrategie
• Optional: Hosting/Betriebskonzept

Preisangaben

• Vollständige und nachvollziehbare Preisangaben (z. B. Festpreisanteile, Time‑&‑Material je Sprint, Tagessätze)
• Darstellung der Preisbildung und Annahmen
• Kosten für Wartung, Support und Weiterentwicklung (Pflichtangabe, SLA‑basiert)
• Optionale Leistungen separat ausweisen (z. B. Hosting, Lasttests)

Rechtliches

• Darstellung der Lizenz-/Rechteeinräumung gemäß Abschnitt 9–10
• Erklärung zu Drittsoftware/OSS inkl. Lizenzliste/SBOM
• Muster‑AV‑Vertrag oder Bereitschaftserklärung zum Abschluss

13. Zuschlagskriterien

• Qualität & Eignung des technischen Konzepts (inkl. Sicherheit & Skalierbarkeit)
• Agile Umsetzungsfähigkeit (Team, Prozessreife, Referenzen)
• Migrationsansatz und Risikomanagement
• Nachvollziehbarkeit & Realisierbarkeit des Zeitplans
• Preis und Transparenz der Kalkulation
• Qualität & Umfang von Wartung/Support (SLA)
• Referenzen & bisherige Projekterfahrung

(Optional können Bietende zu Bietergesprächen/Demos eingeladen werden.)

14. Datenschutz (DSGVO) & Informationssicherheit

• Einhaltung EU‑DSGVO und BDSG.
• Abschluss eines Auftragsverarbeitungsvertrags (AV‑Vertrag) vor Produktivsetzung.
• Privacy by Design/Default, Datenminimierung, Berechtigungskonzepte, Protokollierung.
• Informationssicherheit nach Best Practice (z. B. OWASP, Härtung, Geheimnisschutz).

15. Vertraulichkeit (NDA)

Alle im Zuge der Angebots- und Projektphase bereitgestellten Informationen sind vertraulich. Eine Weitergabe an Dritte ist untersagt. Diese Verpflichtung gilt über das Vertragsende hinaus.

16. Vertrags- und Rahmenbedingungen

• Vertragsgrundlage ist das nach Zuschlag gemeinsam bestätigte Pflichtenheft sowie diese Ausschreibung.
• Nebenabreden bedürfen der Schriftform.
• Rechteübertragung und Repository‑Regelungen gemäß Abschnitt 9–10.
• Abrechnungs- und Zahlungsmodalitäten gemäß Angebot.

17. Verfahrensablauf

1. Veröffentlichung/Versand der Ausschreibungsunterlagen inkl. Link zum öffentlichen GitLab‑Repository
2. Fragenfrist: Rückfragen ausschließlich über GitLab Issues im öffentlichen Repo; Antworten/Klarstellungen werden dort veröffentlicht.
3. Angebotsabgabe (nicht über GitLab)
4. Prüfung und Wertung der Angebote
5. Rückfragen/Bietergespräche (optional)
6. Zuschlagsentscheidung
7. Auftragserteilung und Projektstart

Ein Anspruch auf Zuschlagserteilung besteht nicht.

18. Fristen

• Frist für Bieterfragen: 01.12.2025, 18:00
• Angebotsfrist: 30.12.2025, 18:00
• Gewünschter Projektbeginn: 01.02.2026

Bitte alle Fristen in der Zeitzone Europa/Berlin verstehen.

19. Kommunikation

Öffentliches GitLab‑Repository (Q&A & Änderungen):
Rückfragen zum Lastenheft und Klarstellungen erfolgen ausschließlich über Issues im öffentlichen Repository. Der Link wird mit der Ausschreibung bereitgestellt. Antworten sind dort für alle Bietenden einsehbar.

Formale/administrative Kommunikation:
Amar Salcinovic
E‑Mail: salcinovic@ibu-epd.com
Bitte keine Angebotsunterlagen oder vertraulichen Inhalte per GitLab einreichen.

20. Anlagen

• A1 – Lastenheft (verbindlich)