nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Recht / Normen - Automotive SPICE

Automotive SPICE für Einsteiger - Prozesse bewerten und verbessern

Der Artikel schildert die aktuellen Herausforderungen in der Systementwicklung und erklärt, warum das Modell Automotive SPICE eine Möglichkeit bietet, Ihnen zu begegnen. Er beschreibt die Begrifflichkeiten des Modells im Detail und soll ein Grundverständnis des Modells und seiner Anwendung schaffen sowie den Nutzen des Modells in der Entwicklung softwarebasierter Systeme darstellen

In der Automobilindustrie steigen die Komplexität der Projekte und Produkte kontinuierlich. Die Herausforderungen haben sich über die Zeit stark verändert. So gewinnt die Entwicklung softwarebasierter Systeme immer mehr Gewicht.

Dabei sehen wir uns mit steigender und verteilter Funktionalität ebenso konfrontiert wie mit kürzeren Entwicklungszyklen, paralleler Projektabwicklung, Sicherheitsaspekten und steigenden Ansprüche der Kunden. Und am Ende soll immer noch ein qualitativ hochwertiges Produkt entstehen. Es gilt also, Fehler zu vermeiden und effizient zu arbeiten. Damit Projekte diese Aufgaben bewältigen, benötigen sie stabile Abläufe und Erfahrung, die auch zwischen den Projekten geteilt werden kann.

Die Standish Group, ein Forschungs- und Beratungsunternehmen mit Schwerpunkt auf Management von Software-Projekten, hat in ihren Analysen für den „CHAOS Report“ 2015 mehr als 5.000 Projekte untersucht und festgestellt, dass insgesamt nur 29 Prozent der Projekte erfolgreich abgeschlossen werden.

Bild 1: Projektabschlüsse

Das „Ziel verfehlt“ hat in diesem Zusammenhang ein Projekt, das sein Budget oder seinen Zeitrahmen deutlich überschreitet oder kein zufriedenstellendes Ergebnis im Sinne der Kundenwünsche abliefern kann. Häufig scheitern Projekte, weil das Zusammenspiel aller Beteiligten, seien es einzelne Personen oder ganze Bereiche, nicht berücksichtigt wird.

Auch wenn in einem Projekt viele Experten mit viel Erfahrung in ihrem jeweiligen Fachgebiet beteiligt sind, ist der Erfolg nicht ausschließlich von der fachlichen Expertise einzelner abhängig. Es braucht die Abstimmung und insbesondere die Verlässlichkeit, dass alle Phasen des Projektes ineinandergreifen.

Das Zusammenspiel ist wichtig

Bild 2: Schnittstellen in der Systementwicklung

Für die Systementwicklung muss der Entwicklungsprozess klare Schnittstellen haben, an denen die Fachbereiche jeweils verlässliche Lieferungen aus den anderen Fachbereichen erhalten. Dabei ist eine Lieferung nicht nur das Produkt selbst, sondern die Sammlung der Anforderungen auf den unterschiedlichen Ebenen, Lösungen für die Architektur und ähnliches. Ein einfaches Beispiel soll dies verdeutlichen und die möglichen Konsequenzen darstellen.

Ein Automobilzulieferer soll für einen OEM ein mechatronisches System inklusive der notwendigen Software entwickeln. Der Projektleiter hat zusammen mit einigen Fachexperten die Anfrage bearbeitet und festgestellt, dass das Projekt umsetzbar ist. Die Experten haben ihre Vorstellung des Systems in Form von Anforderungen dokumentiert, allerdings ohne explizit alle Disziplinen (Software, Hardware, Mechanik) in diese Analyse einzubinden.
Auf der Systemebene wurde eine grobe Architektur festgelegt, die aber nicht eindeutig mit den Anforderungen verknüpft ist. Die Abhängigkeiten zwischen den Software- und Mechatronikanteilen ist nur grob analysiert. Die Experten aus Software, Hardware und Mechanik arbeiten weitgehend unabhängig voneinander an den Anforderungen und beginnen mit der Entwicklung.

In der Elektronik-Entwicklung stellt sich nun heraus, dass bestimmte Funktionalitäten nicht umsetzbar sind, ohne die Auslegung der Hardware anzupassen. Es werden andere Bauteile als ursprünglich geplant eingesetzt, was zu verändertem Laufzeitverhalten führt. Dies hat auch Auswirkungen auf die Software. Dort sind Änderungen an der Architektur und am Code selbst notwendig, um mit dem veränderten Verhalten der Elektronik korrekt umgehen zu können. Allerdings kann aufgrund der fehlenden bzw. unvollständigen Abstimmung und Verknüpfung sowohl zwischen den Fachbereichen Software und Elektronik als auch nach „oben“ auf die Gesamtsystemebene nicht eindeutig identifiziert werden, welche Elemente in der Software bearbeitet werden müssen. Es entstehen Mehraufwand für die Analyse und das Risiko, dass die Änderungen nicht vollständig oder nicht korrekt umgesetzt werden.

Darüber hinaus lässt sich nicht mehr mit Sicherheit sagen, ob durch die veränderten Software- und Elektronikanteile die Anforderungen an das Gesamtsystem (und damit die Anforderungen des Kunden) erfüllt werden.
Diese Problematik weitet sich auf die gesamten Verifikationsaktivitäten aus. Es ist nicht gesichert, dass alle anzupassenden Elemente in der Software und Elektronik korrekt identifiziert wurden. Aus diesem Grund besteht das Risiko, dass die bestehenden Testfälle der jeweiligen Teststufen (Software-Integration, Software-Test, Systemintegration, Systemtest) keine vollständige Testabdeckung gewährleisten und gegebenenfalls sogar falsch sein können. Auch hier sind Mehraufwände notwendig, um dieses Risiko abzufangen.

Durch die beschriebenen Mehraufwände geraten dann das Budget und der Zeitplan in Schieflage und das auszuliefernde Produkt kann Qualitätsmängel haben.


Inhaltsverzeichnis

Volker Lehmann

Method Park Holding AG
Wetterkreuz 19a
91058 Erlangen
volker.lehmann@methodpark.de
www.methodpark.de

Unternehmensinformation

Method Park Holding AG

Wetterkreuz 19a
DE 91058 Erlangen
Tel.: 09131 97206-0
Fax: 09131 97206-280

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt