O'Reilly logo

Automotive SPICE in der Praxis: Interpretationshilfe für Anwender und Assessoren by Jörg Zimmer, Lars Dittmann, Klaus Hörmann, Markus Müller

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

2 Interpretationen zur Prozessdimension
68
elementes. In der Praxis wird der Softwarefeinentwurf oft toolbasiert erstellt, mit
dem späteren Ziel, Sourcecode automatisch zu generieren. Die Modellierung und
Simulation einzelner Funktionen erfolgen dabei am PC. So werden z.B. Zustands-
automaten mit einem grafischen Editor dargestellt und bearbeitet. Erlaubte
Zustandsübergänge werden durch Ereignisse und Bedingungen spezifiziert. Die
erzeugten Modelle können in Hardware-in-the-Loop- oder Rapid-Control-Proto-
typing-Systeme integriert werden, um weitere Arbeiten durchzuführen.
13-22 Traceability record – Traceability-Aufzeichnung
Siehe bei ENG.2
2.7.5 Besonderheiten Level 2
Zum Management der Prozessdurchführung
Die Erstellung des Softwaredesigns muss systematisch erfolgen. In der Praxis
werden die »kleinen« Arbeitsschritte, die sich in vielen Iterationen wiederholen,
normalerweise nicht im Detail geplant. Die »größeren« Arbeitsschritte (z.B.
Designreview sowie Meilensteine, wann verschiedene Versionen des Software-
designs vorliegen sollen) hingegen sind sehr wohl zu planen und in Dokumenten,
wie z.B. dem Projektplan, zu dokumentieren. Sind größere Aktualisierungen des
Softwaredesigns vorhersehbar, z.B. an Meilensteinen, sind diese in der Projekt-
planung zu berücksichtigen.
Zum Management der Arbeitsprodukte
Die Anforderungen von Prozessattribut PA 2.2 gelten insbesondere für die Soft-
waredesigndokumente. Dazu gehört z.B. auch die Durchführung eines Design-
reviews und dass das Softwaredesign ggf. durch den Kunden abgenommen wird.
Baselines enthalten die jeweils gültigen Designdokumente.
2.8 ENG.6 Softwareerstellung
2.8.1 Zweck
Zweck des Prozesses ist es, verifizierte Softwaremodule zu erstellen, die das Soft-
waredesign korrekt widerspiegeln.
Basierend auf dem in ENG.5 erstellten Softwaredesign wird nun die Software
entwickelt. In der Praxis verläuft der Vorgang der Codeerstellung iterativ in meh-
reren aufeinander folgenden Zyklen von Codierung, Fehlersuche und Fehlerbehe-
bung und ist stark verzahnt mit anderen Entwicklungstätigkeiten wie z.B. dem
Softwaredesign oder dem Modultest
41
.
69
2.8 ENG.6 Softwareerstellung
2.8.2 Besonderheiten in der Automobilindustrie
Die Programmierung in der Automobilindustrie berücksichtigt die Anforderun-
gen der verwendeten Hardware in starkem Maße. Insbesondere bei hardwarena-
hen Schichten, wie Betriebssystem oder Gerätetreiber, ist der erzeugte Code oft
nur für einen Microcontroller oder bestenfalls eine Controllerfamilie verwend-
bar. Ähnlich sieht es für die Werkzeuge zur Codeerzeugung aus (z.B. bei Compi-
lern), die nicht universell einsetzbar sind. Gängige Programmiersprachen sind C,
Assembler oder für nicht hardwarenahe Schichten auch C++. Werden Modellie-
rung, Simulation und Designbeschreibung der Software mithilfe von Tools durch-
geführt, geschieht die Codeerzeugung meistens per Knopfdruck im nachfolgen-
den Arbeitsschritt. Dieser automatisch erzeugte Code genügt den Anforderungen
des Projektes aber oft nur teilweise. Oft sind die Ausführungszeiten nicht opti-
mal, und häufig übersteigt der Speicherbedarf des Autocodes die zur Verfügung
stehende Speicherkapazität. Die Kosten für den Speicher sind meist nicht zu ver-
nachlässigen, daher folgen in der Praxis oft weitere Optimierungsarbeiten zur
Speicherbedarfsreduzierung. Die Ausprägungen bezüglich der Codegenerierung
sind in einzelnen Unternehmen völlig unterschiedlich und reichen von komplet-
ten Toolketten, die die gesamte Softwareentwicklung von der Anforderungsdefi-
nition bis zum Softwaretest und unterstützende Aktivitäten (z.B. Konfigurations-
management) beinhalten, bis hin zur völlig heterogenen Struktur mit teilweise
selbst entwickelten Tools und größeren Lücken in der Toolkette.
2.8.3 Basispraktiken
BP1: Entwickle eine Strategie zur Verifikation der Softwaremodule. Entwickle
eine Strategie, um Softwaremodule zu verifizieren und zu re-verifizieren. Diese
Strategie sollte definieren, wie die gewünschte Qualität mit den verfügbaren
Techniken erreicht werden soll.
41. Der Modultest ist nicht zu verwechseln mit der entwicklungsbegleitenden Fehlersuche (engl.
debugging), siehe BP4.
Hinweis für Assessoren
Tools an sich sind im Assessment auf Level 1 und 2 nicht bewertungsrelevant (z.B.,
wie gut diese sind), da Automotive SPICE hierzu keine Forderungen stellt (expli-
zite Forderungen bezüglich adäquater Infrastruktur gibt es jedoch auf Level 3).
Bewertungsrelevant ist jedoch sehr wohl, ob durch Tools bzw. deren Handhabung
Beeinträchtigungen bei Praktiken entstehen. Es kann daher z.B. untersucht wer-
den, ob das Tool zweckmäßig eingesetzt und administriert wird (z.B. Zugriffs-
rechte eines KM-Tools), die Eingangs- und Ausgangsbedingungen der Toolnut-
zung im Projekt, d. h. der Übergang von der »Handarbeit« zur Toolnutzung und
umgekehrt, definiert sind und ob diesbezügliche Vorgaben eingehalten werden.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required