Projektmanagement

Von der Elektronik zu "Embedded IT"

Wie organisiert man ein Embedded Linux Projekt? Wie organisiert man überhaupt ein Software-Projekt mit modernen Mitteln - noch dazu eines, das sich an der Schnittstelle von Hard- und Software abspielt? Der Schlüssel zu erfolgreichen Projekten liegt in einem agilen Vorgehen - aber mit Augenmaß.

Weitere Infos

In der "konventionellen" IT Industrie ist es längst üblich, Projekte nach Vorgehensmodellen und definierten Softwareentwicklungsprozessen umzusetzen. Im Embedded Markt ist diese Methodik unserer Erfahrung nach in vielen Projekten aber noch nicht vollständig angekommen. Wie kommt das?

Oft sind die Entwickler wie die Projetverantwortlichen Quereinsteiger und komen aus der Elektronik- oder Automatisierungsbranche. Nach Jahren, in denen die Elektronik und die Physik im Mittelpunkt stand, kamen die 8-Bitter, die noch leicht für jeden Entwickler durchschaubar waren: der auf einer Din-A4 Seite ausgedruckte Befehlssatz reichte, um erfolgreich Projekte umzusetzen. Aber nur wenige Jahre später sind die 32-Bitter im Markt vollständig vertreten und ermöglichen Dinge wie Web-Oberflächen zur Parametrierung, moderne Kommunikations-Schnittstellen und grafische Applikationen. Unversehens findet sich heute der Entwickler in einem Umfeld wieder, das mehr "IT" als "Elektronik" ist.

In der IT Industrie wurde die Vorgehensweise bei der Entwicklung umfangreicher Projekte in den letzten Jahren komplett auf den Kopf gestellt. Das Erscheinen des berühmten "Design Patterns - Elements of Reusable Object-Oriented Software" Buchs von Gamma et. al. im Jahr 1994 war der Ausgangspunkt einer Entwicklung, die weg von der ad-hoc Umsetzung von Softwareprojekten hin zu einem planvollen Vorgehen geführt hat. Unmittelbar und für uns im Tagesgeschäft der Projekte haben sich daraus für uns ettliche Folgerungen ergeben, die nicht mehr wegzudenken sind:

Benutzung eines Betriebssystems: Jedes Embedded Projekt beginnt für uns nicht beim leeren Editor, sondern mit > 10 Millionen Zeilen vorhandenem Betriebssystem-Code, das alle Grundbedürfnisse abdeckt.
Benutzung von Bibliotheken und Frameworks: Bevor angefangen wird, etwas zu coden, schaut man nach, ob es nicht schon eine Lösung und eine Infrastruktur gibt.
Testbasierung: Testen ist der Schlüssel dazu, daß Funktionalität über die Zeit erhalten bleibt. Nur mit intensivem Testen lassen sich Projekte langfristig erhalten. Wir wollen nie wieder in die "never change a running system" Ära zurückfallen.
Agilität: Anforderungen sind unscharf. Anforderungen ändern sich. Niemand kennt zu Beginn eines Projekts alle Anforderungen. Das ist aber keine Entschuldigung für schlechte Vorausplanung, im Gegenteil. Nur wer sinnvoll vorausplant und bereit ist, Veränderungen als Teil des Prozesses zu sehen, kann Projekte "in time" und "in budget" umsetzen.

In der Konsequenz bedeutet das: Wir müssen Embedded Linux Projekte heute so planen und steuern, wie es in der "richtigen" IT seit langem üblich ist. Requirements Engineering, Modellierung und regelmäßige, ehrliche Kommunikation zwischen den Stakeholdern sind wichtig für einen Projekterfolg. Aber sind auch alle Software Entwicklungsprozesse 1:1 auf Embedded anwendbar?

Besonderheiten bei "Embedded"

Embedded Projekte verfügen über einen großen Unterschied zu "konventionellen" IT Software-Projekten: wir haben es mit Hardware zu tun. Wo dem Java-Entwickler die Angabe der Version seines SDK ausreicht, um die Plattform zu beschreiben, kämpfen wir im Embedded Bereich mit

Chip Bugs, undokumentierten Errata
Timing-Fehlern
schlecht bis überhauptnicht dokumentierten Hardwareschnittstellen
Fremdcode mit mangelhaftem Error Handling

Probleme dieser Art machen Embedded Entwicklern heute nach wie vor stark zu schaffen, wenn es um Planbarkeit und Abschätzbarkeit geht. Um so wichtiger ist es, Risikopfade aufzuzeigen und durch geeignete Projektmanagement-Maßnahmen abzudecken.

In der Praxis gilt es, die besten Methoden aus dem agilen Projektmanagement und dem systematischen Software Engineering herauszupicken und sie mit Augenmaß auf die Anforderungen des Embedded Bereichs anzupassen: so lassen sich Methoden wie Testbasierung beispielsweise in einer Java-Umgebung leichter anwenden als bei Systemen, deren unterste Schnittstelle JTAG, Analogsignale und Feldbus-IOs sind und die nach "oben" hin über Frameworks an objektorientierte Applikationen angebunden sind.

Trotzdem glauben wir, daß sich nur durch Schaffung geeigneter Rahmenbedingungen eine ähnliche Systematik für Embedded Projekte erreichen läßt, wie sie in der IT üblich geworden ist. Mit Methoden wie hardware-nahen Unit Tests, Integration von Elektronik in IT-Infrastrukturen und automatischen Build Systemen im Pengutronix Remote Lab stehen uns heute eine Vielzahl von Werkzeugen bereit, um dieses Ziel zu erreichen.

Unser Weg zum Ziel

Wie erreichen wir diese Anforderungen? Wichtige Aspekte sind:

Offene Kommunikation. Wir glauben, daß transparente Kommunikation und eine offene Zusammenarbeit der Schlüssel zum Erfolg sind. Wir gehen an Problemlösungen heran, indem wir so denken wie unsere Kunden. Projekt-Mailinglisten mit allen Stakeholdern ermöglichen im Projekt das, was uns die Linux Community vormacht: Technologienutzer können in einen direkten Dialog mit Technologieprovidern treten.
Probleme verstehen. Als Ingenieure sind wir gewohnt, aus Problemen Lösungen zu entwickeln. Das geht aber nur dann wirklich optimal, wenn wir verstehen, was das eigentliche Problem ist. Die Planung und Umsetzung eines Projekts kann nur optimal vonstatten gehen, wenn die Fragestellungen (und nicht nur bereits existierende Lösungsvorschläge!) verstanden sind.
Risiken identifizieren. Nur mit viel Erfahrung kann man schon in einer frühen Phase des Projekts so viele Risikopunkte wie möglich identifizieren und ggf. durch Vorabstudien untersuchen. Bei hardwarenahen Projekten muß allerdings die Kirche im Dorf bleiben: es gibt viele Fragestellungen, bei denen man die Aufgabe umgesetzt haben muß, um die Frage endgültig zu beantworten, ob etwas umsetzbar ist. Deshalb sind gute Planung und Augenmaß ein Muß.
Agilität leben. Projekte lassen sich nur sinnvoll steuern, wenn alle Beteiligten bereit sind, sich auf eine Welt mit sich ändernden Anforderungen einzulassen und die richtigen Schlüsse daraus zu ziehen. Regelmäßige Statusmeetings und ein gemeinsamer Focus auf Problemlösungsstrategien sind dabei extrem wichtig.