Ein derartiger Entwicklungsprozess und Datenfluss wird bei steigendem Druck nicht intakt bleiben. Die offensichtlichen Schwachstellen sind die Übergabestellen zwischen den Aktivitätsinseln. Benötigt wird ein kohärenter Prozess, bei dem Daten nahtlos zwischen den Organisationen übertragen werden (Bild 3).
Hierfür ist eine Reihe von Werkzeugen erforderlich, welche die Daten für den Anwender verwalten, ohne dass manuelle Transfers die Datenintegrität beeinträchtigen. Genauso wenig dürfen die Daten Fehlern ausgesetzt werden und im Prozess kritische Schwachstellen auftreten.
Das bedeutet nicht, dass alle Entwickler die gleiche Bedienoberfläche verwenden und die Dinge auf die gleiche Art und Weise ausführen müssen. In der Tat hat jede Entwicklungsorganisation sehr unterschiedliche Anwendungsfälle, Geschäftsmodelle und Ziele. Die eingesetzten Werkzeuge sollten das widerspiegeln können. Wenn solche kohärenten Werkzeuge und Methoden das V-Modell stärken, lässt es sich unter dem Marktdruck leichter komprimieren und anpassen. Gleichzeitig bleibt eine solide Engineering-Integrität erhalten (Bild 4).Jeder Entwicklungsprozess wird von einem stetigen Strom von Änderungen begleitet. Das Verwalten dieser Änderungen war zwar schon immer wichtig, wird aber durch die kürzeren Zykluszeiten noch bedeutender. Entscheidend ist ein kohärenter Prozess, bei dem Daten nahtlos ausgetauscht werden. Dies muss jedoch auf kontrollierte Weise geschehen.
Wären die Daten weit offen für permanente Änderungen, bräche ein Chaos aus. Grundlegende und obligatorische Anforderungen sind einfache Dinge wie Designs, die Freigaben definieren und ermöglichen; ferner solche, die Benutzerberechtigungen überwachen, die über einen Audit Trail verfügen, sowie darstellen, wer wann Anpassungen gemacht hat. Abschließend muss sichergestellt sein, dass Änderungen mit Hilfe einer Änderungsdokumentation festgehalten werden.
Um neue Funktionen schnell implementieren zu können, müssen diese an der richtigen Stelle im V-Modell eingefügt und die Änderungen dann mit dem Rest der Designorganisation auf eine kontrollierte Weise synchronisiert werden. In der Regel beginnt man an der linken oberen Seite des Prozesses mit der funktionalen Modellierung. Diese wird für eine Plattformarchitektur verwendet, die zur Entwicklung von logischen Systemen führt, welche wiederum für die physikalische Topologie einer Plattform zum Einsatz kommen.
Daraus ergibt sich eine physikalische Verdrahtung, welche zum Beispiel mit dem Kabelbaumdesign synchronisiert wird. Dieser Zwischenschritt wird dann für die Assemblierung des Kabelbaums weiter detailliert, was letztlich zur Fertigung eines realen Kabelbaums führt. Eine Serviceorganisation kann anhand all dieser Daten Servicedokumente und Störungsbeseitigungs-Verfahren für ihre Techniker im Feld erstellen (Bild 5).
Gängige Abläufe neu überdenken
Was ist, wenn die auf den Markt drängende Technologie ein Standardprodukt eines etablierten Anbieters ist und in einer bestehenden Plattform eingesetzt werden soll? Ist dann eine vollständige Neubewertung der Plattformarchitektur erforderlich? Vielleicht hat der Zulieferer bereits ein logisches Design des Systems zur Verfügung gestellt. Der schnellste Weg, um ein solches System einzusetzen, wäre es, das neue Systemdesign in den Prozess einzufügen und es dann stufenweise zu verfeinern.
Das würde jedoch bedeuten, dass die funktionalen Modelle und Plattformarchitekturen veraltet wären und nicht mehr länger mit dem freigegebenen Design übereinstimmen. Das kann zum Problem werden, wenn die nächste vom Markt forcierte Funktion eine vollständige Bewertung des funktionalen Designs erfordert. Wie ist das möglich, wenn das funktionale Design und das Architektur-Design nicht mit dem Produktdesign übereinstimmen?
Benötigt wird die Fähigkeit, Daten auf eine kontrollierte Art und Weise von einer Abstraktion zu einer anderen zu synchronisieren. Da die nachgelagerte Aufgabe der Bordnetz- und Kabelbaumentwicklung für dieses neue System in Arbeit ist, kann die für die funktionale Modellierung und das Architekturdesign verantwortliche Organisation damit beginnen, ihr Design mit dem eingefügten Logikdesign des Systems zu synchronisieren (Bild 6). Indem diese die Abstraktionen miteinander vergleicht, sieht man, was in ihren Architektur- und funktionalen Modellen geändert werden muss, um konsistent mit den neuen Änderungen zu sein. So können die Modifikationen entweder manuell durchgeführt oder idealerweise Werkzeuge dazu verwendet werden, die das automatisch machen. Sobald dieser Vorgang abgeschlossen ist, sind alle Daten innerhalb des Prozesses kohärent und konsistent. Dafür benötigt eine Organisation jedoch nicht den Mehraufwand, der nach einem Start bei Schritt 1 erforderlich wäre.
Sich widerstrebende Anforderungen in Einklang bringen
Manuelle Entwurfsprozesse sind langsam und fehleranfällig. Dies steht im Widerspruch zu zwei erstrebenswerten Eigenschaften, die es zu erreichen gilt: Geschwindigkeit und Korrektheit. Entwurfsprozesse müssen so weit wie möglich automatisiert werden, damit der Entwickler vom kritischen Pfad inkonsequenter Entscheidungsfindung loskommt. Er sollte auf einer höheren Ebene arbeiten und die Regeln implementieren, anhand derer die Automatisierung Tausende von kleinen Entscheidungen trifft. Diese Regeln kann eine Organisation dann wiederverwenden, um die Konsistenz in der Designqualität zu gewährleisten.
Die Konsum-Orientierung des Autos zwingt Automobilhersteller zu kürzeren, flexibleren Designzyklen. Dies ist problematisch für das herkömmliche V-Modell, das üblicherweise aus zwei getrennten Prozessen zusammengesetzt wird. Das macht es auch besonders schwierig, auf den aktuellen Trend zur Konsum-Orientierung zu reagieren. Es bedarf eines kontrollierten und nahtlosen Datentransfers zwischen den Abteilungen – in der Automatisierung und Abstraktion der Anforderungen wie von Auditing-Änderungen und der Modellierung neuer Funktionen, sowohl hinsichtlich der Korrektheit als auch der Kosten.
Ideale Entwicklungswerkzeuge sollten den ganzen Weg bis zur Erstellung der Servicedokumentation abdecken. Dies ist angesichts der unzähligen Fahrzeugkonfigurationen eine große Herausforderung. Die Hauptaufgabe im Zeitalter der vernetzten Fahrzeuge ist es, anpassungsfähigere und flexiblere Entwicklungsprozesse zu realisieren, die sich besser an die sich ändernden Präferenzen der Kunden anpassen lassen. Denn diese werden eher von Smartphones als von Motorspezifikationen bestimmt.
Der Autor
Sjon Moore |
---|
ist als Technical Marketing Engineer bei Mentor Graphics tätig, und zwar in Novi, Michigan (USA). Innerhalb der Marketing-Abteilung arbeitet er als Solution Architect. |
sjon_moore@mentor.com