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.

• Agile Softwareentwicklung Iterative Zusammenarbeit. Anforderungen können während des Projekts konkretisiert und angepasst werden (Change-Management, siehe Abschnitt 6).
• 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.
• 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 die im beigefügten Lastenheft beschriebenen Anforderungen sowie das auf dieser Basis 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. Technisches Konzept, Architektur- und Datenmodellskizzen.
3. Entwicklung UI/UX Konzept Erstellung Gestaltungs- und Benutzerführungskonzept, inkl. User-Stories zu den wichtigen Grundfunktionen.
4. Agile Implementierung auf Basis des Pflichtenhefts.
5. Qualitätssicherung & Tests: Unit-, Integrations-, System- und Abnahmetests; Testdaten; Testprotokolle.
6. Datenmigration inkl. Mapping, ETL‑Prozessen, Testmigration(en), Validierung und Cutover (Details in Abschnitt 7).
7. Technische Dokumentation & Programmbeschreibung, Betriebs-/Administrationshandbuch, Anwenderdokumentation.
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, Repository, Definition of Ready/Done.
2. Phase 1 – Pflichtenheft: Entwicklung bis zur abgestimmten Endfassung als Grundlage für Umsetzung und Abnahme inkl. Technisches Konzept.
3. Phase 2 – Entwicklung UI/UX Konzept Erstellung Gestaltungs- und Benutzerführungskonzept, inkl. User-Stories zu den wichtigen Grundfunktionen.
4. Phase 3 – Agile Entwicklung: Iterative Entwicklung entsprechend den abgestimmten Meilensteinen, fortlaufende Backlog‑Pflege.
5. Phase 4 – Test & Abnahme: System-/UAT‑Tests, Mängelliste, Abnahme gemäß Kriterien (Abschnitt 8).
6. Phase 5 – Rollout & Datenmigration: Cutover-Plan, Go‑Live, Hypercare.
7. Phase 6 – Wartung & Support: SLA‑basierte Betreuung.

5. Projektorganisation & Kommunikation

• Vorgehensmodell: Agiles Modell, iterative Entwicklung mit regelmäßigen Feedbackschleifen, regelmäßigen Abstimmungsterminen, Backlog.
• Tools: Kollaboration (z. B. MS Teams/Jira/Confluence), Codeverwaltung GitLab (privat), CI/CD.
• Kommunikation: Regeltermine (Jour fixe), Protokolle, Entscheidungslog.
• Transparenz: 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 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 auf systemkritische Komponenten, automatisierte Tests, OWASP Top 10‑Bewusstsein.
• Abnahmekriterien: Erfüllung Pflichtenheft & vereinbarter Akzeptanzkriterien, Bestehen der Testfälle, Beseitigung wesentlicher Mängel (Schweregrad‑Definitionen im Pflichtenheft).
• Abnahmeprozess: UAT mit Protokoll; ggf. Teilabnahmen.
• 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 Repository 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.
• Wenn nach Abstimmung mit dem Auftraggeber im System kostenpflichtige Drittanwendungen oder -schnittstellen (z. B. zur Dokumenten-Generierung oder ähnlichen Zwecken) eingesetzt werden, wird der Auftraggeber Lizenzinhaber der betreffenden Software und trägt die hierfür anfallenden Kosten.
• 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 eigener Projekte und allgemein Webanwendungen

Projektbezogene Angaben

• Beschreibung der geplanten agilen Vorgehensweise
• Projektorganisation & Kommunikationsstruktur
• grobes technisches Konzept (wünschenswert, aber nicht verpflichtend)
• Maßnahmen zur Qualitätssicherung & Teststrategie
• Optional: Hosting/Betriebskonzept

Preisangaben

• Vollständige und nachvollziehbare Preisangaben (z. B. Festpreisanteile, 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 groben technischen Konzepts
• Migrationsansatz und Risikomanagement
• Nachvollziehbarkeit & Realisierbarkeit des Zeitplans
• Preis und Transparenz der Kalkulation
• Qualität & Umfang von Wartung/Support (SLA)

(Optional können Bietende zu online 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: 31.01.2025, 18:00
• Gewünschter Projektbeginn: 01.04.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)