Anbieter zum Thema
Um vertraglichem Wildwuchs vorzubeugen, empfiehlt es sich, den Kunden in den agilen Systemprozess einzuweihen und eine Bepreisung nach Storypoints auszuhandeln. Storypoints werden in der Aufwandsschätzung für jedes Feature festgelegt und sind ein Maß für die Komplexität zur Entwicklung des Features. Ein Angebot nach Storypoints ist sowohl bei Aufwands- als auch Festpreisangeboten möglich, die eine bestimmte Anzahl an Storypoints garantieren. Zu Beginn einer Iteration kann der Kunde bei der Auswahl der Features mitbestimmen und so seine Prioritäten sichern.

Einbettung der Hardwareentwicklung gemäß dem V-Modell
Um eine grobe Abschätzung der Dimensionierung zu ermöglichen, muss auch im agilen Systemprozess das Gesamtsystem zumindest grob architekturell geplant werden. Basierend auf dieser Grobplanung schätzt man die Dimensionierung ab und verfeinert sie mit jeder Iteration. Zum Glück gibt es viele Pin-kompatible Controller in verschiedenen Leistungs- und Speichergrößen, sodass eine Korrektur nicht immer gleich ein teures Redesign bedeutet. Die HW selbst entsteht trotz V-Modell iterativ. Zunächst verwendet man wenn möglich ein Standard-Entwicklungsboard für die ersten SW-Entwicklungsschritte. Zweckmäßigerweise beginnt man mit den möglichst HW-unabhängigen Anteilen. Mit Fertigstellung des ersten HW-Prototypen schwenkt man mit einem Teil der SW-Entwicklung auf den Prototypen um.
Im Laufe der weiteren Iterationen werden sukzessive die weiteren SW-Entwicklungen auf den Prototypen verlegt, sofern dessen Stabilität dies erlaubt. Implizit wird dabei durch Testen und Verifizieren der SW-Funktionen, die zuvor auf dem Entwicklungsboard liefen, auf den Integrationstest des Systems umgeschwenkt. Dieser Prozess setzt sich kontinuierlich mit dem korrigierten Prototypen und dem ersten Hardware-Release fort.

Wer den Umstieg auf die agile Systementwicklung erfolgreich geschafft hat, der ruht sich nicht aus, sondern sucht gezielt nach weiteren Optimierungsmöglichkeiten. Es muss doch noch besser gehen! Mit dem Schritt in Richtung Test Driven Development lassen sich die Vorteile des agilen Testens weiter ausbauen und damit die Qualität und Systemstabilität weiter verbessern. Warum nicht gleich bei der Grobspezifikation des Systems die System-Testfälle gestalten und das System so kontrolliert wachsen lassen? Test Driven Development bedeutet in diesem Zusammenhang, dass nicht nur die Testfälle vor der Codierung der SW entstehen, sondern gleich die Testfälle für das Gesamtsystem.
Software as a Service (SaaS)
Web-basierte Oberflächen für Embedded-Systeme sind längst State of the Art. Jeder Billig-Router für 20 Euro bietet diese Möglichkeit. Smartphones und Smart-TV verfügen über komplexe Applikationen, die einem ständigen Update-Prozess unterliegen.
Die Updates nicht mehr herunterzuladen, sondern gleich in der Cloud zu belassen und dem Kunden als SaaS anzubieten, bringt einige Vorteile: Der Hersteller braucht nicht mehr verschiedene, sich im Feld befindliche Systemversionen zu warten. Der Kunde hat ohne Installations- und Wartungsaufwand stets die aktuellste Softwareversion in Betrieb. Bei Problemen hat der Servicetechniker sofort Zugriff auf das System. Doch was bedeutet dies für das gesteuerte Embedded-System? Das System muss mit dem Server im Internet kommunizieren, und der Anwender bedient nicht das System selbst, sondern die App im Internet.
Zusammenfassung
Neben der steigenden Bedeutung von Haftungsfragen und der Betriebssicherheit wird für die Entwicklung ein immer breiter gefächertes Wissen unverzichtbar. Das Problem liegt häufig in einem unzureichenden Know-How der Embedded-Softwareentwickler. Es ist also jeder gut beraten, rechtzeitig vorzusorgen und die Technologie-Speerspitze zu bilden. Nach C und C++ sind nun Python, Ruby/Rails, Cloud, SaaS und agile Methoden die wichtigsten Ausbildungsziele.
* Dipl.-Ing. (Univ.) Remo Markgraf ist Management-Trainer bei der MicroConsult GmbH. Er verfügt über langjährige Projekt- und Führungserfahrung in der Softwareentwicklung.
(ID:42474009)