Lehre / Vorlesung 05 · 16.09.2026

Proposal, Standards und Geschäftsmodell

Referenzdokumente, Konformitätsanforderungen, V&V, Ressourcen und Preismodelle machen aus einer technischen Idee ein verhandelbares Proposal.

16.09.2026Sitzung 05 / 06eingefroren 28.09.2026
Embedded Software Engineering / MODULE 04 · COMMERCIAL ENGINEERING / 05 · 16.09.2026
Kernideen

Kernideen

01

Dokumentstatus unterscheiden

Frameworks, Standards, Guidelines und Gesetze sind nicht austauschbar.

02

CE ist Konformität, kein generisches Zertifikat

Anwendbares EU-Recht treibt die Konformität; harmonisierte Standards sind meist freiwillige Wege.

03

T&M ≠ alle Risiken beim Kunden

Das Commercial Model ändert Exposure, rechtliche Haftung bleibt vertraglich.

04

Estimate muss nachvollziehbar sein

Workstreams, Ressourcen, Material, Lead Times und Contingency müssen die Zahl erklären.

Kernaussage

Praktische Kernaussage

Ein belastbares Proposal verbindet Technical Solution mit Reference Basis, Verification Evidence, Ressourcen, Zeitplan, Unsicherheit und Geschäftsmodell.

Als Nächstes

06 — Vom Vertrag zu Anforderungen und erster Architektur

Der Kurs wechselt von Pre-Sales zu Delivery: Staffing Lead Time, Discovery, Business Decomposition, User Needs, System Requirements und erste Architekturskizze.

Rekonstruiertes & eingefrorenes Material

Vollständiges Vorlesungsskript

Aus dem primären ukrainischen Transkript rekonstruiert. Redaktionelle Korrekturen und externe Ergänzungen sind im Material ausdrücklich markiert.

Proposal, Standards und Geschäftsmodell

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.

1. Unsere Position im Projektlebenszyklus

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.

2. Weshalb Embedded-Angebote schnell auf Normen treffen

Bei Systemen mit Wirkung auf die physische Welt umfassen Kundenerwartungen meist mehr als die reine Funktion:

  • funktionale Sicherheit;
  • Cybersicherheit;
  • elektromagnetische Verträglichkeit sowie elektrische und mechanische Randbedingungen;
  • Qualitätsprozesse;
  • Rückverfolgbarkeit;
  • Fertigungs- und Marktanforderungen;
  • Nachweise der Verifikation.

Ein Angebot benötigt daher eine Referenzgrundlage aus regulatorischen, prozessualen und technischen Dokumenten, die die Lösung beeinflussen.

3. Drei Orientierungsebenen: Framework → Norm → Guideline / Praxis

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.

Framework / Prozessmodell

Beantwortet überwiegend die Fragen „Welche Prozesse sind erforderlich, und wie wird ihre Fähigkeit bewertet?“

Beispiel: Automotive SPICE.

Norm / Standard

Legt Anforderungen, Prinzipien, Arbeitsprodukte oder Kriterien für ein bestimmtes Gebiet fest.

Guideline / Programmier- oder Entwurfsregelsatz

Ü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.

4. Redaktionelle Präzisierung — Automotive-SPICE-Fähigkeitsstufen

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.

5. Redaktionelle Präzisierung — Normen und CE-Kennzeichnung

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:

  • Europäische Normen sind in der Regel freiwillige technische Spezifikationen, sofern nicht eine Rechtsvorschrift bestimmte Anforderungen verbindlich macht;
  • harmonisierte Normen begründen oft eine Vermutung der Konformität, obwohl alternative technische Lösungen zulässig sein können;
  • die CE-Kennzeichnung ist kein universelles Qualitätssiegel und erfordert nicht in jedem Fall eine Drittprüfung;
  • zunächst ist genau festzustellen, welche EU-Vorschriften auf das konkrete Produkt anwendbar sind.

Offizielle EU-Quellen:

6. Einstufung funktionaler Sicherheit: Domänen und Normen nicht vermischen

HARA und ASIL erscheinen erneut als Beispiel dafür, wie Risikoklassifizierung die Strenge der technischen Maßnahmen beeinflusst.

Redaktionelle Präzisierung

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.

7. Ein Angebot muss Architektur, Implementierung und V&V erklären

Der Kunde muss erkennen können, was gebaut werden soll und wie nachgewiesen wird, dass das Ergebnis den Bedarf erfüllt.

Architektur

  • Grobe Systemzerlegung;
  • wesentliche Schnittstellen;
  • externe Abhängigkeiten;
  • wichtige Randbedingungen;
  • Alternativen und technische Zielkonflikte.

Implementierung

  • Technologien und Werkzeuge;
  • geplante Arbeitsbereiche;
  • Aufbau- und Fertigungsweg;
  • Integrationsstrategie;
  • Machbarkeitsprüfungen oder PoC bei Bedarf.

Verifikation und Validierung

  • Reviews und statische Analyse;
  • Unit-Tests;
  • Integrationstests;
  • Prüfstand-, HIL- und Hardwaretests;
  • Regressionstests und Leistungsmessungen;
  • Abnahme- und Validierungsnachweise.

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.

8. Ressourcen sind mehr als Personal

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.

9. Time & Materials und Fixed Price: Was sich tatsächlich ändert

Die Vorlesung vergleicht zwei grundlegende Vergütungsmodelle.

Time & Materials

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.

Fixed Price / Festpreis

Der Dienstleister verpflichtet sich, einen festgelegten Umfang zu vereinbartem Preis und vertraglichen Bedingungen fertigzustellen. Das erfordert deutlich klarere Leistungsabgrenzung, Abnahmekriterien, Annahmen und Änderungssteuerung.

Redaktionelle Präzisierung — Risikoverteilung

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

10. Wann ein Festpreis sinnvoll ist

In der Logik der Vorlesung ist ein Festpreis realistisch, wenn:

  • Problem und Leistungsumfang gut verstanden sind;
  • die Anforderungen ausreichend stabil sind;
  • der Anbieter vergleichbare Arbeiten schon ausgeführt hat;
  • die Abnahmekriterien klar sind;
  • Abhängigkeiten und Pflichten des Kunden dokumentiert sind;
  • ein Änderungsmanagement besteht;
  • Unsicherheit in Reserve und Marge berücksichtigt wurde.

Sind diese Bedingungen nicht erfüllt, ist T&M oder ein phasenweises Zusammenarbeitsmodell häufig transparenter.

11. Schätzungen müssen nachvollziehbar sein

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?

12. Kontrollfragen

  1. Warum benötigt ein Angebot eine Referenzgrundlage?
  2. Wodurch unterscheidet sich ein Prozessbewertungsmodell von einer Produktsicherheitsnorm?
  3. Welche Fähigkeitsstufen definiert Automotive SPICE 4.0?
  4. Warum ist die CE-Kennzeichnung nicht bloß eine „ISO-Zertifizierung“?
  5. Welchen Vorteil kann eine harmonisierte Norm innerhalb der EU bieten?
  6. Auf welchen drei Parametern beruht die Automotive-HARA-/ASIL-Einstufung?
  7. Was ist der wesentliche kommerzielle Unterschied zwischen T&M und Festpreis?
  8. Warum lassen sich rechtliche und Haftungsrisiken nicht allein aus dem Preismodell ableiten?
  9. Welche nicht-personellen Ressourcen gehören in eine Embedded-Projektschätzung?
  10. Wann ist eine Schätzung rückverfolgbar und nachvollziehbar?

13. Schema der Veranstaltung

Kundenbedarf
          ↓
Referenzgrundlage (Prozess/Framework + Normen/Recht + Richtlinien/Projektregeln)
          ↓
Architektur + Implementierung + V&V
          ↓
Ressourcen + Zeitplan + Risiken
          ↓
T&M / Festpreis / Hybridmodell
          ↓
verhandelbares Angebot

14. Übergang zum 22. September 2026

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.

Geprüfte Referenzen