Softwareentwicklung in der Automobilindustrie


Hausarbeit, 2020

17 Seiten, Note: 1,3


Leseprobe


Inhaltsverzeichnis

1. Einleitung
1.1. Relevanz des Themas
1.2. Ziel der Arbeit
1.3. Aufbau der Arbeit

2. Automotive SPICE (ASPICE)
2.1. Historie und Herkunft
2.2. Reifegradmodell
2.3. Prozessreferenzmodell

3. ASPICE System- und Softwareprozesse
3.1. SYS.1 Anforderungserhebung
3.2. SYS.2 Systemanforderungsanalyse
3.3. SYS.3 Systemarchitekturdesign
3.4. SWE.1 Softwareanforderungsanalyse
3.5. SWE.2 Softwarearchitekturdesign
3.6. SWE.3 Softwarefeinentwurf und Modulerstellung
3.7. SWE.4 Softwaremodulverifikation
3.8. SWE.5 Softwareintegration und Integrationstest
3.9. SWE.6 Softwaretest
3.10. SYS.4 Systemintegration und Integrationstest
3.11. SYS.5 Systemtest
3.12. SUP.10 Änderungsmanagement
3.13. MAN.3 Projektmanagement

4. V-Modell, Projektmanagement und Arbeitsweisen

5. Schluss
5.1. Zusammenfassung
5.2. Kritische Reflexion der eigenen Vorgehensweise

6. Literaturverzeichnis

7. Abbildungsverzeichnis

1. Einleitung

1.1. Relevanz des Themas

Mit über 97 Millionen produzierten Fahrzeugen (PKW, Nutzfahrzeuge und Busse)1 im Jahr und, je nach Ausstattung, über 10.000 Teilen pro Fahrzeug2 ist das Automobil das komplexeste massenproduzierte Produkt der Welt.3 Parallel zur hohen Komplexität des Automobils erwartet der Kunde eine hohe Zuverlässigkeit über viele Jahre bei jeglichen Witterungsverhältnissen und einen kontinuierlichen Anstieg an Funktionalitäten. Dabei wächst die Funktionalität im Auto zunehmend über die Software. Lag der Softwareanteil an der Wertschöpfung im Fahrzeug im Jahr 2000 bei ungefähr 2%4, steigert sich dieser Wert aktuell kontinuierlich auf über 60% in naher Zukunft5. Softwareentwicklung spielt somit auch in der Automobilbranche eine dominante Rolle und dass unter besonderen Rahmenbedingungen wie beispielsweise funktionaler Sicherheit. Um die notwendige Softwarequalität (auch in der Zuliefererkette) sicherzustellen, hat ein firmenübergreifender Arbeitskreis ein für den Automotive-Bereich optimiertes Prozess- und Reifegradmodell, namens „Automotive SPICE“ entwickelt, welches heute die Grundlage für Softwareentwicklung in der Branche bietet.

1.2. Ziel der Arbeit

Das Ziel dieser Arbeit ist es die wichtigsten Softwareentwicklungsprozesse nach Automotive SPICE (ASPICE) vorzustellen, Vergleiche zum klassischen Entwicklungsprojekt zu ziehen, die Historie und Herkunft von ASPICE zusammenzufassen und das Zusammenwirken verschiedener Methodenmodelle in der Praxis zu betrachten.

1.3. Aufbau der Arbeit

Beginnend mit der Historie und grundlegenden Informationen über Automotive SPICE, wird das Assignment anschließend die wichtigsten ASPICE Prozessgruppen der Softwareentwicklung behandeln. Danach wird das Zusammenspiel von Prozess- und Arbeitsmodellen beleuchtet und mit einer kritischen Reflexion sowie einer Zusammenfassung das Assignment beendet.

2. Automotive SPICE (ASPICE)

2.1. Historie und Herkunft

Die „Automotive Special Interest Group“, bestehend aus Fahrzeugherstellern und Interessensgemeinschaften, begann 2001 Automotive SPICE auf Basis des SPICE (Software Process Improvement and Capability Determination) Standards der ISO/IEC 15504 zu entwickeln. 2005 wurde ASPICE erstmals veröffentlicht und seitdem kontinuierlich weiterentwickelt.6 Die zwischen-zeitliche Ablösung der ISO/IEC 15504 durch die ISO/IEC 330xx Serie wurde in die ASPICE Spezifikation übernommen. Die aktuellste Veröffentlichung ist die Version 3.1 aus dem Jahr 2017.7 ASPICE beinhaltet zwei Dimensionen, einerseits ein Reifegradmodell, welches es ermöglicht den Zustand einer Organisation in den einzelnen Prozessschritten zu messen und zum anderen die Prozessdimension in der die Vorgänge der einzelnen Prozesse beschrieben sind.8

2.2. Reifegradmodell

Der Reifegrad eines Prozesses wird in ASPICE in sechs aufeinander auf-bauenden Levels gemessen.9 Die Prozessreifemessungen finden im Rahmen von Assessments statt, die von unabhängigen Auditoren durchgeführt werden. Teilweise müssen Zulieferer eine Mindestprozessreife nachweisen, um Projekte der Fahrzeughersteller erhalten zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Levels des ASPICE Reifegradmodells10

Level 0 bedeutet, dass entweder der Prozess nicht implementiert ist oder, dass der Prozess seinen Zweck nicht erfüllt.

Auf dem Level 1 erfüllt der implementierte Prozess seinen Zweck. Es bedeutet, dass grundlegende Praktiken des Prozesses eingeführt sind und definierte Prozessergebnisse abgeliefert werden.

Bei Level 2 wird zusätzlich die Prozessausführung geplant und nachverfolgt. Die Arbeitsprodukte werden systematisch abgelegt und qualitätsgesichert.

In Level 3 besitzt die Organisation einen Standardprozess, der für die einzelnen Projekte in Versionen des Standardprozesses angepasst wird.

Level 4 erfordert, dass für die Prozessdurchführung Kennzahlen definiert sind und gemessen werden. Korrekturmaßnahmen werden auf Grund von Erkenntnissen aus den Messungen vorgenommen.

Das Level 5 erwartet, dass eine kontinuierliche Verbesserung der Prozesse angewendet und die Steigerung der Effektivität nachgewiesen wird.11

2.3. Prozessreferenzmodell

Die primären Entwicklungsprozesse basieren auf dem V-Modell, was sich in Abbildung 3 gut erkennen lässt. In Abbildung 2 sehen wir eine Gesamtübersicht aller Prozessbereiche, die durch ASPICE definiert werden, wobei sich die Mitglieder des VDA (Verband der Automobilindustrie) primär auf die rot umrandeten Bereiche konzentrieren.

Abbildung in dieser Leseprobe nicht enthalten

Abb.2: Aufteilung der Prozessgruppen nach ASPICE12

Abbildung in dieser Leseprobe nicht enthalten

Abb.3: Primäres V-Modell der Entwicklungsprozesse nach ASPICE13

3. ASPICE System- und Softwareprozesse

3.1. SYS.1 Anforderungserhebung

Die Erhebung der Kundenanforderungen erfolgt kontinuierlich über den gesamten Lebenszyklus des Produkts. Die Anforderungen werden erfasst, verarbeitet, verstanden, vereinbart und verfolgt. Verglichen mit dem klassischen Projektmanagement entspricht SYS.1 in etwa dem Lastenheft wobei SYS.1 zusätzlich noch unternehmensinterne Anforderungen von Produktion, Marketing oder Management enthalten kann. Die Sammlung aller erhobenen Anforderungen dient als Basis für alle weiteren Arbeitsprodukte.14

3.2. SYS.2 Systemanforderungsanalyse

SYS.2 transformiert die in SYS.1 erhobenen Anforderungen in technisch detaillierte Anforderungen. Dabei soll das Design des Systems unterstützt werden. Die resultierenden Systemanforderungen entsprechen dem Pflichtenheft und sollten so geschrieben sein, dass ein Zusammenspiel der Entwicklungsbereiche Software, Hardware und Mechanik optimal möglich ist.15

Abbildung in dieser Leseprobe nicht enthalten

Abb.4: Schematische Struktur der Anforderungsspezifikation16

Abbildung in dieser Leseprobe nicht enthalten

Abb.5: Verfeinerung von Anforderungen über die verschiedenen Ebenen17

3.3. SYS.3 Systemarchitekturdesign

Die Aufgabe der Systemarchitektur ist es das Gesamtsystem in Systemelemente aufzuteilen, die Anforderungen den Elementen zuzuordnen und die Schnittstellen zwischen den Systemelementen zu definieren. Darüber hinaus wird hier entschieden welche Funktionen durch Hardware- oder Softwarelösungen umgesetzt werden.18

3.4. SWE.1 Softwareanforderungsanalyse

Aus den Systemanforderungen werden die Softwareanforderungen abgeleitet. Dabei werden die Anforderungen in funktionale und nicht funktionale Anforderungen unterschieden und noch weiter verfeinert (siehe Abb.5).19

3.5. SWE.2 Softwarearchitekturdesign

Im Prozess des Softwarearchitekturdesigns werden die einzelnen Softwarekomponenten modelliert und die entsprechenden Software-anforderungen zugeordnet. Auch die Schnittstellendefinition zwischen den Softwarekomponenten und die Zieldefinition des Ressourcenverbrauchs (CPU-Auslastung, Speicherverbräuche, etc.) erfolgt an dieser Stelle.20

3.6. SWE.3 Softwarefeinentwurf und Modulerstellung

Basierend auf den Softwareanforderungen und der Softwarearchitektur wird ein Softwarefeinentwurf erstellt und daraus die Software generiert. Dabei sind auch die nicht funktionalen Anforderungen, wie Beispielweise Wieder-verwendbarkeit, Wartbarkeit, Stabilität und Testbarkeit, zu berücksichtigen. Während der automatischen oder manuellen Code Erstellung wird in der Praxis iterativ zwischen Codierung und Fehlersuche gependelt, bis das Softwaremodul die gewünschten Funktionen erfüllt.21

3.7. SWE.4 Softwaremodulverifikation

Während der Softwaremodulverifikation werden die Softwaremodule darauf geprüft ob sie den dem Softwarefeinentwurf und den nicht funktionalen Anforderungen entsprechen. Neben statischen und dynamischen Analyse-verfahren werden Codereviews und der Softwaremodultest ausgeführt.22

Abbildung in dieser Leseprobe nicht enthalten

Abb.6: Welches Testlevel prüft welche Definitionen23

Wann im Entwicklungszyklus was geprüft wird soll durch Abbildung 6 verdeutlicht werden. Der Fokus eines Testlevels richtet sich immer auf das was im korrespondierenden Prozessschritt auf der linken Seite des V-Modell definiert wurde. Modulverifikation testet gegen den Softwarefeinentwurf, Softwareintegrationstest gegen die Softwarearchitektur, Softwaretest gegen die Softwareanforderungen usw.

3.8. SWE.5 Softwareintegration und Integrationstest

Die schrittweise Integration der Softwaremodule zu größeren Software-bestandteilen in Kombination mit begleitenden Integrationstest ermöglicht eine möglichst frühe Fehlererkennung in der Interaktion zwischen den Modulen. Außerdem ist zu prüfen ob die Softwaremodule, sowie deren Schnittstellen, der Softwarearchitektur (SWE.2) entsprechen.24

3.9. SWE.6 Softwaretest

Der Softwaretest hat die Aufgabe die integrierte Software auf das vollständige Erfüllen der Softwareanforderungen aus SWE.1 hin zu prüfen. Dabei ist besonders auf Nachverfolgbarkeit zu achten. Wirklich jede Softwareanforderung muss mit mindestens einem Testfall im Softwaretest geprüft werden.25

3.10. SYS.4 Systemintegration und Integrationstest

Die Aufgabe der Systemintegration ist es die Ergebnisse der Einzeldisziplinen Mechanik, Hardware und Software zu einem vollständigen System zusammenzusetzen. Im simplen Fall bedeutet es, dass auf das im Musterbau produzierte Steuergerät, das zugehörige Softwareprodukt aufgespielt wird. Im zugehörigen System Integrationstest wird sichergestellt, dass die Schnittstellen zwischen den Komponenten und die Schnittstellen zur Umwelt des Systems funktionieren.26

3.11. SYS.5 Systemtest

Im Systemtest wird das auszuliefernde System darauf geprüft ob alle in SYS.2 definierten Systemanforderungen erfüllt werden. Jede Systemanforderungen muss dabei mit mindestens einem Testfall geprüft werden. Die Nachverfolgbarkeit zwischen den einzelnen Systemanforderungen und den einzelnen Testfällen und deren Testergebnissen muss sichergestellt werden.27

[...]


1 vgl. http://www.oica.net/category/production-statistics/ (abgerufen am 22.05.2020)

2 vgl. https://www.focus.de/auto/ratgeber/auto-abc/auto-aus-wie-vielen-einzelteilen-besteht-ein-auto_id_3514353.html (abgerufen am 22.05.2020)

3 vgl. JAVORSKY, 2018, S.XIII

4 vgl. MÜLLER, 2016, S.V

5 vgl. https://www.vde.com/de/veranstaltungen/veranstaltungsuebersicht/veranstaltung-detailseite?id=17433&type=vde%7Cvdb (abgerufen am 22.05.2020)

6 vgl. https://vda-qmc.de/software-prozesse/automotive-spice/ (abgerufen am 22.05.2020)

7 vgl. http://www.automotivespice.com/download/ (abgerufen am 22.05.2020)

8 vgl. https://vda-qmc.de/software-prozesse/automotive-spice/ (abgerufen am 22.05.2020)

9 vgl. MÜLLER, 2016, S.9

10 https://vda-qmc.de/software-prozesse/automotive-spice/ (abgerufen am 24.05.2020)

11 vgl. MÜLLER, 2016, S.9 ff.

12 https://vda-qmc.de/software-prozesse/automotive-spice/ (abgerufen am 24.05.2020)

13 https://www.kuglermaag.com/fileadmin/05_CONTENT_PDF/2-11_automotive-spice_v3-0_update.pdf, S.25 (abgerufen am 24.05.2020)

14 vgl. MÜLLER, 2016, S.37 ff.

15 vgl. MÜLLER, 2016, S.46 ff.

16 MÜLLER, 2016, S.49

17 MÜLLER, 2016, S.48

18 vgl. MÜLLER, 2016, S.57 ff.

19 vgl. MÜLLER, 2016, S.76 ff.

20 vgl. MÜLLER, 2016, S.83 ff.

21 vgl. MÜLLER, 2016, S.91 ff.

22 vgl. MÜLLER, 2016, S.100 ff.

23 https://www.flecsim.de/images/download/AutomotiveSpice/Automotive%20Spice%203.0/Annex%20D.html (abgerufen am 07.06.2020)

24 vgl. MÜLLER, 2016, S.111 ff.

25 vgl. MÜLLER, 2016, S.121 ff.

26 vgl. MÜLLER, 2016, S.65 ff.

27 vgl. MÜLLER, 2016, S.73 ff.

Ende der Leseprobe aus 17 Seiten

Details

Titel
Softwareentwicklung in der Automobilindustrie
Hochschule
AKAD University, ehem. AKAD Fachhochschule Stuttgart
Note
1,3
Autor
Jahr
2020
Seiten
17
Katalognummer
V906685
ISBN (eBook)
9783346230690
ISBN (Buch)
9783346230706
Sprache
Deutsch
Schlagworte
Automotive SPICE, ASPICE, V-Modell
Arbeit zitieren
Sascha Lang (Autor:in), 2020, Softwareentwicklung in der Automobilindustrie, München, GRIN Verlag, https://www.grin.com/document/906685

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Softwareentwicklung in der Automobilindustrie



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden