Best-Practice-Leitfaden Software-Release Themenplattform Automotive Electronics, Infrastructure & Software
Impressum Best-Practice-Leitfaden Software-Release Herausgeber: ZVEI - Zentralverband Elektrotechnik- und Elektronikindustrie e.v. Themenplattform Automotive Electronics, Infrastructure & Software Lyoner Straße 9 60528 Frankfurt am Main Telefon: +49 69 6302-276 Fax: +49 69 6302-407 E-Mail: zvei-be@zvei.org www.zvei.org Verantwortlich: Dr. Stefan Gutschling Mai 2014 Trotz größtmöglicher Sorgfalt übernimmt der ZVEI keine Haftung für den Inhalt. Alle Rechte, insbesondere die zur Speicherung, Vervielfältigung und Verbreitung sowie der Übersetzung, sind vorbehalten. 2
Inhaltsverzeichnis 1. Ziele dieses Leitfadens 4 2. Release-Prozess 5 2.1. Software-Release 5 2.2. Prozess aus Sicht des Zulieferers 5 2.3. Prozess aus Sicht des OEM 7 3. Dokumentation und Artefakte 10 3.1. Übersichtsdokument 10 3.2. Detaillierte Releasedokumentation 10 3.2.1. Lieferumfang 10 3.2.2. Systembeschreibung 11 3.2.3. Lebenslauf/Änderungshistorie 11 3.2.4. Funktionsliste 12 3.2.5. Verifikationssergebnisse 12 3.2.6. Metriken 13 3.2.7. Freigaben 14 4. Leitlinien für die Anwendung in der Praxis 16 5. Definitionen und Begriffe 18 6. Endredaktion und beteiligte Firmen 21 3
1. Ziele dieses Leitfadens Mit der steigenden Bedeutung von Software im Fahrzeug, der zunehmenden Vernetzung von Steuergeräten und der damit rapide wachsenden Komplexität tritt die Notwendigkeit eines robusten und effizienten Softwareentwicklungsprozesses immer mehr in den Fokus der Automobilindustrie. Immer mehr Anforderungen sind in immer kürzeren Zeitspannen umzusetzen. Die wachsende Komplexität kann nur beherrscht werden, wenn der Entwicklungsprozess im Netzwerk von Fahrzeugherstellern, Zulieferern und Dienstleistern nahtlos ineinandergreift und die Aufgabenteilung klar definiert und allen Beteiligten transparent ist. Während in den letzten Jahren der Fokus auf der Verbesserung der firmeninternen Prozesse (z. B. in der Umsetzung von Automotive SPICE oder CMMI) lag, wurden die Schnittstellen zwischen Fahrzeugherstellern und den Zulieferern noch wenig betrachtet. Gerade an der Nahtstelle Software-Release führen fehlende einheitliche Definitionen zu erheblichem Abstimmungsaufwand, wenn nicht sogar zu Mißverständnissen und dadurch verursachten signifikanten Störungen im Projektablauf. Die Optimierung gerade des Software-Release- Prozesses ist ein gemeinsames Interesse aller Beteiligten sie kann einen wichtigen Beitrag zur Erhöhung des Reifegrades leisten. Deshalb soll dieser Leitfaden zu einigen wesentlichen Aspekten Erfahrungen und Best-Practices zusammenfassen. Damit soll das Bewusstsein geschaffen werden, wo eine frühzeitige bilaterale Festlegung hilfreich ist, auch wenn nicht überall eindeutige unternehmensübergreifende Empfehlungen möglich sind. Dieser Leitfaden betrachtet beide Seiten des V-Modelles von der Übergabe der Anforderungen des OEM bis zur Übergabe von Steuergeräten an den OEM. Eine gemeinsame Begrifflichkeit ist dabei sehr wichtig nicht nur, aber ganz besonders bei neuen Geschäftsbeziehungen. Ziel ist es, Vorschläge für eine Optimierung der Schnittstelle (Kommunikation und Dokumentation) zwischen Fahrzeughersteller und Zulieferer zu präsentieren. Dies ist eine wesentliche Voraussetzung, um neuen Herausforderungen im Bereich Software-Entwicklung (Fahrerassistenzsysteme, Serviceorientierte Kommunikation, Car2x, etc.) besser begegnen zu können. Im Zentrum steht dabei die Definition der zu einem Software-Release gehörenden Artefakte, wobei es in erster Linie um ein gleiches Verständnis der Inhalte und weniger um einheitliche Datenformate geht. 4
2. Release-Prozess 2.1. Software-Release Im reinen Wortsinn bedeutet Software- Release Freigabe der Software. In der klassischen Informationstechnologie steht die Freigabe der Software am Ende ihres Entwicklungsprozesses. Mit der Freigabe sichert der Lieferant der Software bestimmte Eigenschaften zu und gibt sie für den Abnehmer im Rahmen der definierten Eigenschaften zur Benutzung frei. Das Resultat der Freigabe erfüllt daher typischerweise Vertragselemente der Geschäftsbeziehung zwischen Abnehmer und Lieferant. Die Softwareentwicklung für eingebettete Steuergeräte im Automobil ist in einem weiteren Kontext zu betrachten. Softwarekomponenten, die von verschiedenen Lieferanten stammen können, sind zunächst auf einzelnen Steuergeräten zu integrieren. Ihre Funktion ist auch im Verbund vernetzter Steuergeräte sicherzustellen. Aus Sicht des Fahrzeugherstellers gilt dies bis hin zu verteilten Funktionen, die das Gesamtfahrzeug betreffen. Damit fügt sich die automotive Softwareentwicklung in ein System ein, das viele Beteilgte aufweist und Disziplinen wie Elektrik, Elektronik, Mechanik und Vernetzung als Randbedingungen beachten muss. Dafür hat sich in der Automobilindustrie eine Prozesssystematik mit vielen Synchronisationspunkten etabliert, zu denen jeweils ein Software-Release erforderlich ist. Im sprachlichen Umgang und auch im Folgenden in diesem Leitfaden geht der Begriff Software-Release inzwischen über die wörtliche Bedeutung hinaus und bezieht sich vor allem auf das Ergebnis der Freigabe, also das freizugebende Artefakt, aber auch auf die dazu gehörigen Dokumente und Metriken. Der zur Freigabe und dem freizugebenden Artefakt führende Vorgang ist der Release- Prozess. Dieser Leitfaden beleuchtet in den folgenden Abschnitten den Release-Prozess aus verschiedenen Blickwinkeln: aus der Sicht des Zulieferers und aus der des Fahrzeugherstellers. Das freizugebende Artefakt ist hierin generisch als Komponente aufzufassen. Es kann sich dabei aus Sicht des Zulieferers um eine Software-Komponente handeln. Es kann sich aber auch um eine Gruppe von Software-Komponenten handeln, die gemeinsam freizugeben sind, z. B. die Software für ein ganzes Steuergerät. Aus der Sicht des OEM schließt der Begriff Komponente oft Hardware mit ein und bezieht sich dann z. B. auf ein freizugebendes Steuergerät. 2.2. Prozess aus Sicht des Zulieferers Der Prozess aus Sicht des Zulieferers gliedert sich in verschiedene Entwicklungszyklen über die verschiedenen Subsysteme (Mechanik, Hardware, Software). Die Entwicklungszyklen der Subsysteme sind in sich abgeschlossen, können unterschiedlich schnell sein und müssen zu den Meilensteinen des Gesamtsystems synchronisiert werden (siehe Bild 1). Die Entwicklungsmethoden der einzelnen Subsysteme können voneinander unabhängig sein (z. B. V-Modell für die Hardware und Agile Methoden für die Softwareentwicklung). Der Software-Release-Prozess des Zulieferer enthält folgende Schritte: Funktionserweiterungen, Änderungen und Fehlerbehebungen fließen zu einem definierten Zeitpunkt in die Komponenten ein. Was wann einfließt, muss im Rahmen der Release-Planung definiert werden. Die getesteten und freigegebenen Komponenten werden zur Gesamtsoftware integriert. Auf Basis der Gesamtsoftware wird ein änderungsbezogener Softwaretest durchgeführt, der zur Zeitoptimierung auch parallelisiert werden kann. Bei hohem Automatisierungsgrad kann die Software auch mit der gesamten Testfallsammlung geprüft werden. Die Gesamtsoftware wird evtl. zusammen mit einem Datensatz freigegeben. Die Gesamtsoftware wird falls erforderlich zusammen mit anderen Systemen wie z. B. Hardware ausgeliefert. Der Umfang des Software-Releases muss vor der Auslieferung definiert und abgesichert werden. Gesamtsoftware und Grundbedatung stellen zusammen mit der Begleitdokumentation das Software-Release aus Sicht des Zulieferers dar. 5
Product: I-Level Project Preparation Production Ramp up and Series Gate Gate Gate Gate Gate Production I1 Diese Concept Auslieferung stellt Product wiederum and Process eine Komponente für den OEM dar. Damit startet der Readiness and Phase Development Validation Release-Prozess beim OEM. I2.x I2.x I3.x I3.x I4.x I1.5 I2 I2.5 I3 I3.5 I4 I5 Mechanics: Long Cycles Hardware: Medium Cycles Software: Short Cycles Bild 1: Prozess: Synchronisation der Subsystem Entwicklung (Bildquelle: ESG Elektroniksystem- und Logistik) Bild 2: Ablauf Change-Request/Bugfix (Bildquelle: ZF Friedrichshafen ) 6
2.3. Prozess aus Sicht des OEM Der OEM erwartet vom Zulieferer eine für den geforderten Reifegrad komplett getestete Software. Aus Sicht des OEM ist die Software Teil des Steuergerätes und damit Teil einer Komponente. Diese Komponente testet der OEM inhouse in verschiedenen Schritten. Es werden Komponenten-, Teilsystem-, und Systemtests durchgeführt. In den verschiedenen Absicherungsschritten werden die Komponenten (Steuergeräte) immer näher an das Gesamtfahrzeug herangeführt und getestet (siehe Bild 3). In den Komponententests wird die Komponente an sich getestet, z. B. auf Funktionsfähigkeit und Flashbarkeit. Der Teilsystemtest sichert das Zusammenspiel zwischen der Komponente und den direkten Kommunikationspartnern ab. Im Gesamtsystem wird die Querwirkungsfreiheit sowie die Funktionalität im Fahrzeug getestet. Treten bei einem Test Fehler auf, werden diese an den Komponentenentwickler (Zulieferer) zur Fehlerbehebung in Folge-Releases zurückgespiegelt. Bild 3: Release-Prozess aus Sicht des OEM (Bildquelle: ESG Elektroniksystem- und Logistik) Bild 4: Prinzip der unterschiedlichen Integrationsebene (Bildquelle: ESG Elektroniksystem- und Logistik) 7
Release-Prozess aus Sicht des OEM Zeitlicher Ablauf Die Integration einer Software in das Gesamtsystem besteht dementsprechend aus drei unterschiedlichen Integrationsstufen. Diese Tests werden aufeinanderfolgend gestartet, laufen aber parallel ab. Wenn die Quickchecks einer Integrationsstufe erfolgreich durchlaufen wurden, beginnt der nächste Testschritt. Nachlieferungen von Software werden nur bei Show-Stoppern zugelassen. An einem vorher definierten Zeitpunkt findet der System-Freeze statt. Ab diesem Zeitpunkt sind keine Nachlieferungen mehr zulässig und die abschließenden Tests werden durchgeführt. Release-Prozess aus Sicht des OEM Theorie Bei den OEM werden Integrationsstufen mit definierten Funktionshüben eingeplant. Zu Beginn der Entwicklung sind die Abstände größer, zwischen zwei und vier Monaten. Kurz vor SOP sind die Funktionshübe nicht mehr so komplex und kommen in Abständen von zwei bis sechs Wochen. Release-Prozess aus Sicht des OEM Realität Durch ungeplante Bugfix-Maßnahmen werden Fehlerbehebungsschleifen zwischen die geplanten Integrationsstufen geschoben. Dies ist darauf zurückzuführen, dass Fehlerbehebungen ungeachtet des Soll-Prozesses nachgeliefert werden. Bugfix-Maßnahmen und Funktionshübe werden in der Praxis oftmals nicht getrennt. Wegen ungeplanter Fehlerbehebungsschleifen müssen Kapazitäten für die Weiterentwicklung und Absicherung überplant werden. Kapazitäten stehen oft nicht ausreichend zur Verfügung. Ungeplante Schleifen können somit eine zeitliche Verschiebung bis zum finalen Produkt bedeuten. Gleichzeitig besteht die Gefahr, dass die Nachvollziehbarkeit und Transparenz der durchgeführten Aktionen wegen den zwischengeschobenen Schleifen leidet. Release-Prozess aus Sicht des OEM Best Practice Bei jeder Integrationsstufe ist mit Fehlern zu rechnen. Daher sollten Fehlerbehebungsschleifen von Anfang an mit eingeplant werden. Dies sichert eine höhere Qualität und Transparenz im SW-Entwicklungsprozess. Im Endeffekt ergibt sich dabei ein gleicher Zeitaufwand wie bei zwischengeschobenen Schleifen. Gesamtsystem Teilsystem Release SWL Komponente Komponententest KF SF1 SF2 Nachlieferung bei Legend: Show-Stopper SWL Softwarelieferung KF KomponentenFreeze SF1 System Freeze 1 Release SF2 System Freeze 2 SR System Release QC Quick Check Bild 5: Releaseprozess: zeitlicher Ablauf (Bildquelle: ESG Elektroniksystem- und Logistik) QC QC Funktionstests Nachlieferung bei Show-Stopper Release SR Systemfunktionstest mit Blick auf Gesamtsystem, Querwirkungen und Besonderheiten System Release t 8
Funktionshub Funktionshub Funktionshub Bild 6: Release-Prozess aus Sicht OEM: Theorie (Bildquelle: ESG Elektroniksystem- und Logistik) Funktionshub Bugfix Funktionshub Funktionshub Bugfix Bild 7: Release-Prozess aus Sicht des OEM: Realität (Bildquelle: ESG Elektroniksystem- und Logistik) Funktionshub Funktionshub Bugfix Funktionshub Bugfix Bild 8: Release-Prozess aus Sicht des OEM: Best Practice (Bildquelle: ESG Elektroniksystem- und Logistik) 9
3. Dokumentation und Artefakte In diesem Kapitel wird beschrieben, welche Dokumente bei der Auslieferung einer Komponente (ECU) bzw. eines Software-Standes zu einem Release bereitgestellt werden sollten. 3.1. Übersichtsdokument Die Praxis hat gezeigt, dass der beste Einstieg in eine Release-Dokumentation für den Kunden mit einem Übersichtsdokument zu erreichen ist. Folgende Aspekte sollten in diesem zusammenfassenden Dokument Erwähnung finden: Kurzbeschreibung des Releases, Einsatzzweck (Bauphase, Erprobungsfahrt, Zwischenrelease, ). Eine eindeutig strukturierte Nomenklatur in der Release-Bezeichnung ist anzustreben. Damit kann dann sicher zwischen Haupt-Releases oder z. B. Bugfix-Releases unterschieden werden. Zudem ist es sinnvoll, in der Nomenklatur zu benennen, ob die Software schnittstellenkompatibel zum Vorgänger ist oder auch nicht. Übersicht der gelieferten Unterlagen, Fahrplan durch die Dokumentation Projektterminplan mit Bezug auf die aktuelle Phase im Projekt (A-, B-, C-Muster) Kurze Beschreibung des vereinbarten Regelablaufs bzw. des Vorgehensmodells für ein Release Netzwerk-Beschreibung n Release n-1 Netzwerk-Beschreibung n+1 Release n Wochen vor Auslieferung an OEM -19-18 -17-16 -15-14 -13-12 -11-10 -9-8 -7-6 -5-4 -3-2 -1 0 1 2 3 4 5 6 7 Vorab-Freeze alle Anforderungen bekannt Freeze Fahrfähiger Stand an OEM alle Anforderungen besprochen Basisauslieferung an OEM Integration Gemeinsame Freigabe Lieferung der Komponenten OEM/Zulieferer Programmierung / Integration / Prüfung Bedatung SW- Test HIL SW- Test Fzg Prüfung OEM Bild 9: Beispiel Regelablauf Software-Release (Bildquelle: ZF Friedrichshafen) 3.2. Detaillierte Releasedokumentation 3.2.1. Lieferumfang Hier ist eine detaillierte Übersicht der gelieferten SW-Komponenten bzw. des Steuergerätes einschließlich einer Variantenübersicht z. B. in Form einer Matrix zu erstellen, die alle zur Integration der Komponente notwendigen Informationen enthält. So sollten z. B. die ein Software-Release kennzeichnenden Informationen zu Software-Version, Konfigurationsdateien, Flashbootloader, HW usw. hier detailliert und klar benannt werden. Bei Bedarf sollten darüber hinaus Parametersätze und Diagnosebedatungen ebenfalls beschrieben werden. Als vorteilhaft hat sich ebenfalls erwiesen, eine Liste der integrierten Software-Fremdkomponenten (z. B. OEM-Standardsoftware) inklusive der Versionsnummern beizufügen. In diesem Zusammenhang kann es auch sinnvoll sein, zusätzlich die exakten Daten der verwendeten Buildumgebung wie z. B. Compilerversionen zu beschreiben. In Tabelle 1 wird beispielhaft die Matrix-Beschreibung des B1-Musterstandes eines Steuergerätes beschrieben. Ähnliche Darstellungen können auch bei reinen SW Lieferungen verwendet werden. 10
Tabelle1: Beispiel für Kenndaten eines Steuergeräte-Releases: Musterstand Variante Tier 1 Artikel-Nr. 1. Flexray Single XY 2. Flexray 4fach XY 3. Flexray 8fach XY Kennzeichnung OEM LU Nr. (Lieferumfang) OEM ZB Nr. (Zusammenbau) SW HW SW Nummer HW Nummer B1 MECH DBC-File OEM... Mechanik Index ECU-Filename... Standard SW Package... OEM Flashbootloader Stand... SW-Sachnummer Erweiterte SW Sachnummer... 3.2.2. Systembeschreibung Neben der grundlegenden Kennzeichnung des Produktes sollte zu einem Release immer ein klarer Bezug zur System- bzw. Steuergeräteebene beigefügt werden. Dies ist für den Kunden insbesondere dann hilfreich, wenn er Funktionalitäten an einem Release überprüfen will und hierzu die entsprechenden Rahmenbedingungen schnell verfügbar haben will. Zu der Systembeschreibung gehören z. B. folgende Informationen: Schaltplan des Steuergerätes Schnittstellenbeschreibung des Steuergerätes bzw. Systems Blockschaltbild Steckerbeschreibung 3.2.3. Lebenslauf/Änderungshistorie Die Aufgabe des Lebenslaufes ist es, dem Kunden einen knappen aber vollständigen Überblick über den Änderungsumfang des Release zu geben. Als zentrales Element enthält es eine Auflistung der Software Änderungen bezogen auf das Vorgänger-Release. Idealerweise werden die Änderungen aus dem Workflow- Managementsystem exportiert, um Konsistenzprobleme von Software und Dokumentation zu vermeiden. Um die Kompatibilität von Hardware, Software und Werkzeugen eindeutig zu dokumentieren, ist es sinnvoll, das Dokument Lieferumfang zu referenzieren. Dieser wichtige Block einer Releasedokumentation kann häufig von Release zu Release übernommen werde, bei Änderungen in System bzw. Steuergeräte-HW sind Hinweise zur Kompatibilität des Software-Release zu verschiedenen Hardware Ständen ebenfalls zu dokumentieren. 11
Es ist sinnvoll, eine Unterscheidung zwischen umgesetzten Anforderungen und Fehlerbehebungen vorzunehmen. In der Praxis haben sich Tabellen mit folgenden Spalten als Kategorien bewährt: Fortlaufende Nummer Eindeutige Lieferanten-ID (Referenz auf Change-Management-System des Lieferanten) Headline der Änderung Kennzeichnung Anforderung/Fehlerbehebung Eindeutige Kunden-ID (Referenz auf Requirements- oder Problem-Management-System des Kunden) 3.2.4. Funktionsliste Im Zuge der Releaseplanung eines Projektes werden die zu einem Release umzusetzenden Funktionen festgelegt. Diese sollten hier nochmals aufgeführt werden und es sollte eine Referenzierung auf die gültigen Anforderungsdokumente vorgenommen werden. Es soll dargestellt werden, ob die geplante Funktion realisiert wurde. Wurde sie nur teilweise realisiert, sollte eine kurze Darstellung der Einschränkungen ergänzt werden. Eine Herausforderung ist der Trend zu einem immer fein granularerem Reporting, welches unter Umständen bis auf die Ebene von Einzelanforderungen reichen kann. Hier ist mit dem Kunden zur Aufwandsminimierung unbedingt eine sinnvolle Tiefe bzw. eine mittlere Granularität zu vereinbaren. So kann ein Bezug auf übergeordnete Funktionen oder Funktionsgruppen sinnvoll sein. An vielen Stellen wird hierfür der Begriff Feature verwendet. Durch eine hohe Lastenheftqualität und -stabilität wird das Erstellen einer aussagekräftigen Funktionsliste unterstützt. Die Wichtigkeit einer solchen Liste wird allerdings bei schlechterer bzw. volatiler Lastenheftqualität umso bedeutender. Behobene Fehler sind bereits in der Änderungshistorie dargestellt. Hier in der Funktionsliste sollten daneben Fehler aufgeführt werden, die bekannt, aber noch nicht behoben sind ( known issues ). Dies erhöht die Transparenz und stärkt das Vertrauen. Es ist weiterhin sinnvoll Metriken zu dem erreichten Funktionshub zwischen den Releases zu erstellen. Wie entwickelt sich die Anzahl der Anforderungen über die Projektlaufzeit, werden die vereinbarten Funktionshübe erreicht, wie groß sind die Abweichungen? Bild 10 zeigt angenommen über einen fiktiven Projektverlauf den Umsetzungs- und Erfüllungsgrad. Dabei wird unterschieden zwischen Anforderungen die zum Release geplant und umgesetzt wurden, sowie zwischen Anforderungen die zwar geplant waren aber nicht umgesetzt werden konnten. 3.2.5. Verifikationssergebnisse Die Aufgabe dieses Dokumentes ist es, Verifikationsergebnisse des Lieferanten dem Kunden in einer geeigneten Weise zur Verfügung zu stellen. Im Rahmen einer Prozessabstimmung vereinbaren Kunde und Lieferant zu Projektbeginn, welche Testmethoden und welche Test-Endekriterien im Projekt zum Einsatz kommen. Um den Aufwand für Kunden und Lieferanten zu minimieren und aus Gründen des Knowhow Schutzes, ist es notwendig eine geeignete Abstraktionsebene für die Verifikationsergebnisse zu vereinbaren. Im Normalfall ist es ausreichend, die Testabdeckung bezogen auf die Kunden- Requirements zu berichten (siehe auch Abschnitt 3.2.6). Die detaillierten Testergebnisse werden nur dann zur Verfügung gestellt, wenn dies vertraglich vereinbart ist. Ein guter Kompromiss ist oft, dass detaillierte Ergebnisse eingesehen werden können, jedoch nicht übergeben werden. Anmerkungen: Vom definierten Dokumentumfang kann je nach Projektphase abgewichen werden. In frühen Phasen ist der Dokumentenumfang evtl. unvollständig oder angepasst. Bei mehreren Lieferungen und Rekursionsschleifen zu einem Release kann es sinnvoll sein, eine Delta-Betrachtung durchzuführen. 12
1400 1280 1300 1300 1300 1200 1100 1158 1000 900 977 Anforderungen 800 600 500 600 700 790 umgesetzt nicht umgesetzt Zum Release geplant 400 300 360 200 100 90 60 77 58 20 0 0 B0 B1 B2 C0 C1 C2 D0 Release Bild 10: Umsetzungsstatus Lastenhefte (Bildquelle: Leopold Kostal) 3.2.6. Metriken Metriken dienen zur gesamtheitlichen Bewertung eines SW-Release und sind damit ein wesentliches Element des Risiko-Managements. In vielen Fällen ist es sinnvoll, die jeweils gleichen Metriken über den Projektverlauf zu dokumentieren, um daraus Trend- Aussagen ableiten zu können. Daher ist die sorgfältige Definition der Metriken beim Projektstart besonders wichtig. Jede spätere Änderung erfordert ggf. Korrekturrechnungen und erschwert in jedem Fall Aussagen zum langfristigen Trend. In vielen Projekten haben sich die folgenden Metriken bewährt: Anzahl der umgesetzten Funktionsänderungen ( Funktionshub ) Anzahl der behobenen Fehler Anzahl der noch nicht behobenen Fehler bzw. der offenen Punkte ( known issues ) Testabdeckung bezogen auf die Anforderungen Testabdeckung bezogen auf den erstellten Code (z. B. Function Coverage oder Code Coverage ) Metriken zur Bewertung der Produkt-Qualität (z. B. MISRA oder HIS) Maturity Index Der Maturity Index ist ein sehr nützliches Werkzeug zur Bestimmung der Produktqualität oder Produktreife im Laufe der Produktentwicklung. Er berücksichtigt Probleme und Änderungswünsche je nach deren Schweregrad und Bearbeitungsstatus. Details hierzu finden sich im Glossar. Ressourcenbedarf (bezüglich RAM, ROM und Laufzeit, siehe Bild 11) 13
BELEGUNG ROM (DATENBEREICH) 600 500 400 KBYTE 300 200 Summe Nutzbar 85 % 100 0 Bild 11: Beispiel Ressourcenverlauf Ist/Soll (Bildquelle: ZF Friedrichshafen/ZVEI) 3.2.7. Freigaben Mit diesem Dokument werden die Freigabeunterlagen der beteiligten Entwicklungsabteilungen in einem mehrstufigen Prozess verdichtet (siehe Bild 12). Die Freigabe zu einer definierten Verwendung eines Software-Release wird vom Projektleiter des Lieferanten ausgesprochen und dokumentiert. Diese basiert auf den Freigabeempfehlungen der beteiligten Funktionen (z. B. SW-Entwicklung, Test, Qualitätssicherung, Safety-Management). Abhängig von den Projektphasen können unterschiedliche Freigabe-Level geprüft und erteilt werden. Dies sind zum Beispiel: Eine Freigabe für die Erprobung im Fahrzeug auf einem abgesperrten Prüfgelände für speziell zugelassene Fahrer in der Prototypenerprobung Eine Freigabe für die Erprobung im Fahrzeug auf öffentliche Straßen für einen eingeschränkten Personenkreis, der das Fahrzeug bewegen darf, Eine Freigabe für die uneingeschränkte Verwendung des Fahrzeugs auf öffentlichen Straßen. 14
Kunde Freigabe Projekt Freigabe- Empfehlung Freigabe- Empfehlung Freigabe- Empfehlung Software- Projekt Safety (HW + SW) Elektronik- Hardware Freigabe- Empfehlung Freigabe- Empfehlung Freigabe- Empfehlung Projekt Q-Bericht Software- Entwicklung Software- Lieferant Software- Testmanager Qualitäts- Beauftragter Bild 12: Beispiel für einen mehrstufigen Freigabeprozess (Bildquelle: ZF Friedrichshafen) 15
4. Leitlinien für die Anwendung in der Praxis Für eine optimale Umsetzung des Software- Release-Prozesses in enger Kooperation zwischen den OEM s und ihren Partnern auf Zulieferer- und Dienstleisterseite müssen zwei zentrale Herausforderungen adressiert werden: eine hohe Transparenz über den Status der Software ist die Basis für nahtlose Zusammenarbeit und Vertrauen zwischen allen Partnern, und Stabilität im Prozess ist gerade in kritischen Projektphasen essentiell, um Reibungsverluste zu vermeiden. Für die anzustrebende Transparenz sind Konsistenz und Kontinuität der Informationen von entscheidender Bedeutung. Sie bilden die Grundlage für eine effiziente Kommunikation. Heute sind die Austauschformate für die Dokumentation von Software-Releases zwischen Kunde und Lieferant für jeden Kunden unterschiedlich. Eine Vereinheitlichung der Schnittstellen insbesondere zu Change- und Problem- Management ist dringend anzustreben. Durch hohe Transparenz muss sichergestellt werden, dass Kunde und Lieferant ein einheitliches Verständnis über Anforderungen und Erwartungen für jedes Software-Release haben. Dies kann durch Projekt- und Release- Kick-offs, in denen Erwartungen und Umfang gemeinsam geklärt werden, und durch eine transparente Darstellung aller relevanten Informationen in Release-Planung und Dokumentation sichergestellt werden. Dabei ist es wichtig, dass eine geeigneten Abstraktionsebene gemeinsam definiert wird, die nicht zu feingranular ist ein zu viel an Detailinformationen führt nicht zu höherer Transparenz. So soll natürlich in der Release-Dokumentation der Grad der Anforderungserfüllung berichtet werden aber nicht durch ein paralleles Reporting zur Anforderungsmanagementdatenbank (z. B. in DOORS), sondern in einer mittleren und pragmatischen Granularität: entscheidend ist eine gute Übersicht, was dieser Softwarestand kann und was nicht. Zum Aufbau einer Vertrauensbasis zwischen Kunde und Lieferant können initiale Prozess-Qualitätsbewertungen (z. B. SPICE- Assessment), die bei Bedarf im Projektverlauf aktualisiert werden können, einen wichtigen Beitrag leisten. Dies kann hilfreicher sein als ein zu feingranulares Reporting im Projekt. Eine rechtzeitige Planung und Abstimmung der Release-Inhalte ist Grundlage für eine qualitativ hochwertige und termingerechte Lieferung. Ungeplante Änderungen führen leicht zu einem Terminverzug im Projekt. Die Zahl der zu liefernden Software-Releases muss in der Projektplanung definiert und so weit wie irgend möglich eingehalten werden übertriebener Aktionismus durch tägliche Releases schadet nur der Stabilität des Prozesses. Tägliche Softwarelieferungen im Rahmen agiler Entwicklung, z. B. durch Nightly Builds mittels Continuous Integration können insbesondere auf Komponenten-Ebene durchaus sinnvoll sein. Sie sind nicht als Software- Release im Sinne dieses Leitfadens zu sehen, da dabei deutlich weniger formale Anforderungen zu erfüllen sind. Späte Änderungen aufgrund von Kundenentscheidungen müssen gemeinsam bewertet werden. Die Balance zwischen Termintreue, Qualität und Änderungsbedarfen des Kunden kann nur in enger und offener Kommunikation erfolgreich optimiert werden. Dazu sind vereinbarte Metriken und eine gemeinsame Bewertung eine wichtige Basis. Bei der Planung der Releases ist darauf zu achten, dass Testergebnisse und damit Korrekturen in Folge-Releases einfließen können. In der Release-Planung ist genauso die Definition unterschiedlicher Freigabe-Levels und damit Testumfänge pro Release je nach Projekt-Phase zu dokumentieren. Die Unterscheidung zwischen Bugfix auf Seitenzweig und Weiterentwicklung auf Hauptzweig ist notwendig. Dabei ist der Umfang von Bugfixes, die nicht im Hauptzweig integriert werden können, auf das Notwendigste zu beschränken. 16
Die Übergabe eines Software-Release an den Kunden sollte durch ein Release-Review begleitet werden. Hier wird der erreichte Entwicklungsstand an den Anforderungen und Erwartungen des Kunden gespiegelt und es wird ein gemeinsames Verständnis hergestellt, für welche Zwecke das Release verwendet werden kann. Eine Bewertung der Entwicklungsphase seit dem zugehörigen Release-Kick-off ( Lessons learned ) ist sinnvollerweise ein zusätzlicher Bestandteil eines Release-Reviews. 17
5. Definitionen und Begriffe Applikationsstand Grundbedatung der Integrationssoftware (Gesamtsoftware) mit neutralen Daten/Konfigurationswerten, um eine Grundfunktionalität sicherzustellen. Bugfix Behebung eines festgestellten Fehlers bzw. einer Fehlfunktion. Der Bugfix wird erst zur nächsten offiziell geplanten Softwarelieferung wirksam. Ein Bugfix beschreibt immer die Behebebung eines Fehlers und keine neue Funktionalität (vgl. Funktionshub. Feature). Feature Übergeordnete Funktionalität oder Funktionsgruppe. Siehe auch Funktionshub. Freigabe Eine Freigabe bestätigt, dass eine (Software-) Komponente oder ein (Software-) Release für bestimmte Zwecke eingesetzt werden kann. Funktionshub Geplante oder implementierte neue Funktionalität aus Sicht der bestehenden Funktionalität einer Teilkomponente. Ein Funktionshub beschreibt keinen Bugfix (siehe dort). Integrationsstufe Gesamtheit aller geplanten und durchgeführten Funktionshübe, Bugfixes sowie die positiv abgeschlossener Absicherungsmaßnahmen für diesen Meilenstein. Kalibrationsstand Kalibrierte Software mit erweiterten Daten bzw. erprobten Datensätzen auf Basis des Applikationsstands Known Issue Ein bekanntes und unter gewissen Bedingungen bzw. Konstellationen auftretendes Problem in einer Softwarekomponente, welches zum aktuellen Zeitpunkt noch nicht behoben wurde. Maturity Index (Produkt-/Release-Reife) Der Maturity Index hat das Ziel, die Produktreife in einer Kennzahl zusammenzufassen. Dabei werden die Issues entsprechend ihrer Schwere und ihrem Bearbeitungszustand gewichtet (siehe Tabelle 2). Alle Release-relevanten Fehler, Änderungswünsche und Feature-Implementierungen werden gleichwertig als Issue behandelt. Der Maturity Index ergibt sich letztlich als die Summe der gewichteten Issues und wird sinnvolerweise als Grafik über die Zeit aufgetragen. Tabelle 2: Wichtungsfaktoren zur Ermittlung des Maturity-Index Severity Showstopper Major Minor Status New or 40 20 10 Analyzing Open or 20 10 5 Implementing Testing 10 5 1 Closed or Rejected 0 0 0 18
Alle Implementierungs- Tasks für Release sind definiert Test und Bugfixing läuft Maturity Index Gewünschte Testabdeckung erreicht 1600 1400 1200 1000 Fehlerbehebung und Verifizierung läuft lmplementierung ist fortgeschritten Testing startet 800 600 400 200 0 01.01.2013 01.02.2013 01.03.2013 01.04.2013 01.05.2013 01.06.2013 Maturity Index Release Zeitpunkt Bugfixing und Verifizierung läuft Blocking Issues sind gelöst, der letzte Testlauf kann starten Bild 13: Typischer Verlauf des Maturity-Index (Bildquelle: TTTech Computertechnik) Regelablauf Terminübersicht der geplanten und abgestimmten Projektphasen und Meilensteine mit dem OEM, sowie der erwarteten Ergebnisse in zeitlicher Relation zur Auslieferung für diese Integrationsstufe. Release Die bestimmte fertige und veröffentlichte Version/Stand einer Software, das für einen spezifischen Zweck bereitgestellt wurde (Bsp. Test oder Produktion). Mit einem Release geht eine Veränderung der Versionsbezeichnung, meist ein Hochzählen der Versionsnummer einher. Release-Kick-off Ein Release-Kick-off sollte in Form eines Präsenz-Meetings zwischen Kunden und Lieferanten stattfinden. Teilnehmer sind Entscheidungsträger, Projektleiter und technische Experten. Im Meeting präsentiert der Kunde: Release-Ziele Akzeptanzkriterien und der Lieferant: geplante Absicherungsmaßnahmen und ggf. eine detaillierte Terminplanung. Ziel des Release-Kick-offs ist der Abgleich der Erwartungen beider Seiten und die Definition von Regeln bezüglich Kommunikation, Prozessen, Eskalation, etc. Release-Review Teilnehmer und Format entsprechen dem Release-Kick-off. Im Meeting präsentiert der Kunde die ggf. überarbeiteten: Release-Ziele und Akzeptanzkriterien Der Lieferant präsentiert: den erreichten Stand der Entwicklung Reifegrad des Produkts Absicherungsmaßnahmen Testabdeckung Die Release-Notes werden gemeinsam gesichtet und akzeptiert und die weiteren Schritte bis zur Freigabe des Release werden abgestimmt. Ein weiteres Element des Release-Reviews ist die Bewertung der Entwicklungsphase seit dem Release-Kick-off bezüglich der Punkte, die sich bewährt haben und der Punkte, die einer Verbesserung bedürfen (im Sinne von Lessons learned ). 19