Übersicht
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 |
|---|---|---|---|---|---|
| Übersicht der Qualität des Angebots | |||||
| Eignungskriterien für bietende Unternehmen (A) | |||||
| 1. Allgemeine Angaben des Unternehmens | |||||
| Name und Anschrift des Unternehmens | |||||
| Kontaktperson | |||||
| Alle Kriterien erfüllt? | Nein | ||||
| Wertungskriterien für das fachliche Angebot (B) | |||||
| Erreichbare Gesamtpunktzahl | 1300 | 0.0 | |||
| Erreichte Punkte | 0 | ||||
| Erreichte Punkte in der Kriterienhauptgruppe 1 (XP). | 0 | 0.0 | |||
| Preispunktberechnung | |||||
| Wertungspreis (Angebotsformular Teil C) | (wird manuell durch die DEHSt aus Teil C übertragen) | ||||
| Preispunkt | Teilung durch 0: Formular nicht ausgefüllt? |
Eignungkriterien (A)
| Eignungskriterien für bietende Unternehmen (A) i.d.F.v. i.d.F.v. 09.09.2026 (Änderungen sind grün hervorgehoben) | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 |
|---|---|---|---|---|---|---|---|---|
| Kriterium | Kriterienart | beizubringen von | Bewertung Erfüllung (ja-nein) | Antworterwartung | ||||
| I Einführung | DropDown-Liste | |||||||
| 1. Allgemeine Angaben des Unternehmens | Erfüllt | Ja | ||||||
| Name und Anschrift des Unternehmens | Nicht erfüllt | Nein | ||||||
| Kontaktperson | ||||||||
| II. Befähigung und Erlaubnis zur Berufsausübung | ||||||||
| 1. Eintragung in das Berufs-/Handelsregister oder vergleichbarer Nachweis für die erlaubte Berufsausübung | ||||||||
| Sie verfügen über eine Eintragung in das Berufs/-Handelsregister bzw. vergleichbarem Nachweis zur Befähigung zur Berufsausübung nachzuweisen durch formlose Bestätigung im Angebot. Zutreffende Nachweise nicht älter als 12 Monate sind gesondert beizufügen. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern zutreffend | A-Kriterium: • Kopie des relevanten Dokuments (der relevanten Dokumente) ist beizulegen, um Kriterium zu erfüllen | |||||
| III. Wirtschaftliche und finanzielle Leistungsfähigkeit | ||||||||
| 1. Angaben zum Mindestumsatz: Gesamtumsatz | ||||||||
| Angabe des Gesamtumsatzes des Unternehmens der letzten beiden Geschäftsjahre (2023, 2024), nachzuweisen durch formlose Angabe im Angebot. Hinweis: Bei Unternehmens-/Bietergemeinschaften und/oder dem beabsichtigten Einsatz von Unterauftragnehmern hat jedes Mitglied die Angaben gesondert zu machen. Im Rahmen der Auswertung werden die Zahlen von allen Mitgliedern Das Unternehmens-/Bietergemeinschaft aufsummiert. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern zutreffend | A-Kriterium: Kriterium nicht erfüllt bei (aufsummiertem) Jahresumsatz im Mittel p.a. < 4 Mio. Euro | |||||
| 2. Versicherungsdeckung | ||||||||
| Das Unternehmen (ggf. die Unternehmens-/Bietergemeinschaft) hat dem Auftraggeber spätestens vor einer beabsichtigten Zuschlagserteilung eine Bescheinigung über eine Betriebshaftpflichtversicherung mit einer Deckungssumme von Personenschäden mind. 1.000.000 Euro, sonstige Schäden mind. EUR 500.000 Euro vorzulegen. Sollte die Bescheinigung nicht mit Angebotsabgabe vorgelegt werden, ist dem Angebot eine formlose Zusicherung beizufügen, wonach der Bieter die entsprechende Versicherungsbescheinigung im Falle einer beabsichtigten Zuschlagserteilung vorlegt. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium: • bei vollumfänglicher Zusicherung des Versicherungsabschlusses vor Zuschlag sowie Einreichung der Versicherungsbestätigung oder bei bereits bestehender Versicherung in ausreichendem Deckungsumfang: Kriterium erfüllt | |||||
| IV. Technische und berufliche Leistungsfähigkeit | ||||||||
| 1. Angaben zur Anzahl der durchschnittlichen Beschäftigtenzahl | ||||||||
| Anzahl der durchschnittlich jährlich Beschäftigten des Unternehmens in den Geschäftsjahren 2023, 2024, nachzuweisen durch formlose Angabe im Angebot. Hinweis: Bei Unternehmens-/Bietergemeinschaften und/oder dem beabsichtigten Einsatz von Unterauftragnehmern hat jedes Mitglied die Angaben gesondert zu machen. Im Rahmen der Auswertung werden die Zahlen von allen Mitgliedern des Unternehmen-/Bieterkonsortiums aufsummiert. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern zutreffend | A-Kriterium: Kriterium nicht erfüllt bei < 30 Beschäftigten oder keine Nennung | |||||
| 2. Konzept zur Digitalen Souveränität | ||||||||
| Das Unternehmen hat ein Kurzkonzept vorzulegen, das darlegt, wie die unmittelbar für die Leistungserbringung eingesetzten Werkzeuge und Ressourcen dazu beitragen, die Anforderungen der IT-Architekturrichtlinie „AV-09 Digitale Souveränität“ des Bundes zu erfüllen. Beispiele hierfür sind etwa der Einsatz von Open-Source-Software, die nachweisbare Datenhaltung innerhalb der EU, Einsatz von on-premise Lösungen, eine Unabhängigkeit oder mindestens eine Multi-Vendor-Strategie für kritische oder proprietäre Komponenten. Hinweis: Bei Unternehmens-/Bietergemeinschaften und/oder dem beabsichtigten Einsatz von Unterauftragnehmern hat jedes Mitglied die Angaben gesondert zu machen. Im Rahmen der Auswertung werden die Zahlen von allen Mitgliedern des Unternehmen-/Bieterkonsortiums aufsummiert. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern zutreffend | A-Kriterium; • Konzept erfüllt im Kern die für Auftragnehmende relevante Vorgaben aus der IT-Architekturrichtlinie des Bundes AV-09 Digitale Souveränität und benennt Entscheidungen, Werkzeuge und Ressourcen, die dazu beitragen, diese Vorgaben zu erfüllen. • die Vorgaben aus der Richtlinie werden nicht eingehalten oder die getroffenen Entscheidungen, eingesetzter Werkzeuge und Ressourcen zur Erfüllung der Vorgaben werden nicht genannt: Kriterium nicht erfüllt | |||||
| 3. Nachweis über durchgeführte Projekte mit relevanten Technologien und Techniken | ||||||||
| Die Bieterin verfügt über nachgewiesene Kenntnisse und praktische Erfahrung im Einsatz des Web‑Frameworks Spring Boot. Als Nachweis ist die Beschreibung mindestens eines erfolgreich abgeschlossenen Projekts einzureichen, in dessen Rahmen die Bieterin Spring Boot eingesetzt hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem Spring Boot eingesetzt wurde - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| Die Bieterin verfügt über nachgewiesene Kenntnisse und praktische Erfahrung im Einsatz des Web‑Frameworks AngularJS. Als Nachweis ist die Beschreibung mindestens eines erfolgreich abgeschlossenen Projekts einzureichen, in dessen Rahmen die Bieterin AngularJS eingesetzt hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem AngularJS eingesetzt wurde - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| Die Bieterin verfügt über nachgewiesene Kenntnisse und praktische Erfahrung im Umgang mit PostgreSQL. Als Nachweis die Beschreibung mindestens eines erfolgreich abgeschlossenen Projekts einzureichen, in dessen Rahmen die Bieterin PostgreSQL eingesetzt hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem PostgreSQL eingesetzt wurde - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| Die Bieterin verfügt über nachgewiesene Kenntnisse und praktische Erfahrung in der Containerisierung mit Docker. Als Nachweis ist die Beschreibung mindestens eines erfolgreich abgeschlossenen Projekts einzureichen, in dessen Rahmen die Bieterin Docker eingesetzt hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem Docker eingesetzt wurde - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| Die Bieterin verfügt über nachgewiesene Kenntnisse und praktische Erfahrung in der Build‑Automatisierung mit CI/CD (z.B. GitLab CI/CD). Als Nachweis ist die Beschreibung mindestens eines erfolgreich abgeschlossenen Projekts einzureichen, in dessen Rahmen die Bieterin CI/CD eingesetzt hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem Build-Automatisierung mit CI/CD-Werkzeugen (z.B. GitLab CI/CD) eingesetzt wurde - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| Die Bieterin verfügt über Erfahrung in der Entwicklung oder Betreuung eines Software Development Kits (SDK). Als Nachweis ist die Beschreibung mindestens eines Projekts einzureichen, das die Bieterin innerhalb der letzten drei Jahre durchgeführt hat und in dessen Rahmen sie ein SDK entwickelt, weiterentwickelt oder betreut hat. Der Nachweis kann – sofern verfügbar – auch durch einen Verweis auf einen entsprechenden Software-Code ergänzt werden, der dem Angebot als ZIP-Datei beizufügen ist. | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; Das Kriterium gilt als erfüllt, wenn die folgenden Angaben vollständig und in den bereitgestellten Vorlagen „Referenzprojekte“ bzw. „Repository“ eingereicht werden und - mindestens ein Projekt beschrieben wird, in dem ein Software Development Kit entwickelt, weiterentwickelt, oder betreut wurde, - eine nachvollziehbare Kurzbeschreibung des Projekts enthalten ist (Ziel, Umfang, Zeitraum, Rolle der Bieterin) - die konkreten Tätigkeiten der Bieterin klar dargestellt sind - die verwendete Software angegeben wurde - der erfolgreiche Abschluss des Projekts erkennbar beschrieben ist - optional ein Software-Code als ZIP-Datei eingereicht wird, sofern verfügbar. (Hinweis: Für jedes eingereichte Code‑Repository muss in der „Repository“-Vorlage zwingend auf eine konkrete Version (Commit‑Hash) verwiesen werden, damit eindeutig nachvollziehbar ist, welche Codebasis Bestandteil des Angebots ist.) | |||||
| V. Verpflichtungserklärungen sowie weitere Erklärungen | ||||||||
| 1. Beherrschung der deutschen Sprache durch das eingesetzte Personal | ||||||||
| Alle Mitarbeiterinnen und Mitarbeiter, welche für die Ausführung der zu vergebenden Leistungen vorgesehen werden, d.h. inklusive vorgesehener Vertretung, müssen die deutsche Sprache fließend in Wort und Schrift beherrschen. Sollte das im Einzelfall nicht so sein, trägt das Unternehmen die Kosten für dadurch entstehende Mehraufwände. Sichern Sie dies zu? | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; bei Zusicherung: Kriterium erfüllt | |||||
| 2. Kontinuierlicher Einsatz des aufgeführten Personals | ||||||||
| Sollte während der Vertragslaufzeit ein Austausch der für die Leistungserbringung vorgesehenen bzw. bereits eingesetzten Personen notwendig sein, so muss eine ebenso qualifizierte Ersatzperson zum Einsatz kommen. Der Austausch einer Person ist dem Auftraggeber mindestens 2 Wochen im Voraus anzuzeigen und zu begründen. Sichern Sie dies zu? | A | Unternehmen; Mitglieder einer Unternehmens-/Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; bei Zusicherung: Kriterium erfüllt | |||||
| 3. Verpflichtung gemäß Verpflichtungsgesetz | ||||||||
| Stimmen Sie den Bestimmungen zur Verpflichtung gemäß Verpflichtungsgesetz vom 2. März 1974, BGBI.I S.469, G47 zu? Hinweis: Wenn ersterem zugestimmt wird, muss im Fall des Zuschlags ergänzend hierzu seitens des Unternehmens und jedem Mitglied das Unternehmen-/ Bietergemeinschaft, Unterauftragnehmer, das Personal für das Projekt stellt, die Erklärung „Verpflichtung auf die Vertraulichkeit“ (gesonderte Anlage) rechtskräftig unterzeichnet werden. Sämtliche eingesetzte Mitarbeiter, die an geheim zu schützenden Daten arbeiten, müssen belehrt und verpflichtet werden. | A | Unternehmen oder bevollmächtigter Vertreter einer Unternehmens-/Bietergemeinschaft | A-Kriterium; bei Zusicherung: Kriterium erfüllt | |||||
| 4. Bietergemeinschaft/Eignungsleihe-Erklärung | ||||||||
| „Bietergemeinschaft/Eignungsleihe-Erklärung" wurde, sofern zutreffend, ausgefüllt und von allen Mitgliedern der Unternehmens-/Bietergemeinschaft unterzeichnet. | A | Unternehmen/Mitglieder einer Unternehmens-/Bietergemeinschaft nur bei der beabsichtigten Bildung einer Unternehmens-/Bietergemeinschaft, sofern zutreffend | A-Kriterium nur bei der beabsichtigten Bildung einer Unternehmens-/Bietergemeinschaft zutreffend; bei vollumfänglicher Ausfüllung und Unterschrift durch jedes Mitglied Das Unternehmens-/Bietergemeinschaft: Kriterium erfüllt, | |||||
| Im Fall des beabsichtigten Einsatzes von Unterauftragnehmern bzw. der Eignungsleihe in Verbindung mit Unterauftragnehmerrn wurde, sofern zutreffend, die "Erklärung Unterauftragnehmer/Eignungsleihe" ausgefüllt und unterzeichnet eingereicht. | A | Unterauftragnehmer im Falle der Eignungsleihe, sofern zutreffend | A-Kriterium nur bei der beabsichtigten Eigungsleihe zutreffend; bei vollumfänglicher Ausfüllung und Unterschrift: Kriterium erfüllt. | |||||
| Bitte füllen Sie die Erklärung "Eigenerklärung" aus und legen diese bei. | A | Unternehmen; Mitglieder einer Unternehmen-/ Bietergemeinschaft und/oder Unterauftragnehmer im Falle der Eignungsleihe, sofern diese Personal für den Auftrag stellen | A-Kriterium; bei Vorlage der ausgefüllten Erklärung: Kriterium erfüllt. | |||||
| Alle Kriterien erfüllt? | Nein |
Wertungskriterien (B)
| Wertungskriterien für das fachliche Angebot (B) | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 | Erreichbare Gesamtpunktzahl | Unnamed: 10 | 1300 | 0 | Unnamed: 13 | Unnamed: 14 | Unnamed: 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Erreichte Punkte | 0 | ||||||||||||||
| Kriterien-hauptgruppe | Kriterien-gruppe | Kriterium | Einzelkriterium | Kriterienart | Bewertungstyp | Umfang (S/M/L) | Beantwortung | Bewertung und Gewichtung der Einzelkriterien | |||||||
| Bewertungsschema | Bewertung Kriterium | Gewichtung | Ergebnispunkte Kriterium gewichtet | ||||||||||||
| 0-3 Punkte | 4-7 Punkte | 8-10 Punkte | |||||||||||||
| I. Expertise zur Arbeit im fachlichen Kontext (XP) | Maximal erreichbare Punktzahl für I. Expertise zur Arbeit im fachlichen Kontext (XP). | 400.0 | |||||||||||||
| Erreichte Punktzahl für I. Expertise zur Arbeit im fachlichen Kontext (XP) | 0.0 | 0.0 | |||||||||||||
| XP | SDK | Konzept zur nachhaltigen Betreuung, Weiterentwicklung und Dokumentation des SDK (Los 1) | Maximal erreichbare Punktzahl für XP.SDK | 400.0 | |||||||||||
| XP | SDK | XP.SDK.1 | Gefordert wird ein Konzept, das beschreibt, wie die Bieterin das SDK fachlich und technisch betreuen, weiterentwickeln und für die Nutzenden (andere Auftragnehmende) zugänglich machen möchte. Das Konzept soll zeigen, wie die Bieterin sicherstellt, dass das SDK langfristig stabil, gut wartbar und für externe Entwickler*innen leicht nutzbar bleibt. Behandelt werden sollten zumindest: 1) Wartung, Weiterentwicklung und Stabilität des SDK, insb. die - Schlüssigkeit des Wartungs‑ und Release‑Prozesses, - Qualitätssicherung und technische Stabilität, - Transparenz und Nachvollziehbarkeit der geplanten Entwicklung, - Einbindung der SDK‑Nutzenden für eine Optimierung der Planungen. 2) Pflege und Verbesserung der SDK‑Dokumentation, insb. die - Ansätze zur Verbesserung der Struktur, Verständlichkeit und Nutzbarkeit der Dokumentation, - Prozesse zur Aktualisierung und Pflege der Dokumentation, - Unterstützung der SDK‑Nutzenden. | B | Konzept | S-M (1-2 Seiten) | Konzept des Bieters / der Bieterin | Das Konzept ist unklar formuliert und enthält nur allgemeine oder oberflächliche Ansätze. Es fehlen nachvollziehbare technische Details oder eine konkrete Strategie zur Umsetzung, sodass die Machbarkeit der Lösung nicht erkennbar ist. | Das Konzept beschreibt die technische Umsetzung in grundsätzlichen Zügen und bietet eine solide Orientierung. Es enthält wesentliche technische Aspekte, aber könnte durch detailliertere Erläuterungen zur Vorgehensweise und möglichen Herausforderungen noch verbessert werden. | Das Konzept ist klar strukturiert, gut begründet und technisch fundiert. Es beschreibt präzise, wie die Lösung umgesetzt wird, berücksichtigt relevante Anforderungen und zeigt eine durchdachte Strategie zur erfolgreichen Realisierung. | 40 | 0 | |||
| II. Expertise zur Arbeit im technischen Kontext (SKILL) | Maximal erreichbare Punktzahl für II. Expertise zur Arbeit im technischen Kontext (SKILL). | 900.0 | |||||||||||||
| Erreichte Punktzahl für II. Expertise zur Arbeit im technischen Kontext (SKILL) | 0.0 | 0.0 | |||||||||||||
| SKILL | PoC | Kreative und effektive Ansätze zur Beschleunigung von Softwareentwicklung | Maximal erreichbare Punktzahl für SKILL.PoC | 300.0 | |||||||||||
| SKILL | PoC | SKILL.PoC.1 | Gefordert wird ein Kurzkonzept, das beschreibt, wie die Bieterin innovative technische Ansätze einsetzt, um die Softwareentwicklungsprozesse effizient, stabil und qualitativ hochwertig zu gestalten. Das Konzept soll insbesondere darstellen, wie moderne Technologien, Werkzeuge oder Methoden genutzt werden, um die besonderen Anforderungen des Projekts zu unterstützen: kurze Umsetzungszeiträume, präzise Umsetzung komplexer fachlicher Berechnungen (z. B. Emissionsformeln) sowie jährliche Weiterentwicklungszyklen mit paralleler Entwicklung neuer Fachverfahren. Eingangen werden soll insbesondere auf: - den Beitrag zur Beschleunigung kurzer Entwicklungszyklen durch die vorgeschlagenen Techniken und Technologien - die Unterstützung bei der korrekten Umsetzung komplexer fachlicher Logik - die Eignung für jährliche Weiterentwicklungszyklen und parallele Projekte. | B | Konzept | S-M (1-2 Seiten) | Konzept des Bieters / der Bieterin | Das Konzept ist unklar formuliert und enthält nur allgemeine oder oberflächliche Ansätze. Es fehlen nachvollziehbare technische Details oder eine konkrete Strategie zur Umsetzung, sodass die Machbarkeit der Lösung nicht erkennbar ist. | Das Konzept beschreibt die technische Umsetzung in grundsätzlichen Zügen und bietet eine solide Orientierung. Es enthält wesentliche technische Aspekte, aber könnte durch detailliertere Erläuterungen zur Vorgehensweise und möglichen Herausforderungen noch verbessert werden. | Das Konzept ist klar strukturiert, gut begründet und technisch fundiert. Es beschreibt präzise, wie die Lösung umgesetzt wird, berücksichtigt relevante Anforderungen und zeigt eine durchdachte Strategie zur erfolgreichen Realisierung. | 30 | 0 | |||
| SKILL | DEV | Fähigkeit zur schnellen Einarbeitung in eine bestehende Codebasis | Maximal erreichbare Punktzahl für SKILL.DEV | 300.0 | |||||||||||
| SKILL | DEV | SKILL.DEV.1 | Die Bieterin stellt für ihre Einreichung jeweils einen Fork der bereitgestellten Beispielanwendung als ZIP-Datei bereit – bestehend aus einem Frontend‑Repository und einem Backend‑Repository. Der Zugriff auf die GitLab‑Instanz (einschließlich Beispielanwendung, SDK und Dokumentation) wird bei Bedarf gewährt. In beiden Forks sind die durchgeführten Arbeiten wie folgt zu dokumentieren: - README‑Dateien im Markdown‑Format, die eine nachvollziehbare Veränderungshistorie enthalten; ergänzend können Screenshots verwendet werden. - Aussagekräftige Commit‑Messages in der Git‑Historie, die das Vorgehen transparent machen. - Vollständige Ausfüllung der Vorlage „Code‑Repository“ für jedes Repository. Die Bieterin soll anhand der Dokumentation nachvollziehbar darstellen, dass sie: - die bereitgestellte Codebasis ausführen konnte, - eine von ihr frei gewählte Funktionalität oder Variable im Datenmodell konzeptionell ändern kann, - diese Änderung sowohl im Backend als auch im Frontend umsetzen und sichtbar machen kann. Es wird ausdrücklich keine Vorgabe zur Art der Änderung gemacht; es soll keine Arbeitsleistung im Sinne einer produktiven Weiterentwicklung erbracht werden. Sollte es der Bieterin aus nachvollziehbaren und nicht selbst verschuldeten Gründen nicht möglich sein, den bereitgestellten Code auszuführen, wird dies bei der Bewertung berücksichtigt; in diesem Fall wird die konzeptionelle Darstellung bewertet. | B | Code-Repositories | L (mehrere Repositories) | Code-Repositories | Es ist kein oder nur ein sehr unvollständiger Versuch erkennbar, das Projekt umzusetzen. Die Ergebnisse bleiben weit hinter den Erwartungen zurück, und eine strukturierte Dokumentation fehlt gänzlich. | Das Projekt wurde teilweise oder mit gewissen Mängeln umgesetzt. Einige Schritte sind zwar ausgeführt worden, aber entweder nicht vollständig, nicht stabil oder nicht sauber dokumentiert. Es ist ein Bemühen erkennbar, jedoch mit sichtbaren Defiziten in der Ausführung oder Qualität. | Das Projekt wurde erfolgreich und überzeugend umgesetzt. Alle geforderten Schritte sind ausgeführt worden. Die Dokumentation ist klar strukturiert und verständlich, sodass der Projektfortschritt gut nachvollzogen werden kann. Der Gesamteindruck ist sehr positiv. | 30 | 0 | |||
| SKILL | CICD | Automatisierung und Qualitätssicherung | Maximal erreichbare Punktzahl für SKILL.CICD | 300.0 | |||||||||||
| SKILL | CICD | SKILL.CICD.1 | Gefordert wird ein Konzept, das beschreibt, wie die Bieterin kleinere Aktualisierungen von Software‑Dependencies (z. B. Patches, Sicherheitsupdates, Minor‑Releases) automatisiert erkennt, validiert und integriert. Das Konzept soll darstellen, wie Containerisierung mit Docker und Build‑Automatisierung mit GitLab CI/CD genutzt werden, um Aktualisierungen sicher, stabil und reproduzierbar bereitzustellen. Eingegangen werden soll u. a. auf: - Automatisierungsgrad des Update‑Prozesses - Qualitätssicherung und Stabilität - Umgang mit Risiken und Fehlern - Einsatz von Containerisierung und CI/CD - Transparenz, Nachvollziehbarkeit und Dokumentation | B | Konzept | S-M (1-2 Seiten) | Konzept des Bieters / der Bieterin | Das Konzept ist unklar formuliert und enthält nur allgemeine oder oberflächliche Ansätze. Es fehlen nachvollziehbare technische Details oder eine konkrete Strategie zur Umsetzung, sodass die Machbarkeit der Lösung nicht erkennbar ist. | Das Konzept beschreibt die technische Umsetzung in grundsätzlichen Zügen und bietet eine solide Orientierung. Es enthält wesentliche technische Aspekte, aber könnte durch detailliertere Erläuterungen zur Vorgehensweise und möglichen Herausforderungen noch verbessert werden. | Das Konzept ist klar strukturiert, gut begründet und technisch fundiert. Es beschreibt präzise, wie die Lösung umgesetzt wird, berücksichtigt relevante Anforderungen und zeigt eine durchdachte Strategie zur erfolgreichen Realisierung. | 30 | 0 |
Bewertungsschema
| Unnamed: 0 | Typ | Beantwortung | 0-3 Punkte | 4-7 Punkte | 8-10 Punkte |
|---|---|---|---|---|---|
| Referenzprojekt | Profil des Projekts | Das Kurzprofil enthält nur oberflächliche Informationen und zeigt keine klare Expertise im jeweiligen Bereich. Die Darstellungen lassen eine Sicherstellung der geforderten Leistungen nicht erkennen. Falls vorhanden, sind Code-Repositories schlecht dokumentiert, enthalten unstrukturierte oder unvollständige Implementierungen und zeigen keinen klaren Ansatz. Die Code-Qualität ist schwer einschätzbar. | Das Kurzprofil gibt eine solide Übersicht über bisherige Projekte und Fachkenntnisse. Es zeigt grundlegende Eignung für den Auftrag. Falls vorhanden, enthalten Code-Repositories Code mit einer grundlegenden Struktur und minimnalen Dokumentation. Die Lösungsansätze sind verständlich. | Das Kurzprofil ist klar strukturiert und gut formuliert. Es werden Fachwissen deutlich und wie diese Expertise angewandt wurde. Die Relevanz für den Auftrag ist eindeutig, der Kontext entspricht dem der geforderten Leistung. Idealerweise waren die Leistungen wesentlich für die Aufgabenerfüllung einer öffentlichen Auftraggeberin und mit dem fachlichen Kontext der DEHSt vergleichbar. Falls vorhanden, enthalten Code-Repositories leicht nachvollziehbaren Code und Dokumentation mit einer guten Balance aus Ausführlichkeit und Prägnanz, unterstützt durch eine klare Struktur. Code und Dokumentation folgen dabei etablierten Best Practices. | |
| Konzept | Konzept des Bieters / der Bieterin | Das Konzept ist unklar formuliert und enthält nur allgemeine oder oberflächliche Ansätze. Es fehlen nachvollziehbare technische Details oder eine konkrete Strategie zur Umsetzung, sodass die Machbarkeit der Lösung nicht erkennbar ist. | Das Konzept beschreibt die technische Umsetzung in grundsätzlichen Zügen und bietet eine solide Orientierung. Es enthält wesentliche technische Aspekte, aber könnte durch detailliertere Erläuterungen zur Vorgehensweise und möglichen Herausforderungen noch verbessert werden. | Das Konzept ist klar strukturiert, gut begründet und technisch fundiert. Es beschreibt präzise, wie die Lösung umgesetzt wird, berücksichtigt relevante Anforderungen und zeigt eine durchdachte Strategie zur erfolgreichen Realisierung. | |
| Kundenreferenz | Referenzen oder Testimonials von Projektbeteiligten | Die Referenzen sind vage oder wenig aussagekräftig. Es gibt keine konkreten Hinweise auf die Qualität der geleisteten Arbeit oder die Zufriedenheit der Beteiligten mit dem Ergebnis. Die Eignung für zukünftige Projekte bleibt unklar. | Die Referenzen geben eine solide, aber nicht besonders konkrete Einschätzung der geleisteten Arbeit. Die Zufriedenheit der Beteiligten wird erkennbar. | Die Referenzen sind präzise, positiv und vermitteln ein klares Bild der Fachkompetenz und der erfolgreichen Projektumsetzung. Sie bestätigen die Relevanz der bisherigen Erfahrung und geben vertrauenswürdige Hinweise auf die hohe Qualität der Leistung. | |
| Erklärung | Selbsterklärung | Keine oder nicht nachvollziehbare Ausführung vorhanden. | Ausführungen sind vorhanden, aber lückenhaft oder nur ansatzweise geeignet. | Eindeutige und nachvollziehbare Ausführungen vorhanden. | |
| Code-Repositories | Code-Repositories | Es ist kein oder nur ein sehr unvollständiger Versuch erkennbar, das Projekt umzusetzen. Die Ergebnisse bleiben weit hinter den Erwartungen zurück, und eine strukturierte Dokumentation fehlt gänzlich. | Das Projekt wurde teilweise oder mit gewissen Mängeln umgesetzt. Einige Schritte sind zwar ausgeführt worden, aber entweder nicht vollständig, nicht stabil oder nicht sauber dokumentiert. Es ist ein Bemühen erkennbar, jedoch mit sichtbaren Defiziten in der Ausführung oder Qualität. | Das Projekt wurde erfolgreich und überzeugend umgesetzt. Alle geforderten Schritte sind ausgeführt worden. Die Dokumentation ist klar strukturiert und verständlich, sodass der Projektfortschritt gut nachvollzogen werden kann. Der Gesamteindruck ist sehr positiv. | |
| Ein Kurzkonzept zum Einsatz von innovativen technischen Möglichkeiten zur Verbesserung von Softwareentwicklungsprozessen, die geprägt sind von kurzen Umsetzungszeiträumen (wenige Monate), präzisen Umgang mit komplexen Sachverhalten (Umsetzung von Berechnungsformeln von Emissionen) und jährlichen Weiterentwicklungszyklen (alte Fachverfahren werden jährlich angepasst und neue werden parallel dazu aufgebaut). | |||||
| Links zu jeweils einem Fork unseres Beispielanwendung (bestehend jeweils einem aus Repository für Front- und Backend - Zugriff auf unsere GitLab Instanz wird auf Anfrage gewährt, darin ist das SDK, also der notwendige Code und die Dokumentation enthalten) auf unserer GitLab-Instanz, darin jeweils eine Kurzbeschreibung der durchgeführten Arbeiten in Form von Readme-Dateien im Markdown-Format und Commit-Messages in der git-Historie. |