Kostenfalle Software

Kostenfalle Software Durch Plattformentwicklung zu beherrschbaren Entwicklungskosten Seit vielen Jahren gilt Elektronik mit Anteilen bis zu 90% als Innovationstreiber Nummer 1 in der Automobilindustrie, Software trägt dazu als elementarer Funktionsträger elektronischer Systeme den größten Teil bei. Probleme bei der Softwareentwicklung führten jedoch in der Vergangenheit zu einer Reihe von Qualitätsmängeln. Hier haben sowohl OEM als auch Zulieferer unter anderem mit Prozessverbesse- rungsprogrammen (Stichwort: Automotive SPICE) reagiert. In der aktuell dramatischen Situation der Automobilindustrie, in der sich Zulieferer wachsendem Kostendruck durch OEM und einbrechenden Umsätze gegenüber sehen, müssen jetzt die Entwicklungskosten nachhaltig gesenkt werden. Der richtige Weg hierzu heißt Wiederverwendung durch Plattformen, vor allem im Softwarebereich. Referenzen für Plattformentwicklung in Ausweg aus der Kostenfalle in der Softwareentwicklung der Softwareentwicklung Immer noch werden Synergien in der Softwareentwicklung bei den Zulieferern (Tier1) zu wenig genutzt, Wiederverwendung nicht systematisch betrieben oder unnötige Komplexität und damit Kosten durch Mehrfachentwicklung gleicher Funktionalität erzeugt. Nachdem bisher vor allem versucht wurde, die Qualitätskosten durch konsequente Prozessanwendung und damit Vermeidung von teurer Nacharbeit in der Entwicklung zu senken, muss in der Zukunft das Augenmerk auf der Senkung der Entwicklungskosten durch Wiederverwendung als Plattformkonzept und evolutionärer Weiterentwicklung liegen. • Welche unterschiedlichen Ansätze zur Wiederverwendbarkeit von Software existieren? • Welchen Umfang sollte die Wiederverwendung von Software haben, um maximalen Nutzen zu erreichen? • Welche organisatorischen Maßnahmen sind notwendig sind, um den Erfolg einer Plattformstrategie zu sichern? 1 Unterschiedliche Ansätze zur Wiederverwendbarkeit von Software Fragt man namhafte Tier 1 nach ihren Konzepten zum Software "re-use", verweisen sie wird in der Regel auf existierende Plattformen, die einen hohen Wiederverwendungsgrad ermöglichen. Untersucht man diese Konzepte näher, stellt man fest, dass damit häufig ein so genanntes "carry-over" Konzept gemeint ist, bei dem neue Entwicklungen auf bereits bestehende Entwicklungen für andere OEMs oder andere Fahrzeugplattformen desselben OEM aufsetzen. Dieser Ansatz ist jedoch von einem echten Plattformkonzept, das maximalen Nutzen bietet, zu unterscheiden: Tabelle 1: Charakteristika eines echten Plattformansatzes Charakteristika eines “carry-over” Charakteristika eines echten Ansatzes Plattformansatzes Design wird durch aktuelle Design wird durch Kundenanforderungen vorgegeben Wiederverwendbarkeitsaspekte vorgegeben, pilotiert durch “Lead”-Kunde Das zuletzt verifizierte Design ist Plattform existiert unabhängig vom Grundlage für das nächste neue Design Projekt, oft gibt es eine generische Version zum Zwecke der Validierung Prozesse für Verwendung oder Ableitung Starke Prozesse für Plattformentwicklung sind nicht definiert, ad-hoc (“road map”) und an der Entscheidungen Prozessschnittstelle Applikation / Plattform Software ist nicht oder wenig Tool-basierte Konfigurierbarkeit konfigurierbar individueller Kundenanforderungen Arbeitsprodukte für “carry-over” sind nur Plattform-Arbeitsprodukte decken das der Software Code, nicht jedoch andere komplette V-Modell ab Arbeitsprodukte etwa aus Spezifikation oder Test Keine kundenunabhängige Dedizierte Plattformorganisation, z. B. Plattformorganisation / kein finanziert durch interne Lizenzgebühren Plattformbudget der Kundenprojekte Fehler (“bugs”) werden in jedem Fehler werden einmalig in der Plattform Kundenprojekt einzeln gefunden beseitigt und die Lösung wird an laufende und neue Projekte verteilt Weiterentwicklungen kommen nicht allen Kontinuierliche Weiterentwicklung der Folgeprojekten zugute, „carry-over” endet Plattform durch neue (innovative / in disparaten Projektverästelungen repräsentative) Kundenanforderungen 2 Umfang Wiederverwendung von Software Softwareplattformen dürfen sich nicht auf den reinen Code beschränken, sondern umfassen idealerweise den gesamten Entwicklungszyklus. Dies bedeutet, dass neben den eigentlichen Softwaremodulen auch Software- und Schnittstellenspezifikationen, Softwaredesigns und die zur Softwareverifikation notwendigen Arbeitsergebnisse („work products“), also Modul-, Integrations-, und Software-Testpläne sowie Testprozeduren und Testfallspezifikationen wieder verwendbar sein müssen. Beim Einsatz moderner Werkzeuge für Spezifikationserstellung, Design, ggf. Codegenerierung und Softwaretest muss dies auch berücksichtigt werden, um z.B. möglichst einfach kundenspezifische Werte (etwa Schwellwerte bei Diagnose) einführen zu können, ohne bei Ableitung der Plattform zu einem konkreten Projekt Inkonsistenzen zu erzeugen oder die „Traceability“ (d. h. die durchgängige Verfolgbarkeit der Anforderungen in Design, Code und Test und umgekehrt) zu verlieren. Plattformkonforme Organisation und Prozesse Der Hauptfehler bei der Implementierung von Softwareplattformen ist die unzureichende Ausgestaltung von Organisation und Prozessen, um dem Plattformgedanken Rechnung zu tragen. In vielen Fällen gibt es gar keine oder nur eine schwache Organisationseinheit, die für Plattformentwicklung verantwortlich ist. Oft werden deren Ressourcen als „Steinbruch“ für aktuelle Krisen in Applikationsprojekten missbraucht. Der Grund dafür liegt wohl in erster Linie in der Befürchtung der Unternehmen, dass eine starke (und damit teure) Plattformorganisation Kosten nicht direkt auf Kundenprojekte umlegen kann und somit nicht mit den klassischen Mitteln des Projektcontrollings steuerbar ist. Allerdings muss man zugeben, dass diese Furcht nicht ganz unbegründet ist: Es gibt Beispiele teurer Plattformentwicklungen, die die in sie gesetzten Erwartungen kaum erfüllt haben. Diese Ursachen sind vielfältig: zu hohe kundenspezifische Anteile, die technologsiche Entwicklung überholt das Plattformdesign, fehlende Stabilität oder Modularität, unzureichende Konfigiurierbarkeit oder komplexe, kaum handhabare Integration mit dem Applikationsanteil der Software Zur Vermeidung dieser Probleme muss der Aufbau einer Plattformorganisation übergreifend geplant und mit Unterstützung des Top-Managements erfolgen. In einem ersten Schritt werden die Anteile der Software mit dem höchsten Grad an Gemeinsamkeit über verschiedenen Kunden identifiziert. Dies umfasst typischerweise mindestens den bei AUTOSAR „Basic Software“ genannten Umfang, sollte aber deutlich darüber hinausgehen. Für die Entwicklung und Pflege dieser Software inklusive der dazugehörigen Arbeitsprodukte für 3 Anforderungen, Design und Test wird eine dedizierte Plattformorganisation aufgebaut. Diese Plattformorganisation folgt – neben den Standardprozessen z. B. gemäß Automotive SPICE – weiteren plattformspezifischen Prozessen und Regeln: Tabelle 2: Kernprozesse für eine Plattformorganisation Prozess Zweck Ableitungs- oder Vorgaben für Applikationsprojekte, wie der Plattformcode Anwendungsprozess anzuwenden und auf spezielle Projektbedürfnisse anzupassen ist Änderungs- Vorgaben für Applikationsprojekte, wie Änderungen management veranlasst werden können, um die Plattform z. B. an neue Kundenanforderungen anzupassen oder Kostenvorteile zu erreichen Kompatibilitäts- Regeln, wie die Plattform Auf- und Abwärtskompatibilität mit management anderen Komponenten aufrecht erhält oder auch bricht Plattformentwicklung Regeln für die Weiterentwicklung der Plattform während (“road map”) ihres Lebenszyklus u. a. als Richtschnur für Applikationen, wann die Entwicklungsschritte in deren Projektphasen zu integrieren sind Aus kommerzieller Sicht sollte sich eine solche Plattform nach einer Phase der Anschubfinanzierung durch „Lizenzumlagen“ der Applikationen finanzieren, die die Plattform verwenden. Der zweite Schritt hat das Ziel, den Antagonismus zwischen Plattform und Applikation gänzlich aufzuheben. Das bedeutet, dass letztlich die gesamte Software inklusive der kundenspezifischen Teile „Plattform“ ist, die dann in verschiedene Subsysteme zerfällt.