Display Key (DKEY) Projekt

Im Auftrag der BMW AG, vgl. Projekt 24

1. Vorwort / Rahmen der Ausführung

   Das (Display Key) DKEY Projekt wird möglichst aus der Perspektive des Projektleiters und Testmanagers dargestellt.

   Weitere Umstände bestimmen den Rahmen der Ausführung und grenzen sie ein.

   • Technischer Fokus:

     • Die Hardware-Seite des Projekts bleibt ausser Acht: Die Verantwortung dafür lag beim Auftraggeber - in enger Absprache mit den verantwortlichen Auftragnehmern.
       

     • Auch spiegelt die Beschreibung vorwiegend Verhältnisse im Zeitraum 2017-2018 (die zweite Entwicklungsphase) wider. Seit 2019 wird das DKEY Produkt - in dieser Form - nicht weiter-entwickelt: Alle vorgesehenen Funktionen wurden erfolgreich implementiert. Zudem wird eine neue Technologie nach und nach eingeführt: die Integration der DKEY-Funktionen ins Handy des Fahrers (vgl. z.B. iPhone as BMW car key). Nichtsdestotrotz wird das "klassische" DKEY, bis ans geplante Ende des Lebenszyklus weitergepflegt (z.B. Bug Fixes).

   • Rechtliche Einschränkungen:
     Vertrauliche Informationen zum Projekt dürfen nicht ohne Zustimmung der Rechtsinhaber veröffentlicht werden. Aus diesem Grund gelten folgende Regeln:

     • Aufgaben, Arbeitsschritte, Ergebnisse werden möglichst prozessbezogen dargestellt - wie z.B. der VDA (Verband der Automobilindustrie) in seinen Standards zur Sicherung der Prozess-Qualität darstellt.

     • Es werden keine Projekt-Artefakte - auch nicht Auszüge davon - angezeigt. Projektunterlagen liegen auf Share-Directories, deren Zugriff streng reglementiert ist.

     • Um Umfang und Aufteilung der Aufgaben verständlicher darzustellen, werden in anonymisierte Form Teams vorgestellt. Diese Darstellung widerspiegelt nicht die vertraglichen Verhältnisse.

2. Definition der Aufgaben

   1. Teilprojekt Softwareentwicklung

      1. Die Aufteilung der Software

         Display Key (DKEY) ist der Name eines Steuergerätes, das u.a. als elektronischer Autoschlüssel dient . Das Produkt gibt dem zugeordneten Entwicklungsprojekt seinen Namen.

         Bild 1: Logische Darstellung der HW-Architektur von DKEY

         Bild 1 zeigt eine einfache Skizze der Hardware-Architektur des Steuergerätes, welche die Aufteilung der Aufgaben im Projekt erklärt. Jeder der (3) Rechtecken stellt einen (logischen) Controller dar. Die Pfeile verdeutlichen vorhandene (beidseitige) Datenflüsse. Das DKEY-Gerät steht in Verbindung:

         mit dem User	via Controller [1], der das Touch-Panel bedient.
         mit dem Fahrzeug	via Controller [2], der formatierte und verschlüsselte Meldungen schreibt bzw. liest.

         Ab April 2017, übernahm ich Leitung und Management der (gesamten) Softwareentwicklung. Zu diesem Zeitpunkt wurde der Kreis der beteiligten Teams umgestaltet.

         SW-Entwicklung Team	n MA	Aufgabe (n)
         SWT-1	> 3 MA	Basic Software auf allen Controller / Hardware nahe Programmierung
         SWT-2	3-4 MA	Weiterentwicklung der DKEY GUI (Menüführung per Touch Panel)
         SWT-3	1-2 MA	(Weiter-)Entwicklung der (Kommunikations-)Software auf dem Transponder

         Tab. 1: An der Softwareentwicklung beteiligte Teams (ab 2017)
         Zum Zeitpunkt meiner Übernahme (zwei Jahre nach Projektbeginn ) waren die Hardware- und die Software- Architektur festgelegt und in die Software und Hardware -Konfiguration festgeschrieben.
         • Die Entwicklung der Basis-Software war weitgehend abgeschlossen.
         • Die GUI-Software unterstützte schon einen Teil der vorgesehenen Funktionen.

         Drei Schwerpunkte der Softwareentwicklung standen vor:

         1. Team SWT-1, Basis-Software
            sollte - z.B. nach Erweiterung der GUI-Funktionalität - alle ursprünglichen Anforderungen erfüllen.

         2. Team SWT-2, GUI-Software
            sollte zusätzliche Funktionen unterstützten. Zudem mussten Änderungen des Lastenheftes oder Korrekturen (Bug Fixes) für existierende Funktionen berücksichtigt werden.

         3. Team SWT-3, Transponder-Software
            sollte, nach eventueller Erweiterung bzw. Anpassung von anderen Softwaremodulen, alte und neue Anforderungen bezüglich der Kommunikation mit dem Fahrzeug (z.B. Geschwindigkeit, Zuverlässigkeit) erfüllen.

         DKEY läuft auf eine angepasste Linux-Ubuntu Plattform, deren Kernel, zusammen mit allen nötigen Treibern, die Basis-Software darstellt. Alle Module sind in C geschrieben. Es gab Pläne, die Applikationsebene der GUI-Software (das Display-Menü) auf C++ zu übertragen: Refactoring und Weiterentwicklung sollten Kenngrößen der Softwaremetrik bessern, und - mittelbar - den Quelltext einfacher lesbar und modifizierbar machen. Das Vorhaben wurde aus Zeitgründen nicht weiter verfolgt.

      2. Der Entwicklungsprozess

         Der umgesetzte Entwicklungsprozess leitet sich aus 2 Paradigmen ab:

         1. Das erste Paradigma ist von einer durchdacht vorausschauenden Vorgehensweise strukturiert. Darauf basieren Entwicklungsmodelle wie V-Modellen und abgeleitete Versionen. Relevant sind sie, insbesondere weil sie z.B. in Standards wie ASPICE (Automotive Software Process Improvement and Capability Determination), FuSi (Functionssicherheit, Functional Safety) ) (implizit) vorausgesetzt werden. Solche Standards werden als Maßstab vertraglich verankert.

         2. Alternative Paradigmen gehören zu agilen Verfahren: flüssig, leichtfüssig, wendig, kommunikationsintensiv, iterativ - um Planungsobjektive flink an veränderte Umstände zu orientieren. Genauer formuliert, wir übernahmen Methoden / Techniken aus scrum. Gerade in Projekten der verteilten Entwicklung - mit Teams, die sich selten in der realen Welt treffen - steht die Koordination der Aufgaben aller Mitwirkenden und die Rücksprache mit den Auftraggebern in der Vordergrund - wie z.B. in scrum-meetings angestrebt. (Sehr hilfreich war die Tatsache, dass das Tool ASCENT JIRA unterstützt scrum out of the box - via Funktionen, wie scrum boards, reports, quick filters, etc.

         Theoretisch vertragen sich beide Paradigmen kaum. In der Praxis versucht der Projektleiter mit scrum-Techniken, die strengen Vorgaben der übergeordneten Planung zu erfüllen. In diesem Projekt war das zentrale Dokument dazu das sogenannte Release-Plan, wo Informationen aus beiden Welten zusammengeführt wurden. (Anm.: Der Release-Plan ist eine EXCEL-Mappe - vgl. Office Anwendungen)

   2. Teilprojekt Softwaretest

      1. Übersicht

         Das Testen eines Steuergerätes wie DKEY, ist eine vielfältige Aufgabe.

         Geht es um Software-Verifizierung	, wird die Aufgabe nach Software-Modulen aufgeteilt.
         Geht es um Software-Validierung	, wird eine realistische Nachbildung von Situationen angestrebt, denen der User begegnet (vgl. Use Cases).

         Test-Team	n MA	Aufgabe (n)
         TT-1	> 4 MA	Verifizierung der Basic-Software auf allen Controllers inkl. Test- Entwicklung & Durchführung auf einem HiL
         TT-2	3-4 MA	Verifizierung / Validierung der GUI-Software (alte und neue Codes) inkl. Test- Entwicklung & Durchführung auf einem HiL
         TT-3	1 MA	Verifizierung der Kommunikations-Software auf dem Transponder
         TT-4	> 3 MA	Validierung von DKEY am Fahrzeug

         Tab. 2: An dem Software (& Hardware) -Test beteiligte Teams (ab 2017)

         Jedes Entwickler-Team war verantwortlich für die Entwicklung - und Durchführung - von Verifizierungstests, welche die eigenen Quelltexte betrafen - ob White-Box-Tests (ggf. inkl. Unit-Tests) oder Black-Box-Tests. Mit dem Auftraggeber wurden im Vorfeld Abdeckungskriterien des Tests - u.a. Code Coverage - definiert, die erfüllt werden mussten.

         Unabhängig von Ergebnissen sonstiger Entwickler-Tests wurde eine neue Softwareversion erst offiziell freigegeben, wenn folgende Testergebnisse vorliegen und vom Auftraggeber nachweislich angenommen wurden:

         Testname	Team	Zielobjekt	Erläuterung
         PKI-Test	TT-1	DKEY-Basisprogramm	Solcher Test dokumentiert das Verhalten des Steuergerätes unter vorgegebenen Stress- bzw. Grenz- Situationen - Dank der bei TT-1 vorhandenen Spezielleinrichtungen, wie Kältekammer etc.
         PKI-Test	TT-3	DKEY-Transponder	Solcher Test analysiert spezielle Eigenschaften der Funk-Kommunikation zwischen DKEY und dem (virtuellen) Fahrzeug.
         Funktionstest [Smoke-Test]	TT-2	DKEY-GUI	Dieser Black-Box Test prüft im Vorfeld, ob Änderungen der Software negative Seiteneffekte hervorruft - gleich einem Regressionstest für wenige kritische Szenarien. Die Dauer der Durchführung beträgt ca. 0,5 Tag
         Funktionstest [vollständig]	TT-2	DKEY-GUI	Dieser Black-Box Test prüft alle Funktionen (möglichst ausführlich). Allein die Dauer der Durchführung beträgt ca. 5 Tage.
         PKI-Test	TT-2	DKEY-GUI	Eigenschaften des Verhaltens der DKEY-Steuergeräte während des vollständigen Funktionstests werden statistisch ausgewertet.
         Validierung	TT-4	DKEY	TT-4 testet das Steuergerät am Fahrzeug. Die Fahrer wiederholen - über eine angemessene Zeitdauer - vorgegebene Szenarien, welche Handlungen der Zielanwender nachahmen.

         Tab. 3: Mindestumfang der Testreihe vor Freigabe einer neuen Version der DKEY-Software

         Anmerkungen:
         

         • Vorteile der Tests auf dem HiL:
           Bis auf den Test am Fahrzeug, laufen (fast) alle Tests automatisch auf jeweils der Zielsoftware angepassten HiL-Einrichtungen. Dadurch kann eine enorme Menge von Testfällen unermüdlich durchgeführt, um alle denkbaren Situationen zu wiederholen - z.B. um die sogenannte "Pfad-Überdeckung" zu verbessern vgl. z.B. White-Box-Tests. Auch bildet die statistische Auswertung solcher Fülle an Ergebnissen eine belastbare Grundlage der PKI-Auswertung.

         • Notwendigkeit der Tests am Fahrzeug:
           Trotz des unübersehbaren Nutzens von HiL-Einrichtungen gibt es einige Einschränkungen: Die Schnittstelle zum Fahrzeug ist simuliert: Um den Entwicklungsaufwand der simulierten Schnittstelle zu optimieren, wurden bestimmte Mechanismen vereinfacht, die unter Umständen Ergebnisse verfälschen. Deswegen ist eine manuelle Durchführung von Tests am Fahrzeug von BMW zwingend festgeschrieben.

      2. Rolle des Testmanagers

         Teamübergreifend sorgte ich - in enger Absprache mit dem Auftraggeber - dafür, dass alle Softwaremodule (vgl. Tab. 3) im nötigen Umfang verifiziert wurden.

         Testentwicklung (und Durchführung):
         
         • Die Entwickler(-Teams) waren dazu verpflichtet, Unit-Test für mindestens 90% der relevanten Software-Funktionen zu schreiben - es sei denn, äquivalente Funktionstests existieren.
         • Auch für weiteren Tests wurden Testabkeckungskriterien festgelegt - entweder im Sinn einer White-Box-Betrachtung (im Bezug auf die Quelltexte) oder im Sinne der Black-Box-Betrachtung (im Bezug auf die zu unterstützenden Funktionen)

         Anm.: Dem Wunsch des Auftraggebers entsprechend lag mein Hauptaugenmerk beim Testen der DKEY-GUI, u.a. weil 2017 die Entwicklung des in Python geschriebenen "Testframeworks" für das HiL nicht vollständig abgeschlossen war. Zudem waren die dazugehörigen Testfälle / Testszenarien (auch in Python implementiert) beileibe nicht ausreichend.

         Testdokumentation (vgl. auch Dokumentation):
         Eine wesentliche Aufgabe war dafür zu sorgen, dass alle nötigen Dokumente zur Charakterisierung der Tests entweder auf vorgesehenen Shares (einzelne Dokumente) oder auf der Wiki-Dokumentation verfügbar sind. Testspezifikation, Testfälle, Testframework, rohe Testergebnisse, analysierte Testergebnisse (u.a. Bug Reports, Berechnung der PKI, Abdeckungsnachweis bzw. "Traceability"). Für den Funktionaltest wurde angestrebt, SW-Spezifikationen - ob Lastenheft oder Pflichtenheft - mit Test-Spezifikationen zu verlinken - idealerweise in beiden Richtungen.

3. Verwendete Tools

   BMW stellt (vertraglich) explizite Anforderungen hinsichtlich der Prozess -Erfassung und -Kontrolle in den beauftragten Projekten (vgl. ASPICE), bis hin zur inneren Organisation der beteiligten Firmen (vgl. ISO 9000-family). Bezüglich der DKEY-Projektbearbeitung trug entscheidend zum Erfolg die Tatsache bei, dass ausgereifte Tools, im Intranet der BMW AG, für Projekt- und Test- Management vorgeschrieben war: Die Kommunikation wird über das BMW-B2B-Portal erstellt, das alle Interaktionen mit externen Mitarbeitern steuert, insbesondere die Freigabe der nötigen "Rollen".

   Im Folgenden werden Tools aus der BMW-Tool-Landschaft (1 bis 4) oder sonstige Tools (5) aufgelistet, die für die Steuerung der Teilprojekte relevant waren.

   1. (ASCENT) JIRA

      JIRA ist ein mächtiges Ticketting-System. Wenn systematisch verwendet, ermöglicht es den komplett Stand (und Verlauf) der Teilprojekte zu dokumentieren. Jedes Ticket artikuliert einen "atomischen" Vorgang - z.B. ein Bug-Report -, dessen "Zustand" zu einem bestimmten Zeitpunkt durch eine Menge von "Parametern" charakterisiert ist. Die Mächtigkeit von JIRA - und anderen ähnlichen Datenbanken - gründet sich über die Vernetzung dieser Parameter, die verschiedenen Betrachtern - einzelnen Entwicklern, Teamverantwortlichen, Managern, dem Auftraggeber (bzw. dem Produkt Owner) - jeweils ein passendes Bild liefert, um die eigenen Fragestellungen zu artikulieren.

      Ein wesentlicher Vorteil des Tools ist, dass es eine Fülle von Funktionen bereithält, die unterschiedliche (vorwiegend agile) Paradigmen des Entwicklungsprozesses unterstützen. Darunter scrum: das sogenannte scrum-board und zugeordnete Möglichkeiten des Filterns und der Berichterstattung war von zentraler Bedeutung in meiner Rolle als "scrum-master".

   2. Jenkins Build Server

      Über die Schnittstelle des "Jenkins Build Server" (URL in BMW Intranet) werden sogenannte "Slaves" gesteuert, die executable Versionen der Software bauen. Je nach User wird die Software unterschiedlich gebaut: Entwickler-Versionen, Tester-Versionen, Kunden-Version. Als Release-Manager war ich dazu befugt, in Absprache mit dem Auftraggeber und entsprechend dem Zeitplan, die offiziellen Release-Versionen zu bauen und veröffentlichen.

   3. Versionierung

      git / Gerrit war vom Auftraggeber für die Versionierung der Software-Quelltexte vorgeschrieben. Als Release-Manager hatte ich Zugriff auf die Quelltexte - außer Modulen, die die Funkkommunikation und ihre Absicherung betrafen (streng vertraulicher Bereich). Die grafische Gerrit-Schnittstelle (von git) erwies sich, als sehr hilfreich, um alle Aktivitäten der Softwareentwickler - in den mir zugänglichen Modulen - schnell und einfach zu prüfen.

      Für die Aufbewahrung von anderen Dokumenten - z.B. teamspezifischen Unterlagen der Softwareentwicklung, des Softwaretests, des Projektmanagements, der Prozessüberwachung - kam auch SVN in Anwendung.

   4. Dokumentation

      Die Erstellung und Verfügbarkeit der erforderlichen Dokumenten bezogen auf Softwareentwicklung, Testentwicklung, Prozesssteuerung ist ein kritischer Teil aller modernen Projekte, und entscheidet über die Beurteilung der Qualität - nicht nur des Produktes, sondern der Prozesse. Das Dokumentieren im DKEY-Projekt beruhte auf mehrere Säulen:

      1. Wiki-Dokumentation:

         Die Wiki-Dokumentation nenne ich ein gemeinsames "Projektbuch", worauf alle Projektbeteiligten (Lese- und Schreib-) Zugriff haben.
         Im Sinne der von agilen Verfahren propagierten Selbstorganisation wurden den Experten große Freiheit gestattet, ihre Kenntnisse so darzulegen, wie sie es für richtig halten. Schließlich dient diese Dokumentation zum Großteil der Einarbeitung von neuen Teammitgliedern. Von den Teamverantwortlichen wurde lediglich darauf geachtet, dass alle wichtigen bzw. kritischen Themen behandelt werden: Organisation des Projektes, Hardware-Beschreibung, Software-Beschreibung, Test-Beschreibung. Die in der Alltagspraxis meist gelesenen Texte waren die "How-to-do-s?" - die in separaten Kapiteln nach Themen zusammengeführt wurden.

      2. Share-Directories:

         Viele Protokolle und Ergebnisse befinden sich, auf Share-Directories im Intranet des Auftraggebers: u.a. das zentrale Dokument Release-Plan, alle Protokolle des scrum-Sitzungen und Workshops, Pflichtenheften für die meisten Softwaremodulen, Testspezifikationen, alle Zusammenfassungen der Testergebnisse (Die "rohen" Ausgabedateien von manchen Tests bleiben wegen der schieren Größe - > 1 GByte - bei den jeweiligen Teams - auf Jahre hinaus - aufbewahrt.)

         Vertrauliche Dokumente, die das Projektmanagement betreffen (Verträge, Projekthanbücher, Nachweisdokumente) bleiben auf Shares-Directories (bzw. Repositories) der Auftraggeber - und werden nur auf Anfrage zur Verfügung gestellt.

      3. Die JIRA DB:

         Fast alle Befunde der Software-Entwicklung befinden sich (erwartungsgemäß) in der JIRA-Datenbank - zu Tickets angehängt (Die Entwickler kommunizieren in erster Linie via JIRA.) Dadurch entsteht für relevante Dokumente eine Redundanz, die bewusst zugelassen bzw. unterstützt wird, um den Zugriff auf die Information für unterschiedliche Betrachter zu erleichtern.

   5. Office Anwendungen

      Trotz der Vielzahl von speziellen Programmen zur Bearbeitung von Aufgaben wie Planung, Steuerung und Management, bleiben klassische Office Pakete verbreitet. Meist lohnt sich die projektbezogene Anschaffung von speziellen Programmen erst, wenn die anvisierte Aufgabe eine gewisse Schwelle der Komplexität erreicht, um den Mehraufwand (finanziell, das Erlernen, etc.) zu rechtfertigen.

      Die Lage ist anders gelegen, wenn ein bestimmtes Programm vom Auftraggeber festgeschrieben wird oder bei ihm querdurch Anwendung findet. Im DKEY-Projekt lag von Seite des Auftraggebers - außer der festgeschriebenen Tool-Kette - keine weitere Bedingung vor. Für das interne Projektcontrolling nutzte die Auftragnehmer-Firma ein eigenes Programm, das eine Schnittstelle zu EXCEL für den Daten -Import und -Export unterstützt.