Embedded-Entwicklung Erfolgreiches Design ohne Rücksicht auf sich ändernde Anforderungen

Das Leben von Embedded-Entwicklern wäre wesentlich schöner, wenn sie während des Design-Prozesses nicht dauernd mit Änderungen konfrontiert würden. Wie man trotzdem erfolgreich Arbeiten kann beschreibt Jon Pearson vom Halbleiterhersteller Cypress.

Fordert man Entwickler von Embedded-Systemen auf, in knapper Form den Ablauf eines Projekts zu skizzieren, erhält man meist eine Aussage wie »Man nennt uns die Anforderungen, wir designen das System, schreiben den Code und verifizieren das Ganze dann.« Möglicherweise nimmt die befragte Person noch am selben Tag an der Planung des nächsten Projekts teil. Sobald bekannt ist, um was es bei dem Projekt geht, wird zumindest im Kopf mit dem Schreiben des Programms begonnen, womit gleichzeitig die Architektur festgeschrieben ist. Vielleicht nur einen Tag oder eine Woche später kann man nicht selten miterleben, wie sich derselbe Programmierer in einem ähnlichen Meeting darüber beklagt, die Anforderungen für das Design reichten nicht aus und man könne erst weitermachen, wenn sich die Vorgaben nicht mehr verändern. Wie lässt sich dieser scheinbare Widerspruch erklären?

Jedes Projekt ist mit Risiken behaftet, doch die größte Gefahr besteht darin, dass die Anforderungen entweder zu Beginn des Projekts nicht genügend ausgearbeitet sind oder sich vor Abschluss des Projekts häufig ändern. Gleichzeitig wird von den Ingenieuren erwartet, dass sie ihren Job erledigen – im Rahmen der gesetzten Vorgaben. Das Ganze soll außerdem sicher erfolgen – wiederum innerhalb der Vorgaben. Bei den meisten kommerziellen Projekten ist die Zeit ein wichtiger Faktor, sei es, um saisonalen Absatzzyklen oder Messeterminen Rechnung zu tragen, um einem Konkurrenten um eine Nasenlänge voraus zu sein oder schlicht um den gesetzten Zeitplan nicht zu sprengen. Der stets herrschende Zeitdruck geht zu Lasten der Anforderungen, die deshalb im Lauf des Projekts modifiziert oder weiterentwickelt werden.

Marketingabteilungen neigen dazu,  Projekte vor Festlegung der Anforderungen beginnen zu wollen. Sie bringen ihre Kenntnisse darüber ein, was möglich ist, was der Kunde wünscht (dies lässt sich allerdings bestenfalls vage vorhersagen) und welche Wettbewerbssituation herrscht (wichtig besonders bei neuen Technologien). Allerdings wachsen die Ingenieure mit ihren Aufgaben und stürzen sich deshalb nicht selten kopfüber in ein neues Vorhaben. Die eigentliche Herausforderung besteht für sie somit darin, ein Projekt erfolgreich zu starten und so schnell zu beenden, dass es maximale Einnahmen bringt – alles in dem Bewusstsein, dass sich bis zur tatsächlichen Markteinführung praktisch jede Anforderung ändern kann. Ist das Produkt erfolgreich, wird es außerdem in noch schnellerer Folge Nachfolgeprodukte und Varianten geben.

Es empfiehlt sich deshalb, von vornherein auf eine Strategie zu setzen, die auf Änderungen vorbereitet ist. Von Beginn an wird davon ausgegangen, dass sich alles ändern kann. Die verschiedenen Aspekte des Designs werden daraufhin untergliedert und hinter leistungsfähigen Schnittstellen gruppiert, die dafür sorgen, dass die hinter ihnen stattfindenden Veränderungen keine Auswirkungen auf das übrige Design haben. Übrigens ist diese Programmierweise sehr willkürlich gewählt und passiert keineswegs in einem Umfeld, in dem der Code entsprechend den Anforderungen gleichsam am Fließband erzeugt wird. Die Anforderungen sind wichtig – daran besteht kein Zweifel. Man kann jedoch die kritischen, strukturbezogenen Vorgaben von den Features trennen und mit dem anschließend beschriebenen Designkonzept schneller vorankommen und sich rasch den Gegebenheiten anpassen. Die Vorgehensweise ist wie folgt:

  1. Festlegung der Struktur
  2. Einrichten der Kommunikation
  3. Definition des Timings
  4. Schaffung der Voraussetzungen für austauschbare Features