4 Teil 5: V-Modell-Referenz Produkte
4.3 Produkte
4.3.9 Systementwurf
4.3.9.4 SW-Architektur
|
Vorgehensbaustein |
Sinn und Zweck
Für jede in der Systemarchitektur identifizierte SW-Einheit wird eine SW-Architektur erstellt. Ausgehend von den funktionalen und nicht-funktionalen Anforderungen an die SW-Einheit ist es Aufgabe des SW-Architekten, eine geeignete SW-Architektur zu entwerfen. Das Produkt SW-Architektur dient dabei sowohl als Leitfaden zum Entwurf als auch zur Dokumentation der Entwurfsentscheidungen.
Wie in der Systemarchitektur werden richtungweisende Architekturprinzipien festgelegt und mögliche Entwurfsalternativen untersucht. Entsprechend der gewählten Entwurfsalternative wird die Zerlegung (Dekomposition) der SW-Einheit in SW-Komponenten, SW-Module und Produkte vom Typ Externes SW-Modul beschrieben (vergleiche Strukturelle Produktabhängigkeiten).
Beziehungen und Schnittstellen zwischen den Elementen und zur Umgebung werden identifiziert und im Überblick dargestellt. Ein Datenkatalog der an den Schnittstellen ausgetauschten Datenstrukturen wird erstellt.
Die gewählte Architektur wird hinsichtlich ihrer Eignung für das geforderte System bewertet. Offene Fragen können beispielsweise im Rahmen einer prototypischen Entwicklung geklärt werden.
Der Entwurf der SW-Architektur kann Änderungen der Systemarchitektur nach sich ziehen. Abhängig von den Vorgaben im Projekthandbuch wird die Änderung vom Systemarchitekten geprüft und gegebenenfalls direkt eingearbeitet. Im Einzelfall kann ein expliziter Änderungsantrag notwendig sein.
Hauptverantwortlicher für den Entwurf der SW-Architektur ist der SW-Architekt. Unterstützt wird er dabei vom SW-Entwickler sowie von verschiedenen Experten zu Einzelthemen wie Logistik, Sicherheit oder Ergonomie.
Die SW-Architektur stellt das zentrale Dokument für die Erstellung weiterer Produkte dar. Sie legt alle SW-Komponenten und SW-Module der SW-Einheit fest. Entsprechend ihren Vorgaben werden die jeweiligen Elemente mit ihren Spezifikationen erstellt.
Wann ist das Produkt entscheidungsrelevant?
|
Entscheidungspunkt |
Wer ist beteiligt?
|
Verantwortlich |
|
|
Mitwirkend |
Womit kann das Produkt erstellt werden?
|
Werkzeuge |
|
|
Methoden |
Welche Vorlagen sind verfügbar?
|
Vorlagen |
Produktvorlage wird generiert. |
|
Beispielprodukte |
Wie erstellt man das Produkt?
|
Aktivität |
SW-Architektur erstellen |
Im Rahmen der Architekturerstellung ist eine SW-Architektur der SW-Einheit aus den Anforderungen abzuleiten und festzulegen.
Der Architektur-Erstellungsprozess beginnt mit der Identifikation der Architekturtreiber sowie - parallel dazu - der Festlegung von Bewertungskriterien. Anschließend werden Architektursichten ermittelt und ausgearbeitet. Die Ausarbeitung entspricht dem eigentlichen Designprozess.
Die ausgearbeitete Architektur wird schließlich anhand der Bewertungskriterien überprüft und ausgewählt. Der Architektur-Erstellungsprozess kann in mehreren Zyklen durchgeführt werden.
Folgende Teilschritte sind dabei enthalten:
- Architektur bewerten
- Architektursichten erarbeiten
- Architektursichten identifizieren
- Architekturtreiber identifizieren
- Bewertungskriterien festlegen
Welche Abhängigkeiten hat das Produkt?
|
Erzeugt durch |
Systementwurf |
|
Erzeugt |
Anforderungen und Analysen Prüfung
Systemelemente Systemspezifikationen |
|
Hängt inhaltlich ab von |
Anforderungen und Analysen IT-Organisation und Betrieb Planung und Steuerung Systementwurf Systemspezifikationen |
4.3.9.4.1 Architekturprinzipien und Entwurfsalternativen
Die Beschreibung des Themas Architekturprinzipien und Entwurfsalternativen entspricht weitgehend dem Thema Architekturprinzipien und Entwurfsalternativen der Systemarchitektur.
Zu den Architekturprinzipien auf SW-Ebene zählen beispielsweise die Entscheidung für ein Programmierparadigma (objektorientiert, prozedural), die Entscheidung für eine Technologie (CORBA, EJB) oder auch die Vorgabe für eine spezielle Systemart (verteilte Internetanwendung, Desktopanwendung). Hilfestellung bei Entwurfsalternativen für die SW-Entwicklung geben beispielsweise Entwurfsmuster, Musterarchitekturen und Entwurfsheuristiken.
4.3.9.4.2 Dekomposition der SW-Einheit
Im Rahmen der Dekomposition wird die statische Struktur der SW-Einheit festgelegt. Die statische Struktur beschreibt die Zerlegung der Einheit in SW-Komponenten und SW-Module. Das Entwurfsergebnis wird als Graph der zu realisierenden SW-Elemente sowie ihrer Beziehungen untereinander dokumentiert. Zur Darstellung können beispielsweise Komponenten- und/oder Klassendiagramme verwendet werden.
Grundlage der Dekomposition sind die Anforderungen aus der SW-Spezifikation der SW-Einheit oder eines übergeordneten Systemelements. Randbedingungen werden durch die in der SW-Architektur identifizierten Architekturprinzipien sowie die getroffenen Entwurfsentscheidungen vorgegeben.
4.3.9.4.3 Schnittstellenübersicht
In der Schnittstellenübersicht der SW-Architektur werden die Schnittstellen der SW-Einheit sowie die Schnittstellen ihrer SW-Elemente im Überblick dargestellt. Zur Beschreibung der Schnittstellenübersicht wird jeweils nur die Kommunikation auf einer Ebene betrachtet:
- Auf Ebene der SW-Einheit werden die Schnittstellen zu anderen Einheiten sowie zur Umgebung beschrieben.
- Auf Ebene der SW-Komponenten werden die Schnittstellen zwischen den Komponenten innerhalb der Einheit beschrieben.
- Auf Ebene der SW-Module werden die Schnittstellen zwischen den Modulen innerhalb der Komponente beschrieben.
Umgebungsschnittstellen eines SW-Elements können beispielsweise zum Anwender, zur Logistik oder zu verschiedenen Unterstützungssystemen existieren. Die detaillierte Beschreibung der Schnittstellen erfolgt in den jeweiligen Spezifikationen der SW-Elemente.
4.3.9.4.4 Datenkatalog
Im Datenkatalog der SW-Architektur werden die an den Schnittstellen der SW-Einheit ausgetauschten Datenstrukturen mit Attributen, Datentypen und Wertebereichen beschrieben. Jede Programmiersprache und Plattform bietet hier eigene Lösungen, die bei der Definition zu berücksichtigen sind.
4.3.9.4.5 Designabsicherung
Wurde ein Architekturentwurf für die SW-Einheit gewählt und bis auf Modulebene ausgearbeitet, so ist sicherzustellen, dass der gewählte Entwurf für die Anforderungen geeignet ist. Zur Designabsicherung von SW-Architekturen stehen verschiedene Methoden zur Verfügung. Zwei häufig eingesetzten Methoden sind beispielsweise die Architekturevaluierung mit szenario-basierten Methoden und die prototypische Entwicklung von Systemteilen. Durchführung und Ergebnisse der Designabsicherung werden dokumentiert. Sie können gegebenenfalls eine Neubewertung der Entwurfsentscheidungen und eine Überarbeitung der Architektur nach sich ziehen.
4.3.9.4.6 Zu spezifizierende SW-Elemente
Die Erstellung einer Spezifikation für ein SW-Element ist aufwändig und nicht in allen Fällen erforderlich. Zur individuellen Anpassung des Spezifikationsaufwands an die Projekterfordernisse hat der SW-Architekt, abhängig von den Vorgaben im Projekthandbuch und den Anforderungen, die Möglichkeit festzulegen, für welche SW-Elemente eine SW-Spezifikation zu erstellen ist.
Kriterien für die Notwendigkeit einer Spezifikation können beispielsweise sein: die Kritikalität des SW-Elements, die Komplexität der Anforderungen an das SW-Element oder die Vorgaben zur Prüfung im Implementierungs-, Integrations- und Prüfkonzept SW. Für SW-Elemente, die einer Prüfung unterzogen werden, ist in jedem Fall eine SW-Spezifikation zu erstellen, da sie als Vorgabe der Prüfspezifikation Systemelement dient. Für SW-Elemente, die als nicht zu spezifizieren eingestuft wurden, ist jeweils eine Begründung aufzuführen.
4.3.9.4.7 Nachweis der IT-Sicherheit
Dieses Thema enthält den Nachweis, dass das erstellte System den Anforderungen im Bereich IT-Sicherheit genügt. Die Anforderungen leiten sich aus der Gesamtsystemspezifikation (Pflichtenheft) ab und werden auf Basis der Systemarchitektur bzw. der SW-Architektur nachgewiesen. Dies umfasst beispielsweise den Nachweis der Verfügbarkeit, der Integrität oder der Vertraulichkeit.