Einführung
Mit dem Softwarefeinentwurf-Prozess in Automotive SPICE® (auch bekannt als SWE.3) kann Ihr Unternehmen einen evaluierten Feinentwurf für Softwarekomponenten erstellen und die Softwareeinheiten spezifizieren und produzieren.
Zwei Aspekte sollten dabei berücksichtigt werden:
Detaillierungsgrad
Oft sind Unternehmen unsicher, wie spezifisch der Feinentwurf sein soll. Dabei muss man sich eigentlich nur den Zweck des Feinentwurfs vergegenwärtigen. Er ist die eigentliche Grundlage für die Implementierung des Codes und den Unittest. Insbesondere die Unitverifizierung erfordert eine detaillierte Beschreibung. Hier muss der Abdeckungsgrad berücksichtigt werden.
Für sicherheitskritische Software bietet die ISO 26262 eine Orientierung. In nicht-sicherheitskritischer Software wird typischerweise mindestens C0- oder Anweisungsabdeckung gefordert, einige Kunden fordern auch C1- oder Zweigabdeckung. Je höher das Abdeckungsziel ist, desto mehr Details sind für den Feinentwurf erforderlich. Für ein ASIL-B-klassifiziertes Modul wird eine C1-Abdeckung erwartet. Das bedeutet, dass Ihr Feinentwurf die verschiedenen Branches Ihrer Software identifizieren sollte.
Schnittstellen
Eine häufig anzutreffende Falle bei Assessments ist das Fehlen einer detaillierten Beschreibung der externen und internen Schnittstellen.
Die erwarteten Inhalte einer Schnittstellendokumentation sind:
- Namen
- Art/Typen
- Einheiten
- Auflösungen
- Bereiche
- Standardwerte
Ohne diese Informationen ist ein ordnungsgemäßes Testen der Schnittstellen im Unittest nicht möglich.
Es ist in Ordnung, wenn die externen Schnittstellen auf Architekturebene beschrieben und im Software-Integrationstest getestet werden.
Wann sollte der Feinentwurf dokumentiert werden?
Beschreiben Sie den Feinentwurf, bevor Sie den Code implementieren.
Häufig wird zuerst der Code geschrieben und dann der Feinentwurf beschrieben. Warum ist das ein Problem? Mit dem Unittest sollte geprüft werden, ob der Code dem Feinentwurf entspricht.
Wenn Sie den Feinentwurf erst nach dem Dokumentieren des Codes erstellen, ist der Unittest sinnlos. Nun könnte man argumentieren, dass man den Unittest gar nicht braucht. Allerdings ist zu bedenken, dass der Feinentwurf aus der Architektur und nicht aus dem Code abgeleitet werden sollte. Wenn die Kette unterbrochen wird, sind die Dokumentationsinhalte und die Tests nutzlos.
Folglich muss erst der Feinentwurf stehen, bevor Sie den Code schreiben können. Es spricht nichts dagegen, den Feinentwurf und den Code schrittweise zu entwickeln.
Welchen Nutzen bietet der Softwarefeinentwurf?
Der Softwarefeinentwurf ist das Bindeglied zwischen den Softwareanforderungen, der Softwarearchitektur und der Implementierung. Der Prozess erfolgt in iterativen Schritten:
- Die Softwarearchitektur beschreibt, wie die Software in Komponenten organisiert ist und wie diese zusammenwirken.
- Der Softwarefeinentwurf beschreibt jede Komponente und die Struktur und das Verhalten der Softwareeinheiten im Detail.
- Die Softwareeinheiten werden gemäß den Spezifikationen des Feinentwurfs erstellt.
Der Feinentwurf liefert dem Softwareentwickler eine vollständige Spezifikation für die Konstruktion der benötigten Softwareeinheit.So werden nur qualitativ hochwertige und nachvollziehbar getestete Softwareeinheiten entwickelt.
Was beinhaltet der Softwarefeinentwurf?
- Der Feinentwurf für jede Softwarekomponente wird auf Basis der Softwarearchitektur erstellt und dokumentiert. Er beschreibt die erforderliche Logik und die Algorithmen, die internen und externen Schnittstellen, das dynamische Verhalten und die Fehlerbedingungen (BP1, BP2, BP3).
- Es wird bewertet und verifiziert, ob der Feinentwurf die Softwarearchitektur unterstützt (BP4).
Die Traceability zwischen den Softwareanforderungen und den Softwareeinheiten, der Softwarearchitektur und dem Softwarefeinentwurf sowie dem Feinentwurf und den Softwareeinheiten wird nachgewiesen und auf Konsistenz geprüft (BP5, BP6).
Methoden der Unitverifizierung
- Der Feinentwurf und alle Änderungen des Feinentwurfs werden vereinbart und an die Beteiligten kommuniziert (BP7).
- Der Quellcode einer Softwareeinheit wird gemäß den Spezifikationen des Feinentwurfs erstellt. Bei der modellbasierten Entwicklung wird er aus dem Modell generiert (BP8).
Erfahrungen, Probleme und Tipps
- Festlegung der Struktur der Softwarearchitektur und des Feinentwurfs: Die Architektur besteht aus Elementen, die in untergeordnete Elemente unterteilt werden können. Die Elemente der untersten Ebene werden als „Komponenten“ bezeichnet. Der Feinentwurf geht von den Komponenten aus und zerlegt sie in atomare Einheiten.
- Die Einheiten müssen klar definiert und einheitlich verwendet werden. Handelt es sich bei einer Einheit zum Beispiel um eine C-Datei, um eine Methode oder eine Funktion oder um ein atomares Element in einem Modell? Legen Sie sich fest.
- Eine Feinentwurfspezifikation für Softwarekomponenten enthält in der Regel die verwendeten Algorithmen, definierte Interaktionen und Schnittstellenspezifikationen mit Ein- und Ausgabevariablen sowie eine Beschreibung der Programmstruktur. Zur Beschreibung von Teilen des Feinentwurfs werden häufig Fluss- oder Zustandsdiagramme, Nachrichten-Sequenzdiagramme, UML-Diagramme und Beschreibungen in natürlicher Sprache verwendet.
- Kommentare zum Quellcode sind ein wesentlicher Bestandteil der Einheit.
- Die Entwicklung muss unter Berücksichtigung der Kodierungsrichtlinien und -standards erfolgen. Die Compliance wird durch statische Codeanalysen und Codereviews bestätigt.
- Der Feinentwurf wurde in der Vergangenheit oft zu stark vereinfacht oder ganz vernachlässigt. Stattdessen wurde versucht, den Entwurf mittels Auszeichnungssprachen im Quellcode zu dokumentieren. Dadurch wird der Entwurf vor der Implementierung unter Umständen nicht ausreichend berücksichtigt und überprüft.
- Häufig wird die Traceability zwischen Feinentwurf und Softwareeinheiten durch Namenskonventionen hergestellt.
- Redundanz in der Traceability ist nicht erforderlich. Bei Verknüpfungen zwischen den Anforderungen, der Architektur, dem Feinentwurf und den einzelnen Einheiten muss jedoch darauf geachtet werden, dass dazwischen keine Informationen verloren gehen.
Vertiefen Sie Ihr Wissen über Automotive SPICE®
Nehmen Sie an einer unserer Automotive SPICE® Schulungen teil!
Über den Autor
Bhaskar Vanamali ist seit fast 20 Jahren im Bereich Prozessverbesserung tätig und ehemaliger Sekretär des Arbeitskreises 13 des VDA QMC.
Er ist Principal Assessor und Trainer für Automotive SPICE® und hat bereits über 140 Assessments durchgeführt und mehr als 250 Assessoren ausgebildet.
Um Zugang zu weiteren spannenden Inhalten dieser Website zu erhalten, füllen Sie bitte das nachstehende Formular aus:
Bitte warten…