Fragen zur embedded Produkt- und Softwareentwicklung

Kann eine Person alles, wirklich alles?

"...entwickelt C++ Software und VHDL programmierbare Logik. Erstellt Schemas und Layouts und nimmt dann die Hardware gerade auch selbst in Betrieb. Führt zusätzlich die EMV und CE Zertifizierung durch und übernimmt die Zertifizierung für funktionale Sicherheit und IoT Security..." Das ist die nicht untypische Stellenbeschreibung für einen Entwicklern oder die Selbst-Beschreibung von Ein-Mann Entwicklungsanbietern.

Geht das überhaupt? Sicher, es gab mal eine Zeit, da war das so ähnlich möglich. Aber: das war im letzen Jahrtausend: 8-bit Prozessoren, keine EMV-Vorschriften, die den Namen verdienen, 1K EPROM, 256 Byte RAM, die Sprache hiess Assembler, die Entwicklungsumgebung hiess "Monitor"... Diese Zeit ist definitiv vorbei!

Wenn eine oder zwei Personen heute alleine alle diese Aufgaben übernehmen, dann ist häufig das Desaster vorprogrammiert. Es entsteht eine Steuerung die eigentlich funktioniert. Und dann kurz vor Produktionsstart die EMV-Tests nicht besteht, weil Layout- und EMV-Grundlagen nicht beachtet wurden. Beim Produktions-Ramp-Up zeigt sich, dass die die Ausbeute beim Löten unterirdisch ist, weil Footprints schlecht sind. Der erste Prototyp beim Kunden stürzt ab, und niemand weiss wieso (der erste Parameter, den der Kunde veränderte, hatte keine Fehlerbehandlung, wie alle anderen auch...). Die Sicherheitsprüfung erfordert ein komplettes Redesign. Und so weiter...

Wieso ist das heute so? Wieso ging das früher? Dafür gibt es drei Gründe:

• Komplexitäts-Zuwachs: In Elektronik und Software sind heute Systeme im Einsatz, welche vor einigen Jahren als Server durchgegangen wären. Deren inhärente Komplexität sorgt dafür, dass nur noch gut zusammenarbeitende Spezialisten solche Entwicklungen auch effizient durchführen können.
• Time-to-Market: Wie schnell mussten neue Produkte auf dem Markt sein? Es gab Projekte, die dauerten zehn Jahre. Würde das heute akzeptiert? Die Bauteile wären schon obsolet, wenn die Produktion beginnt...
• Nicht-funktionale Anforderungen: Die meisten Lastenhefte denken in den funktionalen Anforderungen, im Geradeaus-Fall. Das war beim 8-bit Mikrocontroller auch genügend, jeder war froh, wenn man die Funktion in den vorhandenen Speicher quetschen konnte. Dreissig Jahre später sind die funktionalen Ansprüche an ein System innert 20% der Entwicklungszeit erfüllt. Dann kommen die nicht-funktionalen Anforderungen: Zertifizierung für CE, EMV, Betriebssicherheit, funktionale Sicherheit. Die meisten Geräte haben grafische Oberflächen mit Touch-Bedienung, daraus folgen Forderungen nach Usability und Mehrsprachigkeit. Und auch die Industrie 4.0 fordert IoT Funktionen, welche sofort Cyber-Security nach sich ziehen...

Alle Arbeit nur einem Generalisten zu geben, ist wohl eines der am weitesten verbreiteten und für den Projekterfolg folgenschwersten Entscheide. Und leider der, welcher alle embedded Entwickler in ein schlechtes Licht rückt: "Es geht alles sowieso immer viel länger und funktioniert dann doch nicht".

Was heisst das?

Wir finden, dass embedded Entwicklung ist Team-Arbeit ist. Keiner kann alles, stellen Sie ein Team für das Projekt zusammen, in dem alle embedded Fachbereiche mit einem echten Spezialisten vertreten sind.

Ist der Aufwand für eine Spezifikation nicht Verschwendung?

Ist es nicht eine Verschwendung, mehr oder weniger detaillierte Anforderungen zu erstellen für ein Produkt oder noch mehr für eine Software? Würde man nicht besser gerade mit der Entwicklung beginnen um so schnell wie mögliche in Produkt auf den Markt zu bringen?

Auch wenn das in Zeiten von "agil" nicht unbedingt gerne gehört wird, ein klares Ziel hilft bei der schnellen Entwicklung. Dies, weil gerade in embedded Systemen nachträgliche Änderungen und die Korrektur von falschen Annahmen sehr aufwändig werden können, aufwändiger als eine gute Spezifikation.

Der Wert von guten Anforderungen zeigt sich zusätzlich, wenn es um die Abschätzung und Planung einer Neuentwicklung geht, wenn die Rentabilität des Produktes beurteilt werden soll. Spätestens bei der Weiterentwicklung des Produktes ist eine klare Spezifikation dann die solide Basis für die Diskussionen um neue oder wegzulassende Features.

Die Alternative ist die Spezifikation auf Zuruf, manchmal "getarnt" als agile Entwicklung. Diese Projekte sind häufig "Open End" und dadurch ist keine Schätzung der Entwicklungskosten möglich für einen Rentabilitätsbetrachtung.

Was heisst das?

Wir finden, Spezifikationen und Anforderungen zu erstellen macht Sinn und lohnt den Aufwand. Investieren Sie in Ihre Anforderungen. Und wenn Sie mit Externen zusammenarbeiten, behalten Sie alle Rechte an diesem Vermögenswert!

Macht uns das Tool viel schneller?

Der Anbieter der Software hat uns gesagt, dass wir um einen Faktor schneller entwickeln werden. Die neue Sprache verspricht einen Produktivitätszuwachs...

Gibt es diese Wundermittel, diese "Silver Bullets"? Die Antwort ist leider nach 34 Jahren immer noch: "There Is Still No Silver Bullet", ein Artikel welcher sich auf Brooks aus dem Jahr 1987 bezieht... Software-Projekte können sich immer noch ohne Vorwarnung in Werwölfe verwandeln, welche Ressourcen, Termine, Geld und Karrieren verschlingen. 

Werkzeug bringen pragmatisch angewandt und verstanden Fortschritte in der Qualität der Entwicklung und haben das Potential, den Aufwand zu verringern. Nur lösen diese Tools nicht alle Probleme auf einen Schlag, sondern sie können auch neue Probleme aufkommen lassen. Unter anderem, da sie zuerst geschult, verstanden und richtig angewandt werden müssen.

Was heisst das?

Verstehen Sie uns richtig, auch wir verwenden viele Software-Werkzeuge und die neusten Sprachen. Nur glauben wir daran, dass wir nur das verwenden, was für das Projekt und das Produkt Sinn macht, dass wir pragmatisch aus dem grossen Angebot das auswählen, was echte Vorteile bringt.

Können uns agile Methoden retten?

Der Agile-Berater hat gesagt, dass alles viel einfacher geht und alle Probleme verschwinden. Wenn wir uns exakt an seine Methode halten! Ist das wirklich so?

Die agilen Prozesse und Arbeitsweisen des Erzeugens von Spezifikationen während des Projektes wurden für eine Art von (IT-) Problemen entwickelt, wo sie ihre Berechtigung haben. Es geht häufig um das Anpassen von Lösungen an Kundenwünsche,  bei denen sowohl die grundsätzliche Plattform wie auch die grundsätzliche Funktion (Webauftritt, Webshop...) schon bekannt sind.

In der embedded Produktenwicklung sind die Ressourcen (Rechenleistung, Stromverbrauch...) immer beschränkt. Genau wieviele zur Verfügung stehen, wird am Anfang des Projektes beim Design der Elektronik bestimmt. Wenn die Spezifikationen sich ändern und es mehr braucht, dann ist diese Erhöhung meist eine sehr teure Übung.

Die Erzeugung von Spezifikationen während des Projektes ist also nicht die preiswerteste und schnellste Variante. Bei kritischen Systemen ist sie sogar durch die Normen abgeblockt. Und auch hier gilt wie bei den Tools: "There Is Still No Silver Bullet"!

Was heisst das?

Das heisst nicht, dass "agile" Prozesse keine Berechtigung haben. Auch wir machen iterative Auslieferung und Integration, automatisierte Test etc., auch bei kritischen Projekten.

Probieren Sie die Methoden aus, die für Ihr Problem die beste Lösung sind. Haben Sie den Mut, auch nur Teile davon zu benützen und Ihr Vorgehen bei Bedarf anzupassen. Und erwarten Sie keine Quantensprünge, vor allem, wenn diese von quasi-religiösen Eiferern versprochen wurden.