Firmware-Dienstleister wechseln: Checkliste für die Übernahme

1. Zuerst den tatsächlichen Projektstand festhalten

Beschreiben Sie, was übernommen werden soll: eine laufende Serienfirmware, ein Laborprototyp oder ein unvollständiger Entwicklungsstand. Benennen Sie den Anlass des Wechsels und die Funktionen, die während der Übergabe unverändert bleiben müssen. Ein neuer Entwickler kann aus einem Fehlerbericht allein nicht erkennen, welche Eigenschaften absichtlich so ausgelegt wurden.

Erstellen Sie eine Bestandsliste mit drei Zuständen: vorhanden und geprüft, vorhanden aber ungeprüft, fehlend. Trennen Sie bekannte Fehler von gewünschten Erweiterungen. Ein Angebot für die Bestandsaufnahme lässt sich dadurch von einem Angebot für die anschließende Entwicklung unterscheiden. Eine pauschale Zusage zu Kosten oder Termin wäre ohne diese Abgrenzung wenig belastbar.

2. Quellcode und Build als zusammengehöriges Paket prüfen

Legen Sie einen eindeutig benannten Commit oder Release-Stand fest. Dazu gehören eingebundene Bibliotheken, generierte Dateien oder deren Erzeugungsschritte, Linker-Konfiguration und die verwendeten Werkzeugversionen. Ein vorhandenes Binärabbild ist als Referenz hilfreich, ersetzt aber keine wartbare Entwicklungsbasis.

Lassen Sie den Build in einer neu eingerichteten Umgebung nachvollziehen. Dokumentieren Sie den Startbefehl, erforderliche Einstellungen und erwartete Ausgabedateien. Bei CMake-Projekten können gemeinsame Einstellungen in CMakePresets.json versioniert werden; persönliche lokale Einstellungen gehören in CMakeUserPresets.json. Dieses Werkzeugbeispiel ist keine Pflicht zur Umstellung eines bestehenden Projekts. CMake: cmake-presets(7)

Ein erfolgreicher Build beweist zunächst, dass sich der Stand erzeugen lässt. Er beweist weder die Funktionsgleichheit zum ausgelieferten Gerät noch automatisch ein bitidentisches Ergebnis. Abweichungen durch Versionsinformationen, Zeitstempel oder unterschiedliche Werkzeuge müssen erklärt werden, bevor ein neu gebautes Abbild als Referenz dient.

3. Firmware mit Hardware und Programmierung verbinden

Ordnen Sie der Software die konkrete Platinenrevision zu. Benötigt werden die für das Projekt verfügbaren Schaltpläne, Anschlussbelegungen, Speicherkonfigurationen und Informationen zu Varianten. Eine Firmware, die auf einem Entwicklungsboard startet, ist noch kein Nachweis für die vorgesehene Produktplatine.

Vereinbaren Sie, welche Referenzgeräte, Debug-Adapter und Programmieranweisungen bereitstehen. Kalibrierdaten, gerätespezifische Parameter und Bootloader können getrennt vom Anwendungsabbild liegen. Vor einem Programmierversuch muss geklärt sein, welche Daten erhalten bleiben müssen und wie ein Gerät bei einem fehlgeschlagenen Versuch wiederhergestellt werden kann. Schutzmechanismen werden dabei nicht umgangen.

4. Zugriff, Abhängigkeiten und Verantwortlichkeiten klären

Prüfen Sie, ob das neue Team die vereinbarten Quellen und Werkzeuge tatsächlich nutzen kann. Notieren Sie Verantwortliche für Repository, externe Bibliotheken, Build-Umgebung und Freigaben. Lizenzbedingungen und vertragliche Nutzungsrechte sind projektspezifisch zu klären; die reine Dateiübergabe beantwortet diese Fragen nicht.

Passwörter, Signierschlüssel und produktive Zugangsdaten gehören nicht in ein allgemeines Übergabearchiv. Vereinbaren Sie einen getrennten Übergabeweg und legen Sie fest, wer Zugriff benötigt. Wenn ein Werkzeug oder Dienst beim bisherigen Anbieter verbleibt, muss diese Abhängigkeit ausdrücklich sichtbar werden. Die Checkliste ersetzt keine Prüfung der konkreten Verträge.

5. Die Übernahme mit einer kleinen Referenzprüfung abschließen

Definieren Sie wenige, aber aussagekräftige Abläufe, die den bisherigen Stand beschreiben: Einschalten, eine zentrale Gerätefunktion, Kommunikation mit einem benannten Gegenüber, Parameter speichern und erneut starten. Für jeden Ablauf werden Hardwarestand, Eingaben, erwartetes Verhalten und Nachweis festgehalten. Wählen Sie die Abläufe nach dem Produkt, statt eine allgemeine Testliste unverändert zu übernehmen.

Ein Ergebnisprotokoll soll sichtbar machen, was geprüft wurde, was abweicht und was noch unbekannt ist. Erst wenn diese Ausgangsbasis akzeptiert ist, lassen sich spätere Fehler sinnvoll einer Änderung zuordnen. Bestehende Fehler werden nicht stillschweigend als neue Entwicklungskosten behandelt, sondern separat priorisiert.

6. Einen begrenzten ersten Auftrag formulieren

Ein sinnvoller erster Meilenstein kann lauten: vereinbarten Quellenstand bauen, auf der benannten Hardware programmieren, die festgelegten Referenzabläufe prüfen und offene Abhängigkeiten dokumentieren. Mögliche Ergebnisse sind eine Build-Anleitung, eine Versionszuordnung, ein Prüfprotokoll und eine Liste der verbleibenden Risiken. Welche Ergebnisse geschuldet sind, gehört in den vereinbarten Leistungsumfang.

Bleibt der Build wegen fehlender Quellen oder Werkzeuge blockiert, sollte der nächste Auftrag diese Lücke bearbeiten. Eine Neuimplementierung ist eine eigenständige Entscheidung und kein beiläufiger Teil einer Übernahme. Auch eine Zertifizierung, Sicherheitsbewertung oder vollständige Regression ist durch den hier beschriebenen Einstieg nicht automatisch abgedeckt.

Häufige Fragen

Kann die Übernahme ohne vollständigen Quellcode beginnen?

Eine Bestandsaufnahme kann beginnen. Ob eine wartbare Weiterentwicklung möglich ist, bleibt bis zur Prüfung der fehlenden Teile offen. Ein vorhandenes Binärabbild allein ist keine ausreichende Grundlage für eine reguläre Quellcodepflege.

Muss bei einem Dienstleisterwechsel alles neu entwickelt werden?

Nein. Zuerst wird geprüft, ob der bestehende Stand nachvollziehbar gebaut, programmiert und getestet werden kann. Ein Umbau oder eine Neuimplementierung braucht eine gesonderte technische und wirtschaftliche Begründung.

Was bestimmt Aufwand und Dauer?

Vor allem die Vollständigkeit der Unterlagen, die Verfügbarkeit der Werkzeuge und Hardware, die Zahl der Varianten sowie der Umfang der Referenzprüfungen. Eine belastbare Schätzung sollte diese Annahmen und offene Punkte ausdrücklich nennen.