In diesem Kapitel möchte ich, ohne auf die spezifischen Projekte und Unternehmen einzugehen, meine Erfahrungen mit Kollegen und Lesern aus Projekten teilen. Ich finde, dass die „fremde Erfahrung“ für andere Automotive-Projekte viel beitragen kann. Ich hoffe, dass zumindest einige Projektmitwirkenden den einen oder anderen Punkt daraus entnehmen können.
Meine Wahrnehmung ist rein subjektiv. Meine Meinung kann unter Umständen durch unvollständiges Wissen oder eine nicht vollständig verstandene Ursache entstanden sein, insbesondere bei der Interpretation von Gründen für das eine oder andere Problem.
Was ich aber betonen möchte: Diese Probleme wurden auch von anderen Kollegen wahrgenommen und diskutiert. Es gab Punkte, welche erfolgreich gelöst waren; es gab aber auch solche, die in einzelnen Projekten nicht überwunden waren.
| Disziplin: | Beschreibung von Herausforderungen: | Mögliche Lösungsansätze: |
| Projektmanagement | In neu entwickelten Projekten gibt es häufig nicht genügend qualifiziertes und erfahrenes Personal für eine bestimmte Rolle. Dort wird diese Lücke meist mit Personen abgedeckt, die bereits eine bestimmte Rolle im Projekt besitzen. Dadurch wird zwar eine Rolle besetzt, doch kann ein Interessenkonflikt entstehen, sodass das Projekt eher leidet, als dass es profitiert. Die Interessenkonflikte entstehen beispielsweise, wenn z. B. eine Rolle der Entwicklungsleitung und die des Test-Managers durch die gleiche Person ausgeübt werden. | Die Besetzung der führenden Rollen im Projekt sollte gut durchgedacht sein. Damit keine unerwünschten Nebeneffekte im Projekt auftreten, darf es nicht dazukommen, in welcher eine Abteilung die Verantwortung für einen Misserfolg einer anderen Abteilung gibt, um eigene Interessen nicht zu verletzen. Das kann vermieden werden, indem die Rollen so besetzt werden, dass Interessenkonflikte im Projekt, wenn möglich, ausgeschlossen werden. |
| Reviews (disziplinübergreifend) | In einem Team mit mehreren Ingenieuren, die Reviews durchführen, gibt es keine definierten Review-Kriterien (Bewertungskriterien). Es entstehen Missverständnisse und widersprüchliche Review-Ergebnisse. | Die Prozessdokumente für Reviews müssen ausreichend detailliert sein, damit Review-Teilnehmende die einheitlichen Review-Kriterien verfügen. |
| Projektdokumentation (disziplinübergreifend) | In vielen Projekten wird ein Produkt entwickelt. Die Dokumentation wird jedoch vernachlässigt. So kann es in einem Functional Safety relevanten Projekt zur Situation kommen, in der die Systemarchitektur (oder andere wichtige Projektdokumente) weitgehend fehlt. Es wird versucht, anhand von bestehenden Hardware-Dokumenten die Systemarchitektur abzuleiten, um die Softwarearchitekturdokumentation zu vervollständigen. | Im Projekt muss klar definiert werden, wer für welche Projektdokumente und zu welchem Zeitpunkt verantwortlich ist. Der Prozess der Erstellung der Dokumentation und deren Freigabe muss vom Projektmanagement überwacht werden. |
| Prozessdokumentation- Guidelines (disziplinübergreifend) | In einem Team mit vielen „neuen“ Team-Mitgliedern ist es besonders wichtig, die Prozessdokumente in den einzelnen Disziplinen entsprechend ihrem Entwicklungsstand zu vervollständigen. Der ASPICE-Standard definiert viele Anforderungen. Daneben existieren jedoch unternehmensspezifische, durch Tailoring angepasste Prozesse, deren Umsetzungen variieren. Beispielsweise sind Schnittstellen zwischen Disziplinen – etwa Verantwortlichkeiten für Software, Softwareintegration und Integrationsverifikation – oft nicht klar definiert. Es besteht die Gefahr, dass Tests erst sehr spät oder gar nicht durchgeführt werden. | Es ist nicht unzureichend, sich allein auf ASPICE zu berufen und die fehlende Prozessdokumentation durch ASPICE Vorgaben kompensieren zu wollen. Die ASPICE‑Vorgaben beantworten, was getan werden muss, nicht jedoch wie. Die Prozessdokumente sollten so gestaltet sein, dass jedes Teammitglied prozessuale Fragen eindeutig beantworten kann: – wer für was zuständig ist, – wann muss ein bestimmtes Ergebnis geliefert werden. Es eignen sich dafür Methoden-Dokumente, wo diese Fragen speziell eingegangen sind und die Prozesse in Details (anhand z. B. eines Diagramms) erklärt werden. |
| Anforderungen (Requirements Engineering) | Die ASPICE-Vorgaben werden häufig unreflektiert im Projekt umgesetzt. Ein Beispiel dafür ist die Tabelle für Traceability: „Figure C.2 — Consistency and traceability between system and software work product“. Man versucht, Lücken in den Anforderungen auf allen V‑Modell‑Ebenen zu schließen, indem fehlende Vorgaben eigenständig erstellt werden. Wenn ein Kunde nur die Ebene des Software Detailed Design liefert, versucht man, alle V‑Modell‑Ebenen bis hin zu den Systemanforderungen zu erschließen. Dadurch wird das Projekt unnötig komplex, und die erdachten Anforderungen lassen sich nicht immer testen, insbesondere wenn keine System‑ oder Softwareschnittstellen betroffen sind. | Anstatt das Traceability‑Modell unreflektiert zu übernehmen, sollten solche Ausnahmen im Dokument Tailoring‑Guidelines festgehalten werden. So werden hohe Aufwände im Anforderungsmanagement und bei den Testaktivitäten auf allen Ebenen – System (SYS) und Software (SW) – vermieden. |
| Anforderungen (Anforderungstool, Ebenen und Traceability) | In vielen Projekten werden die Anforderungen nicht eindeutig zu den einzelnen Ebenen zugeordnet. In solchen Fällen werden in einer Anforderung mehrere Ebenen abgebildet, z. B. wenn Systemanforderungen und Anforderungen an die Softwareimplementierung gemeinsam formuliert werden. Solche Anforderungen sind meist nicht auf einer klar definierten Ebene testbar. Noch wichtiger ist es, dass diese Anforderungen die Vorgaben der Normen ISO 26262-8, Kapitel: 4, 6 und ISO 29148, Kapitel 7 verletzen. | Die Dokumenten‑Reviews müssen rechtzeitig durchgeführt und aufgetretene Mängel behoben werden. Weitere Maßnahmen kann man ergreifen, indem die Guidelines für die Anforderungserstellung zusammengefasst werden. Die komplexen Spezifikationen müssen weiter in separate und atomare Anforderungen zerlegt werden. |
| Allgemein | Viele Unternehmen automatisieren manuelle Routinen nicht. Öfter wird viel Zeit mit manuellen Aktionen verschwendet, etwa dem Vergleichen von Änderungen, wiederkehrenden Konfigurationsschritten oder der Dokumentationserstellung und den ähnlichen Tätigkeiten. | Für bestimmte Tätigkeiten, z. B. den Vergleich von Anforderungen zwischen Auslieferungen, ist es vorteilhaft, eine Automatisierung einzuführen. |
| Konfigurations-management | Manchmal arbeiten einzelne Abteilungen in eigenen Datenstrukturen. Die anderen Abteilungen haben keinen Zugriff auf die nötigen Informationen (z. B. Es ist hilfreich für die Tester und Entwickler auf die Hardware-Spezifikationen zuzugreifen, um die Software-Ebene zu spezifizieren, zu implementieren und zu testen). Dadurch entstehen Projekthürden, die sich leicht vermeiden lassen. Es gibt Situationen in einzelnen Projekten, in denen Projektteilnehmer unterschiedliche Zugriffsrechte auf Standards und Normen haben. Es gab einen Fall, in dem die Norm ISO 26262 für Entwickler nicht zugänglich war und die beantragten Zugangsrechte über längere Zeit nicht genehmigt waren. | Die Prozessdokumente und deren Bekanntgabe sollen gewährleisten, dass allen Projektteilnehmern die nötigen Informationen zur Verfügung stehen. Die Rolle eines Konfigurationsmanagers kann im Projekt die Aktivitäten übernehmen. |
| Kundenanforderungen | Die Unklarheiten bei den Kundenanforderungen bestehen in vielen Projekten über längere Zeit und manchmal bis zur SOP. Sogar die rudimentären Funktionen, wie das Einschlaf- und Aufweckverhalten können vom Kunden unklar oder unvollständig spezifiziert sein. | Die Schlüsselfunktionen sollten möglichst schnell mit dem Kunden geklärt werden. Die Klärungswege und mögliche Lösungsansätze für die Situationen, in denen die Klärung der Anforderungen notwendig ist, müssen während der Projektstartphase definiert werden. |
| Review der Anforderungen | Es gibt häufig ein prinzipielles Problem in Projekten, in denen zum ersten Mal ein Serienprodukt entwickelt wird. Öfter ist man doch lieber vorsichtiger und versucht, die Reviews mit einer zu großen Mannschaft (manchmal bis zu zehn Personen) durchzuführen, ohne die Vorgaben und Abnahmekriterien genau zu definieren. So dauern Reviews für 300 Anforderungen mehrere Monate und verbrauchen viele Projektressourcen. Hier fehlt die Dokumentation der Prozesse im Unternehmen. | Fehlende Prozessdokumentation muss möglichst schnell ergänzt werden und allen Teambeteiligten zur Verfügung stehen. |
| Projektmanagement | In vielen Agile-Projekten gibt es zwar eine Einführung in die Agile-Vorgehensweise, aber die Prozessdokumentation wurde jedoch nicht entsprechend angepasst. Es gibt viele Unstimmigkeiten bezüglich der Vorgehensweise während der Entwicklung und es gibt kein klares Verständnis, wie das Agile-Projektmanagement zusammen mit solchen Normen wie ASPICE und ISO 26262 in ein Projekt integriert werden kann. In so einem Fall werden die Arbeitsprodukte aus ASPICE und ISO 26262 Anforderungen aus dem Fokus verloren. | Es muss von Beginn des Projekts eine Prozessdokumentation für die Integration des agilen Projektmanagements klar definiert werden. |
| Software | Leider hört man häufig, dass im Code keine Verlinkung zu den Anforderungen stattfinden soll. Als Argumentation hört man, dass die Anforderungskennzeichnungen schlecht zu warten sind. In einem anderen Projekt, in dem der Code wiederverwendet werden soll, bleiben die Artefakte des alten Projekts erhalten. Man muss zustimmen, dass ein gewisser Aufwand dahintersteckt, aber man wendet aus Erfahrung jedoch deutlich mehr Aufwand auf, um die Codeabschnitte zu finden, die einer Anforderung zugeordnet sind. Die Suche erfolgt jedes Mal, wenn ein Entwickler daran arbeitet, ein Tester einen Test durchführt, ein Software‑Architekt den Code prüft und – am wichtigsten – wenn Anforderungsabdeckungsmetriken für das Projektmanagement erstellt werden müssen. Die Berücksichtigung des Aufwands wird gerne vernachlässigt. | Erstens: bidirektionale, granulare Rückverfolgbarkeit zu Anforderungen; zweitens: rasante, automatische Auswertung durch Tools. |
| Testen | Die Standards schreiben vor, die Tests auf allen Ebenen durchzuführen. Es bedeutet für die Projekte, dass man die gezielten Tests auf unterschiedlichen Ebenen durchführt: Software-Unit-Test, Software-Integrationstest, Software-Qualifikationstests, System-Integrationstests, System-Test, System-Qualifikationstest. Es wird blind mit dem Erstellen der Testanforderungen gestartet und man stellt nach einem Jahr fest, dass aus vielen Tests keinen Mehrwert entstanden ist. Im Gegenteil sind nicht mal 10% der Anforderungen mit Tests abgedeckt und häufig wird gleiches auf unterschiedlichen Ebenen getestet. | Es soll in Integrationstests nur das getestet werden, was nicht von Unit-Tests abgedeckt ist. Es sollen gezielt die risikobehafteten Anforderungen getestet werden. Die Automatisierung von Tests z. B. durch Debugger kann Redundanz in Tests verringern. Die Schichtentests sollen zum Testen der komplexen Komponenten verwendet werden. |
| Anforderungen (Requirements Engineering) und Qualität | Besonders in Unternehmen ohne ausgebaute Prozessinfrastruktur entstehen folgende Misserfolge: – System-, Software- und Hardware-Teams wissen nicht, welche Inhalte die Dokumentation auf SYS-, HW- und SW-Ebenen haben soll (z. B. man beschreibt auf System-Ebene ein System ohne konkrete Anforderungen, sondern schreibt einfach als Beispiel: „Das System soll per Tastendruck das Fahrzeugfenster ansteuern“. Man versucht dann, solche Anforderungen „freizugeben“, weil auch die Qualitätsabteilung nicht rechtzeitig den Fehler (Informationslücke in den Anforderungen) erkennt. Nach einem Jahr stellt man fest, dass solche Anforderungen „nicht testbar“ sind und schreibt sie neu, und zwar auf mehreren Ebenen – das ist eine Ressourcenverschwendung und Projektkostenexplosion. – Es wird regelmäßig irrtümlicherweise behauptet, dass das System solche „unkonkrete“ Anforderungen enthalten kann und die Systemarchitektur diese Anforderungen präzisieren muss. Diese Interpretation ist im Grunde falsch. (Das System (SYS.2) hat eine andere Abstraktionsebene als Systemarchitektur (SYS.3) und beschreibt unterschiedliche Objekte – siehe dazu: Anforderungsmanagement-Methode nach dem “Strict Decomposition (SDEC)”-Prinzip.) | Man soll versuchen, im Projekt auf ein qualifiziertes Personal zurückzugreifen (Es gibt jedoch keine Garantie, dass ein erfahrenes Personal mit einer mangelhaften oder fehlenden Prozessbeschreibung erfolgreich ein Projekt zum SOP bringt.) Die Prozesse müssen nicht nur definiert werden; sie müssen auch getestet und kontinuierlich verbessert werden. Wenn zum Projektbeginn nicht alle Prozesse klar definiert sind, sollen als Erstes die Prozesse definiert werden, die am häufigsten verwendet werden. Alle Rückmeldungen zu Prozessänderungen und Prozessergänzungen aus Teams sollen zentral gesammelt, überarbeitet und in die Prozessdokumentation übernommen werden |
| Prozesse (disziplinübergreifend) | Wenn die Prozesse schwach definiert sind, kann es in Meilensteinen zu Schwierigkeiten kommen, bestimmte Arbeitsprodukte durch Review zu bringen. Es fehlt die Übereinstimmung zum Verständnis der Arbeitsproduktreife bei Projektstakeholdern. Wenn viele Stakeholder aus Unternehmen mit unterschiedlicher Unternehmenskultur stammen, gibt es unterschiedliche Realisierungsvorstellungen in Bezug auf einzelne Arbeitsprodukte und unterschiedliche Meinungen zu unternehmensspezifischen Prozessen. Dadurch, dass die Prozesse im Unternehmen lückenhaft sind, gibt es Widersprüche in den einzelnen Realisierungen. | Wenn die Prozesse lückenhaft sind, soll es möglichst schnell eine Basis der Prozesse erstellt werden, die im Projekt am meisten verwendet werden. Die Lücken sollen iterativ geschlossen werden. Es muss eine Rolle dafür definiert und zugeordnet werden. |
| Anforderungen (Requirements Engineering) und Qualität | Thema: Teamqualifikation und nötige Skills Hier ist ein typisches Beispiel, das als Indikator für die Skills von Stakeholdern im Team dienen kann. Im Standard ISO 26262-8, Abschnitt 6.4.2.4 gibt es Vorgaben für Anforderungen, und zwar im Punkt: “h) implementation free; NOTE 12 The requirement, while addressing what is necessary and sufficient for the item, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation independent. The requirement states what is required, not how the requirement should be met.” Dieser Punkt wird oft missinterpretiert. Der Begriff “implementation free” wird oft als Definition der Anforderung ohne Implementierungsvorgaben verstanden. Das ist eine falsche Interpretation. In diesem Fall verliert sich überhaupt der Sinn, eine Anforderung zu definieren. So entstehen solche Anforderungen auf System- oder Software-Ebene wie: “Das System soll die Fehler vermeiden”, “Wenn das System einen Fehler erkennt, dann muss das System reagieren”. Der Punkt h) sagt nur aus, dass zu einer bestimmten Ebene nur bestimmte Anforderungsabstraktion gehört. Dazu kann man mehr im SDEC-Artikel lesen. | Meistens sind solche falschen Annahmen vom Management unterstützt und es ist schwierig, die Kollegen zu überzeugen, meistens dauern Wochen bis Monate bis zum Zeitpunkt, an dem die Mehrzahl des Teams die Fehler verstanden hat. Das Kernteam soll Erfahrung haben. Das Management soll eine gute Verbindung zu solchen erfahrenen Kollegen haben. |
| Anforderungen und Dokumentation | Während der Projektstartphase wird die technische Dokumentation wie Datasheets, Manuals und andere Dokumente intensiv studiert. Dabei suchen die Entwickler wiederholt dieselben Informationen. Es wäre eine Verschwendung, dieselbe Information wiederholt suchen zu müssen. | Die Dokumentationslandschaft sollte vorhanden und gut durchgedacht sein. Jeder Stakeholder sollte den Zugriff auf alle Dokumente haben. Es sollten Richtlinien erstellt werden, wie diese Dokumentation effizient vervollständigt wird, damit doppelter Aufwand vermieden werden kann. |