Sie beschäftigen sich mit der Verifikation Ihrer Softwareeinheiten? Wenn Sie noch nicht genau wissen, mit welchen Verifikationsarten Sie prüfen und nachweisen können, dass Ihre Softwareeinheiten den Entwurfsanforderungen entsprechen, finden Sie hier relevante Infos zum Schlüsselprozess SWE.4 aus dem VDA-Scope, inklusive Video und kostenlosem Whitepaper.
zurück zu ASPICEAutomotive SPICE ist eine Marke des VDA QMC.
Der Verifikationsprozesse auf Ebene der Softwareeinheiten in Automotive SPICE® (im Original als Software Unit Verification oder kurz: SWE.4 bekannt) hilft Ihrer Organisation nachzuweisen, dass die umgesetzten Softwareeinheiten nicht nur funktionieren, sondern auch die Anforderungen erfüllen. Diese wurden zuvor im Feinentwurf (SWE.3) spezifiziert.
Der Software-Unit-Verifikationsprozess in Automotive SPICE® (auch als SWE.4 bezeichnet) hilft Ihrem Unternehmen zu verifizieren, ob die Softwareeinheiten den Feinentwurf (Detailed Design) und die damit verbundenen funktionalen und nichtfunktionalen Anforderungen mit der geforderten Qualität umsetzen. Letztlich dient dieser Prozess Ihrer Absicherung als Lieferant.
Wollen Sie noch mehr zum Automotive SPICE-Prozess »Verifikation der Softwareeinheiten (SWE.4)« aus dem VDA-Scope erfahren? In unserem kostenlosen Whitepaper finden Sie alle Informationen zusammengefasst und eine Leseprobe aus dem Buch »Automotive SPICE® Essentials«, dem Buch für Einsteiger in das Thema Prozessverbesserungen.
Die Verifikation der Software-Units ist die erste Stufe von Tests in einer Abfolge von aufeinander aufbauenden Teststufen.
Der Grund dafür ist, dass ein falsches Verhalten auf Software-Unit-Ebene Probleme auf einer höheren Testebene maskieren kann.
Wie Sie sehen, hilft Ihnen dieser Prozess, mehr Probleme zu finden und gleichzeitig Ihren Aufwand und Ihre Kosten zu senken.
Zur Software-Unit-Verifikation in Automotive SPICE® gibt es drei wesentliche Aktivitäten.
Wie Sie wahrscheinlich aus einigen unserer Videos wissen, verstehen wir unter einer Strategie eine leicht verständliche Beschreibung des Vorgehens. Dies ist besonders wichtig für größere, verteilte Projekte, damit alle wissen, wie es geht.
Der Hauptzweck der Strategie besteht darin, zu beschreiben, wie Sie nachweisen möchten, dass die Software-Units dem Feinentwurf (Detailed Design) entsprechen.
Es sind drei Arten der Verifikation erforderlich. Lassen Sie mich kurz erläutern, wie sie funktionieren:
Darüber hinaus erfordert Automotive SPICE® eine Regressionsteststrategie. Regressionstests bedeuten, dass Sie, wenn Sie etwas an einer Unit ändern, sicherstellen, dass alles, was sich nicht geändert hat, noch gut funktioniert.
Ein praktisches Beispiel: Wenn Sie Continuous Integration verwenden, führen Sie in der Regel alle Unittests während Ihrer nächtlichen Tests erneut durch.
Benötigen Sie Unterstützung für Ihr Projekt? Wir sind Ihre Ansprechpartner rund um Managementberatung und Verbesserungsprogramme in der Elektronikentwicklung.
Steffen Herrmann und das Sales-Team
Hier sind drei Arten von Nachverfolgbarkeit (Traceability) erforderlich
Was bedeutet nun Konsistenz? Zum Beispiel für die Beziehung zwischen einer Software-Unit im Detailed Design und der entsprechenden Testspezifikation, Konsistenz würde erfordern, dass
Ist dies nicht der Fall, müssen zusätzliche Tests verknüpft werden. Konsistenz setzt auch voraus, dass die Tests die Software-Unit tatsächlich korrekt testen. Mit anderen Worten, keine fehlerhaften Tests.
Dies wird normalerweise als Testergebnisbericht bezeichnet. Dieser zusammenfassende Bericht sollte an die Personen gesendet werden, die diese Informationen benötigen, z. B. das Entwicklungsteam, der Projektmanager, die Qualitätsingenieure usw.
Schauen wir uns einmal genauer an, wie dieser Bericht aussehen sollte: Wie der Name schon sagt, sollte er die Ergebnisse zusammenfassen und unnötige Details verbergen. Was ist also die Hauptbotschaft, die der zusammenfassende Bericht vermitteln sollte? Es muss die Übereinstimmung mit dem Detailed Design belegen.
Ich gebe Ihnen ein Gegenbeispiel, das ich leider zu oft in Assessments erlebe: Der Bericht enthält Tortendiagramme mit den 1520 Tests, die hätte durchgeführt werden sollen, von denen jedoch 112 nicht durchgeführt werden konnten und 89 Tests fehlgeschlagen sind. Das ist alles. Es gibt also keine Infos darüber, warum die 112 Tests nicht durchgeführt werden konnten und welche Risiken bestehen. Es gibt auch keine Infos bezüglich der Größe des Problems mit den 89 fehlgeschlagenen Tests. Der Bericht zeigt auch nicht die Übereinstimmung mit dem Feinentwurf. Tatsächlich wird der Feinentwurf überhaupt nicht erwähnt, obwohl er die Basis für die Tests sein sollte. Folglich müssten die Projektverantwortlichen das Tortendiagramm auf die 956 Software-Units beziehen, nicht nur zu den 1520 Tests.
Ich denke, Sie haben den Punkt verstanden. Beim Assessment führt dies natürlich zu Konsequenzen.
Zur systematischen Verbesserung der Entwicklungsprozesse im Bereich der Automobilelektronik sind wir offizieller Lizenznehmer von Automotive SPICE®, einer Marke des VDA QMC.