Entwurf der Softwarearchitektur in Automotive SPICE® – SWE.2

Einführung

Worauf kommt es bei der Softwarearchitektur an? Gehen wir davon aus, dass Sie bereits Softwareanforderungen haben, die beschreiben, was die Software leisten soll. Mit der Softwarearchitektur wird definiert, wie die in den Softwareanforderungen dokumentierte Funktionalität implementiert werden soll. Kurz gesagt, die Anforderungen beschreiben das „Was“ und die Architektur beschreibt das „Wie“. 

Drei Aspekte der Softwarearchitektur

Architektursichten 

Oft besteht die Architektur nur aus einer physischen Sicht, einem Blockdiagramm der Software. Gerade bei komplexen Projekten – und das trifft heutzutage auf die meisten Projekte zu – reicht das nicht aus. Eine hierarchische Gliederung bietet Ihnen eine bessere Übersicht, denn sie zeigt auf, wie funktionale und nicht-funktionale Anforderungen in den verschiedenen Komponenten und Teilkomponenten umgesetzt werden. 

Daneben gibt es dynamische Sichten, spezifische funktionale Sichten, die eine Aufschlüsselung einer bestimmten Funktion zeigen, sowie Zustandsübergangsdiagramme und Schnittstellen, um nur ein paar zu nennen. 

Je komplexer ein System ist, desto mehr Sichten sind erforderlich. 

Da die verschiedenen Sichten konsistent gehalten werden müssen, sollte ein geeignetes UML- oder SysML-Tool verwendet werden. Dieses Tool unterstützt die Konsistenzprüfungen. 

Schnittstellen 

Eine häufig anzutreffende Falle bei Assessments ist das Fehlen einer detaillierten Schnittstellen-Beschreibung. Die erwarteten Inhalte einer Schnittstellendokumentation sind: 

• Name 
• Art/Typ 
• Einheit 
• Auflösung 
• Wertbereich 
• Standardwert 

Ohne diese Informationen ist ein ordnungsgemäßes Testen der Schnittstellen im Integrationstest nicht möglich. Werden die Schnittstellen jedoch in einem geeigneten UML- oder SysML-Tool beschrieben, gewährleistet dies die Konsistenz zwischen den verschiedenen Sichten. 

Traceability 

Dieser Prozess erwartet auch die Nachverfolgbarkeit, die so genannte Traceability, zwischen Ihrer Softwarearchitektur und den Softwareanforderungen. 

Normalerweise gibt es einen Werkzeugbruch zwischen den Anforderungen und der Architektur. Dadurch wird die Traceability erschwert. 
Zweck der Traceability besteht in der Unterstützung von: 

• Konsistenzprüfungen, d. h.der Überprüfung auf Vollständigkeit und Korrektheit der Abdeckung der Softwareanforderungen  
• Auswirkungsanalyse (Impactanalyse) bei Änderungsanträgen oder Fehlern 
• Unterstützung der Berichterstattung über die Erwartungen der Stakeholder und Klärung, welche Anforderungen getestet wurden (Abdeckungsbericht) 

Welchen Nutzen bietet der Software-Architekturentwurf? 

Die Entwicklung von Software für die Automobilindustrie ist ohne die Definition einer Architektur im Vorfeld nicht möglich. Sie bietet nicht nur eine systematische Strukturierung der Software in ihre Elemente entsprechend den Anforderungen, sondern definiert auch das dynamische Verhalten der Software sowie den Ressourcenverbrauch ihrer Elemente. Die Qualität der Architektur hat einen großen Einfluss auf die Effizienz, Wartbarkeit, Testbarkeit, Wiederverwendbarkeit und Wartungskosten des Produkts. 

Die Architektur ist auch notwendig, um die Anforderungen der ISO 26262 zu erfüllen. Sicherheitsanforderungen müssen auf Softwareelemente zurückgeführt werden können. Auf dieser Grundlage werden das Sicherheitskonzept (zu Projektbeginn erforderlich) und der Sicherheitsnachweis (am Ende des Projekts erforderlich) erstellt. 

Was beinhaltet der Software-Architekturentwurf-Prozess? 

• Die Softwarearchitektur wird auf Basis der funktionalen und nicht-funktionalen Softwareanforderungen (und ggf. Sicherheitsanforderungen) entwickelt. (BP1, BP2)  
• Das ist der Stand der Technik: 
• Eine physikalische Gliederung in Elemente bis hin zu den Komponenten (BP1). 
• Modellierung des dynamischen Verhaltens (BP4). 
• Optional: Modellierung der Funktionalitäten (insbesondere wenn ein völlig neues Produkt entwickelt wird). 
• Alternative Architekturen werden auf der Grundlage von Faktoren wie Wartbarkeit, Erweiterbarkeit, Skalierbarkeit, Zuverlässigkeit, Sicherheit und Benutzerfreundlichkeit berücksichtigt (BP6). Architekturentscheidungen werden begründet und dokumentiert. 
• Die Schnittstellen und das dynamische Verhalten (BP3, BP4) sowie die Zielvorgaben für den Ressourcenverbrauch (z. B.in Bezug auf ROM, RAM, EEPROM, Flash-Speicher, CPU-Last usw.) für die Architekturelemente (BP5) werden spezifiziert. 
• Es wird eine bidirektionale Traceability und Konsistenz zwischen Softwareanforderungen und Architekturelementen hergestellt (BP7, BP8). Die Traceability stellt sicher, dass bekannt ist, welche Anforderungen in welchen Elementen umgesetzt werden sollen und umgekehrt. Konsistenz kann nur durch Traceability gewährleistet werden. Konsistenz bedeutet, dass die Verknüpfungen zwischen Anforderungen und Architekturelementen korrekt und vollständig sind. 
• Die Architektur wird allen Beteiligten kommuniziert (BP9). 

Erfahrungen, Probleme und Tipps 

•  Um eine Softwarearchitektur zu entwerfen, werden in der Regel Entwurfswerkzeuge eingesetzt. Ein weiterer Trend ist die automatische Codegenerierung aus den mit dem Entwurfswerkzeug erstellten Entwurfsmodellen. 

• Moderne Tools unterstützen die strukturelle Zerlegung in Elemente, die dynamische Modellierung (z. B. Sequenzdiagramme) und die funktionale Modellierung. UML-, SysML- und XML-Tools bieten in der Regel Konsistenzprüfungen zwischen verschiedenen Darstellungen der Architektur, wodurch manueller Aufwand vermieden wird. 

Beispiel einer Softwarearchitektur 

• Die funktionale Modellierung ist in der Automobilindustrie relativ neu. Viele Projekte waren mit einem enormen Aufwand verbunden, der nicht immer gerechtfertigt erschien, insbesondere wenn die Funktionalität bestehender Legacysoftware modelliert wurde. 
• Die Architektur soll im Wesentlichen eine vereinfachte Sicht auf das Softwaresystem ermöglichen. Sie ist als Abstraktion gedacht und verbirgt Details, so dass ein Gesamtverständnis der Softwareteile und ihrer Zwecke leicht beschrieben und verstanden werden kann. 
• Bei der Entwicklung einer Plattform wird in der Regel eine Basisarchitektur geschaffen, die der Kunde/das Anwendungsteam dann an seine spezifischen Anforderungen anpassen kann. Das funktioniert allerdings nur, wenn beide Parteien – das Entwicklungsteam der Plattform und der Kunde/das Anwendungsteam – ein gemeinsames Verständnis der zugrunde liegenden Softwarearchitektur haben und pflegen. 
• Kurz gesagt: Die Architektur ist oft zu kompliziert, und der Architekt nicht in der Lage, sie prägnant und einfach auszudrücken. Das wiederum wirkt sich negativ auf das gesamte Projekt aus, da es keine gemeinsame Verständnisgrundlage gibt. 
• Mit dieser Automotive SPICE® Version können nun auch alternative Architekturen berücksichtigt werden – ein ideales Tool für die Entwicklung völlig neuer Software. Bei den meisten Projekten in der Automobilindustrie werden jedoch Änderungen an bestehender Software vorgenommen, ohne dass die Architektur geändert wird. Der Nachweis alternativer Architekturen kann deshalb herausfordernd sein. Die strukturierte Konfiguration der Plattform kann als Bewertung alternativer Architekturen betrachtet werden. Erfolgt die Konfiguration etwa auf der Basis von Applikationsparametern, können alternative Parameterkombinationen analysiert und die Gründe für die Wahl einer bestimmten Kombination dokumentiert werden. 
• Wurde die Architektur von einem anderen Projekt oder einer anderen Plattform übernommen, können alternative Entwurfsentscheidungen dokumentiert werden. 
• Die Traceability hat sich in den letzten Jahren zwar verbessert, die Konsistenz lässt aber immer noch zu wünschen übrig. Das liegt ganz einfach daran, dass die Bedeutung von Konsistenz lange Zeit nicht wirklich verstanden wurde.Zusätzlich erfordert Konsistenz einen erheblichen Reviewaufwand. 

Vertiefen Sie Ihr Wissen über Automotive SPICE®  

Sie interessieren sich für Automotive SPICE®? Dann sind unsere Automotive SPICE® Schulungen genau das Richtige für Sie!  

Ü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. 

Das könnte Sie auch interessieren

Ressourcenleitfaden zum Automotive SPICE ^®  Software-Architekturentwurf (SWE.2)

Dienstleistungen für Automotive SPICE und Erweiterungen