Dokumentstatus unterscheiden
Frameworks, Standards, Guidelines und Gesetze sind nicht austauschbar.
Referenzdokumente, Konformitätsanforderungen, V&V, Ressourcen und Preismodelle machen aus einer technischen Idee ein verhandelbares Proposal.
Frameworks, Standards, Guidelines und Gesetze sind nicht austauschbar.
Anwendbares EU-Recht treibt die Konformität; harmonisierte Standards sind meist freiwillige Wege.
Das Commercial Model ändert Exposure, rechtliche Haftung bleibt vertraglich.
Workstreams, Ressourcen, Material, Lead Times und Contingency müssen die Zahl erklären.
Ein belastbares Proposal verbindet Technical Solution mit Reference Basis, Verification Evidence, Ressourcen, Zeitplan, Unsicherheit und Geschäftsmodell.
Aus dem primären ukrainischen Transkript rekonstruiert. Redaktionelle Korrekturen und externe Ergänzungen sind im Material ausdrücklich markiert.
Chronologie: 16. September 2026 · fünfte Veranstaltung. Primärquelle: vollständiges Transkript. Schwerpunkt: Die Pre-Sales-Vision in eine kontrollierte Gesamtheit technischer Annahmen, regulatorischer Bezüge, Ressourcen und kommerzieller Risiken überführen.
Die Sitzung beginnt mit einer Wiederholung der didaktischen Ablaufkette:
Lead
↓
RFI
↓
RFC (Request for Clarification – Kursbegriff)
↓
Proposal / Angebot
↘
RFQ / kommerzielle Schätzung
In der wirklichen Beschaffung können die Schritte anders verlaufen, parallel ausgeführt oder unterschiedlich benannt werden. Entscheidend ist nicht die bürokratische Reihenfolge, sondern die Logik: zuerst die Aufgabe verstehen, dann den Lösungsansatz formulieren und Ressourcen und Risiken transparent abschätzen.
Bei Systemen mit Wirkung auf die physische Welt umfassen Kundenerwartungen meist mehr als die reine Funktion:
Ein Angebot benötigt daher eine Referenzgrundlage aus regulatorischen, prozessualen und technischen Dokumenten, die die Lösung beeinflussen.
Die Vorlesung schlägt folgende hilfreiche Lehrhierarchie vor:
PROZESS- / BEWERTUNGSFRAMEWORK
↓
NORMEN
↓
RICHTLINIEN / REGELSÄTZE / PRAKTIKEN
↓
PROJEKTUMSETZUNG
Dies ist nicht als universelle rechtliche Hierarchie zu verstehen: Dokumente können sehr unterschiedlichen rechtlichen oder vertraglichen Status besitzen. Zur Strukturierung technischer Überlegungen ist die Reihenfolge dennoch hilfreich.
Beantwortet überwiegend die Fragen „Welche Prozesse sind erforderlich, und wie wird ihre Fähigkeit bewertet?“
Beispiel: Automotive SPICE.
Legt Anforderungen, Prinzipien, Arbeitsprodukte oder Kriterien für ein bestimmtes Gebiet fest.
Überträgt übergeordnete Anforderungen in konkrete technische Regeln. Beispiele sind MISRA C/C++, MAAB-Gestaltungsrichtlinien und interne Projektregeln. Die Gründe für ihre Anwendung sind stets ausdrücklich anzugeben.
Im Transkript wurde ein Modell mit sieben Stufen erwähnt. Die Fähigkeitsskala des Automotive SPICE PAM 4.0 reicht tatsächlich von Level 0 bis Level 5:
| Stufe | Bezeichnung |
|---|---|
| 0 | Incomplete (unvollständig) |
| 1 | Performed (durchgeführt) |
| 2 | Managed (gesteuert) |
| 3 | Established (etabliert) |
| 4 | Predictable (vorhersagbar) |
| 5 | Innovating (innovativ) |
Offizielles VDA QMC PAM 4.0: https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf
Außerdem ist Automotive SPICE ein Modell zur Prozessbewertung und kein Zertifikat, das seinen Inhaber automatisch zur Entwicklung von Systemen bestimmter Komplexitätsklassen berechtigt.
In der mündlichen Vorlesung wurden Normen zu stark mit Gesetzen und die CE-Kennzeichnung mit einer „ISO-Zertifizierung“ gleichgesetzt.
Für die Europäische Union ist folgendes Modell präziser:
Anwendbare EU-Rechtsvorschriften = zwingende rechtliche Anforderungen
↓
harmonisierte Normen = üblicherweise freiwilliger Weg zur Konformitätsvermutung
↓
Konformitätsbewertung + technische Unterlagen + Erklärung
↓
CE-Kennzeichnung, sofern das einschlägige Recht sie verlangt
Anders ausgedrückt:
Offizielle EU-Quellen:
HARA und ASIL erscheinen erneut als Beispiel dafür, wie Risikoklassifizierung die Strenge der technischen Maßnahmen beeinflusst.
Nach ISO 26262 wird Automotive-ASIL anhand von Severity, Exposure und Controllability eingestuft. QM und ASIL A–D dürfen nicht ohne Anpassung als universelle Skala für sämtliche Industrien verstanden werden.
ISO 26262-3: https://www.iso.org/standard/68385.html
Auch Regeln wie „dynamische Speicherallokation verbieten“ oder „70 % des Speichers ungenutzt lassen“ können projekt- oder domänenspezifische Vorgaben sein. Ohne eine präzise Referenz dürfen sie nicht als ausdrücklich universelle Forderungen der ISO 26262 ausgegeben werden.
Der Kunde muss erkennen können, was gebaut werden soll und wie nachgewiesen wird, dass das Ergebnis den Bedarf erfüllt.
Nicht jede Testmethode soll mechanisch in jedes Angebot eingefügt werden. Die V&V-Strategie muss sich aus Produktrisiken, Anforderungen und den anwendbaren Prozess- und Referenzgrundlagen ergeben.
Die Schätzung eines Embedded-Projekts umfasst mindestens vier Ressourcenebenen:
| Ebene | Beispiele |
|---|---|
| Personal | Architekt, Firmware, Hardware, Mechanik, QA, Safety und Security, Management |
| Material | Bauteile, Leiterplatten, mechanische Teile, Kabelbäume, Vorrichtungen |
| Externe Leistungen | Fertigung, Bestückung, Labore, Zertifizierung oder Arbeiten zur Konformitätsbewertung |
| Zeit / Abhängigkeiten | Lieferzeiten, Versand, Zoll, Überarbeitungszyklen und Wartezeiten auf Muster |
Der Gantt-Plan und der kritische Pfad eines Embedded-Projekts hängen daher häufig von Umständen ab, die sich nicht allein durch einen weiteren Softwareentwickler beschleunigen lassen.
Die Vorlesung vergleicht zwei grundlegende Vergütungsmodelle.
Der Kunde bezahlt die tatsächliche Arbeitsleistung nach vereinbarten Sätzen und – soweit vertraglich geregelt – Material sowie externe Leistungen. Dieses Modell eignet sich bei unsicherem Umfang, Discovery, Forschung und Entwicklung und häufigen Änderungen.
Der Dienstleister verpflichtet sich, einen festgelegten Umfang zu vereinbartem Preis und vertraglichen Bedingungen fertigzustellen. Das erfordert deutlich klarere Leistungsabgrenzung, Abnahmekriterien, Annahmen und Änderungssteuerung.
Pauschale Aussagen wie „bei T&M trägt der Kunde alle Risiken“ oder „beim Festpreis trägt der Anbieter alle Risiken“ sind falsch. Rechtliche, Safety-, IP-, Haftungs-, Gewährleistungs-, Termin- und Geschäftsrisiken werden vertraglich verteilt.
Vereinfachter Vergleich:
| Risiko | T&M | Festpreis |
|---|---|---|
| Unsicherheit des Umfangs | Lässt sich durch Neupriorisierung leichter aufnehmen | Ohne Änderungsantrag riskant |
| Mehraufwand des Anbieters | Bei freigegebener Arbeit häufiger abrechenbar | Verringert häufiger die Marge des Anbieters |
| Budgetplanbarkeit für den Kunden | Geringer | Bei eingefrorenem Umfang höher |
| Bedarf an eindeutigen Abnahmekriterien | Wichtig | Entscheidend |
| Rechtliche / Haftungsrisiken | Abhängig vom Vertrag | Abhängig vom Vertrag |
In der Logik der Vorlesung ist ein Festpreis realistisch, wenn:
Sind diese Bedingungen nicht erfüllt, ist T&M oder ein phasenweises Zusammenarbeitsmodell häufig transparenter.
Eine fundierte Schätzung beginnt nicht mit „Ich glaube, das dauert drei Monate“, sondern mit einer Zerlegung der Aufgabe.
Umfang / Annahmen
↓
Arbeitsbereiche / WBS
↓
Rollen + Aufwand
↓
Material + externe Leistungen
↓
Abhängigkeiten / Lieferzeiten
↓
Risiken / Reserve
↓
kommerzielle Schätzung
Jede wesentliche Zahl braucht eine Erklärung: Woher stammt sie und welche Faktoren würden sie verändern?
Kundenbedarf
↓
Referenzgrundlage (Prozess/Framework + Normen/Recht + Richtlinien/Projektregeln)
↓
Architektur + Implementierung + V&V
↓
Ressourcen + Zeitplan + Risiken
↓
T&M / Festpreis / Hybridmodell
↓
verhandelbares Angebot
Auf ein angenommenes Angebot folgt eine weitere wichtige Veränderung: Ein Kontakt wird zum Vertrag, aus dem Vertrag müssen ein arbeitsfähiges Delivery-Team und Anforderungen werden. Die nächste Sitzung führt vom unterschriebenen Vertrag über Personalplanung, Produkt-Discovery, Business-Analyse und User Stories zu Systemanforderungen und ersten Architekturvisualisierungen.