Thought Leadership
Unser Alltag ist heute wie selbstverständlich von miteinander vernetzten Geräten und Systemen geprägt. Ob man mit dem Smartphone unterwegs den schnellsten Weg zum Ziel findet, auf dem Sofa mit dem Tablet die Zeitung liest oder die smarte Heizung über eine App auf dem Smartphone steuert, diese Systeme machen unser Leben komfortabler. Der Gewinn an Komfort erfordert jedoch auch strengere Security- und Safety-Anforderungen, mit denen die Entwickler solcher Systeme Schritt halten müssen. Dies gilt besonders für das autonome Fahren – hier haben schlüssige Safety- Konzepte oberste Priorität.
Knowhow und Fertigkeiten, über die Software-Architekten verfügen sollten
Mit steigender Produktkomplexität und immer leistungsfähigerer Hardware erhöhen sich auch der Umfang und die Komplexität der Software von Embedded-Systemen. In vielen Produkten setzt die Software den wesentlichen Teil der Funktionalität um. Die Abteilungen, die Embedded-Software entwickeln, wachsen kontinuierlich. Dies ist insbesondere in der Automobilindustrie zu sehen und spiegelt sich auch auf dem aktuellen Arbeitsmarkt wider. So plant Mercedes-Benz beispielsweise, ab 2030 den überwiegenden Anteil am Umsatz durch softwarebasierte Systeme zu erzielen. Es wird nicht mehr in einer „One-Man-Show“ entwickelt, sondern in großen Teams – verteilt auf unterschiedliche Standorte auf der ganzen Welt.
Der Stellenwert von Embedded-Software hat sich in den vergangenen Jahren in den meisten Unternehmen – sogar im Produktbereich der Mechatronik – der Embedded-Branche drastisch erhöht. Doch dies ist erst der Anfang.
Agile Software-Entwicklungsmethoden stehen verstärkt im Rampenlicht
In agilen Softwareprojekten wird die Software-Architektur evolutionär entwickelt, unter anderem basierend auf testgetriebenen Software-Entwicklungsmethoden. Dabei herrschen zwei unterschiedliche Entwicklungsansätze vor:
- Funktionsarchitektur: Das Softwaresystem wird in Funktionen bzw. Features und deren Abhängigkeiten dargestellt.
- Komponentenarchitektur: Entwickelt einen Grobentwurf sowie mehrere Feinentwürfe, die eine feingranulare Struktur der Software enthalten.
Software-Architektur spielt eine tragende Rolle für den Projekterfolg
Damit der Software-Architekt seiner verantwortungsvollen Tätigkeit gerecht werden kann, benötigt er fundiertes Knowhow zu folgenden maßgeblichen Aspekten:
1. Grundverständnis der Software-Architektur
Auf abstrakter Ebene stellt die Software-Architektur eine Brücke zwischen den Anforderungen und der Implementierung der Software dar. In der Software beschreibt die Architektur die grobe Struktur (nur in Ausnahmefällen auch Module und Klassen), z.B. bestehend aus Software-Komponenten, Software-Schichten, Software-Subsystemen, Interfaces und deren Abhängigkeiten. Für diese Architekturelemente lassen sich aber auch ein interaktives und ein individuelles Verhalten beschreiben. Ein wesentlicher Bestandteil der Software-Architektur ist auch die Laufzeitarchitektur.
2. Die Rolle des Software-Architekten
Jeder mit dem notwendigen Knowhow kann im Unternehmen die Rolle des Software-Architekten in einem Projekt einnehmen. Doch um das Thema wirklich professionell zu betreiben, sollte man aus meiner Sicht die personengebundene Rolle bevorzugen. Abhängig von der Projektgröße sind einer oder mehrere Software-Architekten an einem Projekt beteiligt.
3. Der Chef-Architekt leitet Software-Architektenteams an
Der Software-Architekt stimmt sich mit mehreren Rollen im Projekt ab und benötigt dafür fachliches und nicht-fachliches Wissen – je mehr Erfahrung er hat, desto besser. So sollte die Rolle des Software-Architekten idealerweise nicht mit einem Absolventen direkt von der Hochschule besetzt werden. Hier sind extrovertierte, innovationsfreudige, entscheidungsfreudige und erfahrene Mitarbeiter gefragt.
Entwurfsvorgehen – so entsteht eine Software-Architektur
Das Entwurfsvorgehen beschreibt den Entstehungsprozess der Software (-Architektur). Jedes Unternehmen muss das für sich am besten geeignete Vorgehen finden und implementieren. An dieser Definition ist der Software-Architekt wesentlich beteiligt.
Basierend auf einer V-Modell-artigen Darstellung kann das Entwurfsvorgehen für die Entwicklung eines kompletten Embedded-Systems eingesetzt werden, also nicht nur für die Software-Entwicklung.
Anforderungen (WAS) und entsprechende Anforderungen (WIE)
In den Analyseaktivitäten identifizieren und dokumentieren die Analysten (real betrachtet meist auch die Architekten) der einzelnen Ebenen die entsprechenden Anforderungen (das WAS). Darauf basierend entstehen die Architekturen (das WIE). Auf den Subsystem-Architekturen aufbauend entwickelt der Software-Architekt die Software-Architektur für ein Subsystem – in Abstimmung mit den anderen Entwicklungsdomänen auf gleicher Ebene (z.B. Hardware-Entwicklung).
Parallel zu den Anforderungen entwickelt das Testteam die Testfälle, um später die korrekte Umsetzung nachzuweisen. Dies erfolgt ebenfalls auf den unterschiedlichen Ebenen. „Design for Test“ und neu „Design for Safety“ sind dabei grundlegende Software-Architekturthemen.
Entwurfsbasis und Einflussfaktoren
Aus der in Bild 3 dargestellten X-Analyse (hier Software-Analyse) entstehen die Software-Anforderungen (funktional und nicht-funktional).
Während einer Einflussfaktorenanalyse entscheidet der Software-Architekt über die
- Relevanz der Anforderung für die Software-Architektur
- Veränderbarkeit der Anforderung in der Zukunft
- Ableitung der Konsequenzen für die Software-Architektur
Teil der nicht-funktionalen Software-Anforderungen sind die Software-Qualitätsmerkmale, die die Software erbringen muss, wie z.B.
- Portierbarkeit
- Wartbarkeit
- Zuverlässigkeit
- Sicherheit
- Ressourcenverbrauch
- Performance
- Echtzeitfähigkeit
Hier die Sicht durch die Brille der relevanten Software-Qualitätsmerkmale: SAFETY
Hier aus Sicht der relevanten Software-Qualitätsmerkmale: Reliability
Bei den Qualitätsmerkmalen ist zu beachten, dass manche mitläufig, andere aber auch gegenläufig sind.
Stellen wir uns mit diesem Wissen die folgende Frage: Welche Anforderungen beeinflussen die Architektur mehr – funktionale oder nicht-funktionale?
Richtige Antwort: die nicht-funktionalen Anforderungen!
Somit bilden die Software-Anforderungen und die daraus resultierenden Einflussfaktoren neben der Subsystem-Architektur die wichtigste Entwurfsbasis für die Software-Architektur.
Kommunikation und Dokumentation
Der Software-Architekt schafft mit einer verständlichen Dokumentation der Software-Architektur für alle Stakeholder die Basis für jedes Projekt und damit eine lückenlose Nachvollziehbarkeit für alle Projektbeteiligten. Damit sichert er den Fortbestand des Unternehmens.
Die Dokumentation bildet gleichzeitig die Kommunikationsbasis, die kontinuierlich mit den Stakeholdern abzugleichen ist.
Wichtigster Stakeholder ist dabei der Software-Entwickler, der die Software-Architektur im Design verfeinert und final in der Zielprogrammiersprache implementiert. Neben dem Software-Entwickler haben weitere Rollen, wie beispielsweise das Software-Testteam, ein berechtigtes Interesse an der Software-Architektur. Nur wenn ich weiß, was gewollt ist, kann ich prüfen, ob dies auch wirklich so umgesetzt wurde.
UML (Unified Modeling Language) ist die Notation, mit der sich verschiedenste Sichten und Aspekte der Software-Architektur dokumentieren und im Design verfeinern lassen – bis hin zur automatischen Codegenerierung. Mit dem Paketdiagramm sind in Bild 4 die unterschiedlichen Software-Schichten modelliert.
Mehr lesen Sie in Teil 2.
