SWE.5 Softwareintegration und Integrationstest
Sie beschäftigen sich mit den Anforderungen von Automotive SPICE®, insbesondere an die »Softwareintegration« und deren Tests? Auf dieser kompakten Seite finden Sie relevante Infos zum Schlüsselprozess SWE.5 aus dem VDA-Scope, inklusive einem Video und einem kostenlosen Whitepaper.
zurück zu ASPICE
Wollen Sie noch mehr zum Automotive SPICE-Prozess »Softwareintegration (SWE.5)« 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.
Automotive SPICE ist eine Marke des VDA QMC.
Der Softwareintegrations-Prozess in Automotive SPICE® (auch als SWE.5 bezeichnet) hilft Ihrem Unternehmen sicherzustellen, dass die einzelnen Elemente der Softwarearchitektur integriert und anschließend getestet werden. Damit beweisen sie, dass diese wie geplant zusammenarbeiten und wie in der Softwarearchitektur beschrieben interagieren.
In meinen Kursen und Assessments höre ich oft Fragen wie "Wir führen eine Menge Anforderungstests durch. Lohnt sich der zusätzliche Aufwand für Integrationstests wirklich?".
Was ist Ihre Meinung? Haben Sie schon darüber nachgedacht?
Um diese Frage zu beantworten, müssen wir zunächst klären, was Integrationstests bedeuten.
Bild
Der Prozess SWE.5 im VDA-Scope
Der Zweck von Integrationstests besteht darin, die Übereinstimmung mit der Softwarearchitektur zu überprüfen. Dies beinhaltet die Überprüfung der Schnittstellen, des dynamischen Verhaltens und des Ressourcenverbrauchs gemäß SWE.2, dem Softwarearchitekturentwurfsprozess.
Nun, ändern wir unsere ursprüngliche Frage zu: "Können Anforderungstest die Konformität mit der Softwarearchitektur nachweisen?" Und die Antwort ist: Natürlich nicht, einfach weil diese Tests gegen Anforderungen und nicht gegen die Architektur testen.
So weit, so gut. Aber einige von Ihnen könnten sagen: "OK, verstanden. Aber was bringt es, die Architektur zu testen? Wenn die Funktionalität gut funktioniert, ist das nicht gut genug?"
Schauen wir uns das einmal genauer an: Kann beim Anforderungstest eine Abweichung von der Architektur festgestellt werden? Ja, aber es gibt keine Garantie. Sie können die Anzahl der Anforderungstests mit eintausend, zehntausend, einhunderttausend multiplizieren, aber dafür gibt es noch keine Garantie. Die Kosten würden explodieren, aber die Software hätte immer noch Fehler, die durch einfaches Testen anhand der Architektur hätten vermieden werden können.
Fazit: Durch Durchführung von Integrationstests erhalten Sie robustere Software zu geringeren Kosten im Vergleich zu vollumfassenden Anforderungstests, die versuchen Architekturdesign mit abzudecken.
Im Folgenden sind die wichtigsten Aspekte der Softwareintegration und des Softwareintegrationstests in Automotive SPICE® aufgeführt.
Wie Sie vielleicht aus einigen unserer Videos wissen, ist eine Strategie eine leicht verständliche Übersicht des Vorgehens. Dies ist besonders wichtig für größere, verteilte Projekte, damit alle wissen, wie sie es machen. Diese Strategie beschreibt zunächst den Workflow des Softwareteams, angefangen vom einzelnen Entwickler, der einige einfache Integrationstests durchführen kann, bevor seine Software in den Teamworkstream übernommen wird. Und dann könnte das Team im Rahmen seiner nächtlichen Testläufe einige Integrationstests durchführen. Und wenn sie fertig sind, führen sie einige abschließende Integrationstests durch, bevor sie ihre Arbeit in den Projektworkstream einbringen. Dann könnte es einige zusätzliche Integrationstests geben. Darüber hinaus erfordert Automotive SPICE® eine "Regressionsteststrategie". Regressionstests bedeuten einfach, dass Sie sicherstellen, dass alles, was sich nicht geändert hat, noch gut funktioniert, wenn Sie etwas in der Software ändern.
Ein praktisches Beispiel: Wenn Sie Continuous Integration verwenden, führen Sie in der Regel alle Integrationstests während Ihrer nächtlichen Tests erneut aus.
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
Traceability bedeutet, dass Sie für jedes relevante Architekturelement, z. B. eine Schnittstelle, den entsprechenden Test lokalisieren können. Wenn Sie dies umgekehrt tun können, ist die Traceability bidirektional.
Was bedeutet nun Konsistenz? In unserem vorherigen Beispiel würde Konsistenz erfordern, dass die Schnittstelle mit dem richtigen Test verknüpft ist (und nicht mit dem Test von etwas anderem). Dieser Test eignet sich zum vollständigen Testen der Schnittstelle. Ist dies nicht der Fall, müssen zusätzliche Tests verknüpft werden. Konsistenz setzt auch voraus, dass die Tests die Schnittstelle tatsächlich korrekt testen. Mit anderen Worten, keine fehlerhaften Tests.
Unserer Erfahrung vertrauen bereits über 100 Konzernkunden auf vier Kontinenten.
Automotive SPICE®? Wir sind die Experten!
Bei uns engagieren sich 48 intacts™ zertifizierte Assessoren. Mit an Bord sind auch zehn Trainer für Provisional bzw. Competent Level.
Automotive SPICE®? Wir sind die Experten!
Wir bringen uns bei der Gestaltung des Standards kontinuierlich seit 2005 als Peer Reviewer ein. Bei intacs haben wir Plug-Ins für Mechanical Engineering und Hardware Engineering mitverfasst.
Automotive SPICE®? Wir sind die Experten!
Wir haben den mehrfach aufgelegten Fachbuch-Klassiker »Automotive SPICE in der Praxis« verfasst.
Automotive SPICE®? Wir sind die Experten!
Profitieren Sie von über 200 Personenjahren an geballter Projekterfahrung aus teils mehrjährigen Verbesserungsprogrammen.
Automotive SPICE®? Wir sind die Experten!
Wir haben inzwischen über 1.000 Assessorinnen und Assessoren nach den intacs-Regularien ausgebildet.
Automotive SPICE®? Wir sind die Experten!
Wir haben seit 2007 über 200 Assessments auf Projekt- und Organisationsebene durchgeführt. Dies entspricht 10.000 Assessment-Stunden.
Automotive SPICE®? Wir sind die Experten!
Dies wird normalerweise als Testzusammenfassungsbericht 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.
Sehen wir uns genauer an, wie dieser Bericht aussehen sollte. Wie der Name schon sagt, sollte er die Ergebnisse zusammenfassen und unnötige Details verbergen. Was ist die Hauptbotschaft, die der zusammenfassende Bericht vermitteln sollte? Was denken Sie? Nun, er sollte natürlich die Übereinstimmung mit der Softwarearchitektur darstellen.
Zur systematischen Verbesserung der Entwicklungsprozesse im Bereich der Automobilelektronik sind wir offizieller Lizenznehmer von Automotive SPICE®, einer Marke des VDA QMC.
Ich gebe Ihnen ein Gegenbeispiel, das ich oft in Assessments sehe. Der Bericht enthält Tortendiagramme mit den 539 Tests, die hätten durchgeführt werden sollen, von denen 75 nicht durchgeführt werden konnten und 34 fehlgeschlagen sind. Das ist es dann oft bereits. Es gibt keine Informationen darüber, warum die 75 Tests nicht durchgeführt werden konnten und welche Risiken bestehen. Es gibt auch keine Informationen darüber, wie groß das Problem bei den 34 fehlgeschlagenen Tests ist. Der Bericht zeigt auch keine Übereinstimmung mit der Softwarearchitektur. Die Softwarearchitektur wir in der Tat überhaupt nicht erwähnt. Sie müssten das Tortendiagramm nicht nur mit den 539 Tests, sondern auch mit den 247 Architekturelementen in Beziehung setzen.
Ich gehe davon aus, dass Sie den Punkt verstanden haben. Dies führt natürlich zu Schwächen beim Assessment.
- die Schlüsselprozesse Ihrer Entwicklungseinheit mit Automotive SPICE® auf die erforderliche Reife zu bringen.
- bestehende Arbeitsabläufe und Vorgehensweisen systematisch zu verbessern.
- den Stand Ihrer Prozessverbesserungen per Assessment oder Gap-Analyse zu bewerten.
- die Anforderungen von Automotive SPICE® im Einklang mit Security, Funktionaler Sicherheit und agilen Methoden zu erfüllen.
- Ihre Mitarbeiterinnen und Mitarbeiter intensiv zu schulen und zu Assessoren auszubilden.
