Kriterienkatalog
| Unnamed: 0 | Forderungs- (F) und Bewertungskriterien (B) Legende: F = Forderungskriterium (Muss-Anforderung; Nichterfüllung führt zum Ausschluss). B = Bewertungskriterium (die in Spalte E genannte Mindestforderung muss erfüllt sein; darüber hinausgehende Eigenschaften werden nach der Ankerskala im Blatt „Erläuterung_Bewertung“ mit Punkten bewertet). Nachweisführung: Für jedes Kriterium ist der in Spalte G genannte Nachweis vorzulegen. Fundstellen in der Herstellerdokumentation sind mit Dokument, Version und Seite/Abschnitt anzugeben. Die Wertungsentscheidung je B-Kriterium ist in Spalte K zu begründen. | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Unnamed: 8 | Unnamed: 9 | Unnamed: 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| Nr. | Typ | Kriterium / Anforderung | Mindestforderung (bei B) | Bewertung positiv (bei B) – Bewertungsgesichtspunkte und Messgrößen | Nachweis | Max. Punkte | (Mindest-)Forderungs-kriterium erfüllt? | Erreichte Punkte | Begründung / Quelle (Fundstelle) | |
| 1. Unterstützte Optimierungsproblemklassen | ||||||||||
| F 1.1 | F | Lineare Optimierung (LP), einschließlich sehr großskalige, dünn besetzte Probleminstanzen | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.2 | F | Gemischt-ganzzahlige lineare Optimierung (MILP) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.3 | F | Quadratische Optimierung (QP), konvex und nichtkonvex | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.4 | F | Gemischt-ganzzahlige quadratische Optimierung (MIQP), konvex und nichtkonvex | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.5 | F | Quadratisch restringierte Optimierung (QCP), konvex und nichtkonvex | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.6 | F | Gemischt-ganzzahlige quadratisch restringierte Optimierung (MIQCP), konvex und nichtkonvex | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.7 | F | Second-Order Cone Programming (SOCP) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 1.8 | F | Allgemeine nichtlineare Optimierung (NLP/MINLP): Algorithmen für lokale und/oder globale Optimalität und/oder unterstützende Workflows (Approximationen), soweit anwendbar | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| 2. Deployment, Infrastruktur und Betrieb | ||||||||||
| F 2.1 | F | Einsatz in institutsbetriebener lokaler Hochleistungsrechenumgebung (HPC) möglich | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 2.2 | F | Unterstützung eingeschränkter Netzwerkumgebungen einschließlich Offline- bzw. air-gapped-Betrieb | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 2.3 | F | Keine zwingende Abhängigkeit von durch den Anbieter betriebenen Cloud-Diensten für Lizenzierung, Nutzungskontrolle oder Betrieb | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| 3. Skalierung, Parallelisierung und Lizenzmodell | ||||||||||
| F 3.1 | F | Lizenzmodell ermöglicht die Durchführung von mindestens 2.000 gleichzeitigen Solver-Läufen innerhalb eines einzelnen Instituts, gesteuert über einen lokal betriebenen Lizenz- bzw. Token-Server | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 3.2 | F | Bereitstellung eines lokal durch das jeweilige Institut betriebenen Lizenz- oder Token-Servers; keine institutsübergreifende gemeinsame Nutzung von Lizenzservern oder Lizenzkontingenten | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 3.3 | F | Mehrkern- bzw. Multi-Thread-Fähigkeit pro Rechenlauf | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 3.4 | F | Angabe des Bieters, ob die Lösung das GPU-beschleunigte Lösen sehr großer, dünn besetzter LPs auf institutseigener Infrastruktur unterstützt, einschließlich Darstellung etwaiger Einschränkungen sowie erforderlicher Hardwarevoraussetzungen | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| B 3.1 | B | Umfang der GPU-Beschleunigung | Angabe gemäß F 3.4 liegt vor. | Tatsächlich verfügbare GPU-Beschleunigung für sehr große, dünn besetzte LPs (>1 Mio. Variablen und >1 Mio. Nebenbedingungen); dokumentierte Performance-Gewinne ggü. konventionellem CPU-basierten Barrier-Verfahren. Messgrößen: Speed-up (Laufzeit GPU zu Laufzeit CPU-Barrier) bei identischer Instanz, identischem Zeitlimit und identischer Toleranz; Steuerbarkeit der GPU-Nutzung über die API; dokumentierte Hardwarevoraussetzungen. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 10 | ||||
| B 3.2a | B | Effizienz der Multi-Thread-Parallelisierung pro Rechenlauf (LP) | Multi-Thread-Fähigkeit gemäß F 3.3 ist für LP-Probleme gegeben. | Nachweisbarer Speed-up bei der Lösung von LP-Problemen durch zunehmende Thread-Anzahl (z. B. paralleles Ausführen mehrerer Verfahren, „concurrent optimizer“). Messgrößen: Speed-up bei 1 zu 8 zu 16 Threads auf identischer Instanz; Steuerbarkeit der Thread-Anzahl über API bzw. Parameter. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 5 | ||||
| B 3.2b | B | Effizienz der Multi-Thread-Parallelisierung pro Rechenlauf (MIP) | Multi-Thread-Fähigkeit gemäß F 3.3 ist für MIP-Probleme gegeben. | Nachweisbarer Speed-up bei der Lösung von MIP-Problemen durch zunehmende Thread-Anzahl (z. B. paralleles Branch-and-Bound). Messgrößen: Speed-up bis zum Erreichen einer festgelegten relativen Lücke bei 1 zu 8 zu 16 Threads; deterministisches Verhalten unter Multi-Threading. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 5 | ||||
| B 3.3 | B | Umfang der gleichzeitig nutzbaren Solver-Läufe (Tokens) | Mindestens 2.000 gleichzeitige Solver-Läufe gemäß F 3.1. | Höhere Anzahl gleichzeitig nutzbarer Solver-Läufe bzw. Tokens; Zielwert 4.000 oder mehr wird besonders positiv bewertet. Flexibilität des Lizenzmodells bei Skalierung und Verteilung der Tokens innerhalb des Instituts wird ergänzend berücksichtigt. Messgrößen: vertraglich zugesicherte Anzahl gleichzeitiger Läufe; Umverteilbarkeit der Tokens zwischen Rechenumgebungen ohne Mehrkosten. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Bietererklärung; Auszug aus dem Lizenzvertrag | 10 | ||||
| 4. Schnittstellen und Integration | ||||||||||
| F 4.1 | F | Verfügbarkeit von APIs für: Python, Java, C/C++, .NET, R, MATLAB | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 4.2 | F | Unterstützung effizienter, matrixorientierter Modellierungsansätze zum Aufbau mathematischer Modelle auf matrixbasierten Objekten (mindestens innerhalb der Python-API) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 4.3 | F | Unterstützung etablierter Modellaustauschformate (z. B. LP/MPS) einschließlich Import und Export von Modellen, auch in anonymisierter Form | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 4.4 | F | Automatisierbare Ausführung in Batch- und Pipeline-Workflows | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| 5. Solver-Funktionalitäten | ||||||||||
| F 5.1 | F | Unterstützung von Rückruffunktionen (Callbacks) sowie strukturierter Protokollierung (Logging) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.2 | F | Export und Import von Solver-Parametern sowie Funktionen für systematisches Parametertuning | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.3 | F | Unterstützung von Warmstarts und Advanced Starts, soweit anwendbar | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.4 | F | Export von Lösungen in maschinenlesbaren Formaten | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.5 | F | Bereitstellung eines Lösungspools bzw. mehrerer zulässiger Lösungen, soweit anwendbar | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.6 | F | Gleichzeitige Berechnung verschiedener Szenarien in einem Optimierungslauf | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 5.7 | F | Systematische Analyse und Vorschläge zur Auflösung von Unzulässigkeiten (Infeasibilities) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| B 5.1 | B | Funktionsumfang Infeasibility-Analyse | Funktion gemäß F 5.7 ist vorhanden. | Tiefe und Bedienkomfort der Diagnosewerkzeuge (z. B. Bestimmung einer minimalen unzulässigen Teilmenge von Restriktionen – IIS bzw. Conflict Refinement –, automatisierte Relaxierungsvorschläge, Visualisierungs- oder Reportingfunktionen). Messgrößen: Zeit bis zum Vorliegen der unzulässigen Teilmenge; Kardinalität der ermittelten Teilmenge (kleiner ist besser); Zugriff über die native API statt nur über Dateiexport; Reproduzierbarkeit über mehrere Läufe. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 10 | ||||
| B 5.2 | B | Funktionsumfang Lösungspool und Mehrlösungs-Workflows | Funktion gemäß F 5.5 ist vorhanden. | Konfigurierbarkeit (z. B. Anzahl, Diversität, Qualitätsgrenzen der Lösungen), Performance-Eigenschaften. Messgrößen: Anzahl gefundener zulässiger Lösungen bei fixem Zeitlimit und vorgegebener Qualitätsschranke (relative Lücke); mittlerer paarweiser Abstand der Lösungsvektoren als Diversitätsmaß; Steuerbarkeit über die API. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 10 | ||||
| B 5.3 | B | Funktionsumfang gleichzeitige Szenarienberechnung | Funktion gemäß F 5.6 ist vorhanden. | Anzahl gleichzeitig handhabbarer Szenarien, Effizienz gegenüber sequenzieller Lösung, Integration in die APIs. Messgrößen: maximale Szenarienzahl je Lauf; variierbare Modellbestandteile (rechte Seite, Schranken, Zielfunktionskoeffizienten, Matrixkoeffizienten); Speed-up gegenüber sequenziellem Neulösen mit Warmstart bei identischer Szenarienmenge. Punktvergabe nach Ankerskala (Blatt „Erläuterung_Bewertung“). | Fundstelle in der Herstellerdokumentation; Kurzkonzept (max. 2 S.); Teststellung | 10 | ||||
| 6. Lizenzgrenzen und Nutzungsrechte | ||||||||||
| F 6.1 | F | Separates License Agreement pro Institut, mindestens eine Lizenz je Institut; jedes Institut betreibt einen eigenen, lokal installierten Lizenz- bzw. Token-Server auf institutseigener Infrastruktur. Eine gemeinsame Nutzung von Lizenzen, Tokens oder Lizenzservern über mehrere Institute hinweg ist ausgeschlossen. | — | — | Bietererklärung; Auszug aus dem Lizenzvertrag | — | — | |||
| F 6.2 | F | Nutzungsberechtigung begrenzt auf namentlich benannte Nutzer, affiliiert zum Institut | — | — | Bietererklärung; Auszug aus dem Lizenzvertrag | — | — | |||
| F 6.3 | F | Zur Nutzung berechtigt sind ausschließlich Mitarbeitende des jeweiligen Instituts; eine Nutzung durch externe Dritte ist ausgeschlossen | — | — | Bietererklärung; Auszug aus dem Lizenzvertrag | — | — | |||
| F 6.4 | F | Betrieb mit vertraulichen Projekt- und Kundendaten auf institutseigener Infrastruktur uneingeschränkt möglich; keine verpflichtende Übertragung von Modelldaten, Instanzen, Parametern oder Protokollen an durch den Anbieter betriebene Systeme | — | — | Bietererklärung; Auszug aus dem Lizenzvertrag | — | — | |||
| 7. Reproduzierbarkeit und Nachvollziehbarkeit | ||||||||||
| F 7.1 | F | Deterministisches Lösungsverhalten, einschließlich deterministisches Verhalten unter Multi-Threading, soweit technisch möglich | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 7.2 | F | Eindeutige Identifikation der eingesetzten Softwareversion (z. B. Version, Build-Information) über APIs und/oder in Protokollen | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 7.3 | F | Export und Import von Solver-Parametern zur Reproduktion identischer Konfigurationen | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 7.4 | F | Eindeutige Identifikation von Modellen bzw. Instanzen (z. B. durch Fingerprints oder vergleichbare Mechanismen) | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| F 7.5 | F | Export von Lösungen sowie Protokollen in maschinenlesbaren Formaten zur externen Analyse und Überprüfung | — | — | Bietererklärung; Fundstelle in der Herstellerdokumentation | — | — | |||
| Summe Bewertungskriterien (B) | 60 | 0 | 0 | |||||||
| Hinweise zum Ausfüllen: Weiß hinterlegte Zellen sind durch die Bewertungsstelle auszufüllen. Spalte I: JA/NEIN (NEIN bei einem F-Kriterium oder bei einer Mindestforderung eines B-Kriteriums führt zum Ausschluss). Spalte J: Punktzahl gemäß Erläuterungen im Blatt „Erläuterung_Bewertung“. Spalte K: Begründung mit Fundstelle bzw. Messergebnis der Teststellung – je B-Kriterium zwingend, da die Vergabeentscheidung hierüber dokumentiert wird. Beispiel für Spalte K (B 3.1): „Teststellung Instanz A, Laufzeit GPU 30 s gegenüber CPU-Barrier 60 s, Speed-up 2,0; Doku V12.0, Abschn. 4.3.“ Beispiel für Spalte K (B 3.3): „3.500 Tokens gemäß Angebot S. 4, d. h. 1.500 über der Mindestforderung.“ |
Erläuterung_Bewertung
| Unnamed: 0 | Ankerskala zur Punktvergabe bei den Bewertungskriterien (B) Jede Stufe schließt die Anforderungen der darunterliegenden Stufen ein. Maßgeblich ist die höchste vollständig erfüllte Stufe. Zwischenwerte sind zulässig, sofern sie in Spalte K des Kriterienkatalogs begründet werden. ACHTUNG – die gelb hinterlegten Schwellenwerte sind Vorschläge und vor Veröffentlichung der Vergabeunterlagen fachlich zu bestätigen. Sie sind so zu wählen, dass sie von mehr als einem am Markt verfügbaren Produkt erreichbar sind (Produktneutralität, § 31 Abs. 6 VgV). | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 |
|---|---|---|---|---|---|
| Kriterium | Max. Punkte | Punkte | Voraussetzung für diese Punktzahl | Messgröße / Nachweisform | |
| B 3.1 | 10 | 0 | Keine GPU-Beschleunigung verfügbar oder lediglich angekündigt. | Speed-up = Laufzeit CPU-Barrier / Laufzeit GPU auf identischer Instanz, identischem Zeitlimit und identischer Toleranz; Teststellung mit Instanzen des Auftraggebers. | |
| 2 | GPU-Beschleunigung nur als experimentelle bzw. Beta-Funktion; keine Angaben zu unterstützten Instanzgrößen. | ||||
| 4 | Produktiv freigegeben, jedoch unterhalb der Zielgröße (>1 Mio. Variablen und >1 Mio. Nebenbedingungen) oder ohne dokumentierten Speed-up. | ||||
| 6 | Produktiv freigegeben für LP der Zielgröße; dokumentierter Speed-up mindestens 1,5. | ||||
| 8 | Speed-up mindestens 3,0; GPU-Nutzung über die API steuerbar; Hardwarevoraussetzungen vollständig dokumentiert. | ||||
| 10 | Speed-up mindestens 5,0 in der Teststellung an Instanzen des Auftraggebers; zusätzlich Multi-GPU-Nutzung oder GPU-Unterstützung über reine LP hinaus. | ||||
| B 3.2a | 5 | 0 | Kein nachweisbarer Laufzeitgewinn durch zusätzliche Threads. | Speed-up bei 1 / 8 / 16 Threads auf identischer LP-Instanz; Herstellerdokumentation und Teststellung. | |
| 1 | Parallelisierung nur in einzelnen Teilschritten; kein dokumentierter Speed-up. | ||||
| 3 | Dokumentierter Speed-up beim Übergang von 8 auf 16 Threads; Thread-Anzahl über API bzw. Parameter steuerbar. | ||||
| 5 | Zusätzlich parallele Ausführung mehrerer Verfahren (concurrent); Speed-up in der Teststellung mindestens 1,5 bei 16 gegenüber 1 Thread. | ||||
| B 3.2b | 5 | 0 | Kein nachweisbarer Laufzeitgewinn durch zusätzliche Threads. | Zeit bis zum Erreichen einer festgelegten relativen Lücke bei 1 / 8 / 16 Threads; Teststellung. | |
| 1 | Parallelisierung nur in der Vorverarbeitung bzw. in Heuristiken; kein dokumentierter Speed-up im Suchbaum. | ||||
| 3 | Paralleles Branch-and-Bound mit dokumentiertem Speed-up; Thread-Anzahl steuerbar. | ||||
| 5 | Zusätzlich deterministisches Verhalten unter Multi-Threading; Speed-up in der Teststellung mindestens 3,0 bei 16 gegenüber 1 Thread. | ||||
| B 3.3 | 10 | 0 | N < 2.000 – Mindestforderung F 3.1 nicht erfüllt, Ausschluss. | Vertraglich zugesicherte Anzahl N gleichzeitiger Läufe laut Angebot bzw. Lizenzvertrag. | |
| 2 bis 8 | Anzahl der Tokens, linear interpoliert: Punkte = 2 + 6 × (N − 2.000) / 2.000, begrenzt auf 8 Punkte (N = 2.000 ergibt 2 Punkte, N = 4.000 oder mehr ergibt 8 Punkte). | ||||
| +1 | Zusatzpunkt: Tokens innerhalb des Instituts ohne Mehrkosten zwischen Rechenumgebungen umverteilbar. | ||||
| +1 | Zusatzpunkt: nachträgliche Aufstockung des Kontingents während der Vertragslaufzeit zu vorab bezifferten Konditionen möglich. | ||||
| B 5.1 | 10 | 0 | Nur Rückgabe eines Status- bzw. Fehlercodes; keine Lokalisierung der Ursache. | Zeit bis zum Vorliegen der unzulässigen Teilmenge; Kardinalität der Teilmenge (kleiner ist besser); Reproduzierbarkeit über drei Läufe; Teststellung mit unzulässigen Instanzen des Auftraggebers. | |
| 2 | Bestimmung einer unzulässigen Teilmenge nur über ein externes Werkzeug oder über Dateiexport, nicht über die native API. | ||||
| 4 | Bestimmung einer minimalen unzulässigen Teilmenge von Restriktionen über die native API, mindestens für LP. | ||||
| 6 | Zusätzlich für MIP und QP verfügbar; Rechenaufwand der Suche über Zeit- bzw. Genauigkeitsbudget steuerbar. | ||||
| 8 | Zusätzlich automatisierte Relaxierung mit wählbarer Straf-Norm und gewichteten Verletzungen; Ergebnis maschinenlesbar exportierbar. | ||||
| 10 | Zusätzlich Rückführung auf die Modellstruktur (Benennung der betroffenen Restriktionen und Variablen aus dem Modellierungsobjekt) sowie Visualisierungs- bzw. Reportingfunktion; in der Teststellung an Instanzen des Auftraggebers nachgewiesen. | ||||
| B 5.2 | 10 | 0 | Es wird ausschließlich eine Lösung zurückgegeben. | Anzahl zulässiger Lösungen innerhalb eines festgelegten Zeitlimits bei vorgegebener relativer Lücke; mittlerer paarweiser Abstand der Lösungsvektoren; Teststellung. | |
| 2 | Weitere Lösungen fallen nur als Nebenprodukt der Suche an; keine Steuerungsmöglichkeit. | ||||
| 4 | Anzahl der zu speichernden Lösungen (Poolgröße) konfigurierbar; Pool über die API auslesbar. | ||||
| 6 | Zusätzlich Qualitätsschranke konfigurierbar (absolute oder relative Lücke zum Optimum). | ||||
| 8 | Zusätzlich Suchstrategie bzw. Diversität der Lösungen steuerbar; Pool-Lösungen als Warmstart wiederverwendbar. | ||||
| 10 | Zusätzlich in der Teststellung: mindestens 10 Lösungen innerhalb des Zeitlimits bei einer relativen Lücke von höchstens 1 %, bei nachgewiesener Diversität. | ||||
| B 5.3 | 10 | 0 | Keine entsprechende Funktion; Szenarien sind ausschließlich sequenziell neu zu lösen. | Maximale Szenarienzahl je Lauf; variierbare Modellbestandteile; Speed-up gegenüber sequenziellem Neulösen mit Warmstart bei identischer Szenarienmenge; Teststellung. | |
| 2 | Nur Modifikation des Modells mit anschließendem Neulösen unter Nutzung eines Warmstarts. | ||||
| 4 | Mehrere Szenarien in einem Lauf, Variation beschränkt auf rechte Seite und Variablenschranken. | ||||
| 6 | Zusätzlich Variation von Zielfunktionskoeffizienten. | ||||
| 8 | Zusätzlich Variation von Matrixkoeffizienten bzw. Hinzufügen und Entfernen von Restriktionen; Szenarienfunktion mindestens über die Python-API vollständig zugänglich. | ||||
| 10 | Zusätzlich nachgewiesener Effizienzgewinn in der Teststellung: Speed-up mindestens 2,0 gegenüber sequenziellem Lösen bei mindestens 10 Szenarien; Ergebnisse je Szenario einzeln maschinenlesbar exportierbar. | ||||
| Gelb hinterlegte Zellen enthalten quantitative Schwellenwerte, die nicht aus der Ursprungsfassung stammen, sondern als Vorschlag ergänzt wurden. Sie sind vor Veröffentlichung fachlich zu prüfen und an die tatsächlich vorgesehenen Testinstanzen anzupassen. Alle übrigen Anker beschreiben Funktionsumfänge und sind ohne Zahlenannahmen formuliert. |