4 Teil 5: V-Modell-Referenz Produkte
4.3 Produkte
4.3.9 Systementwurf
4.3.9.1 Systemarchitektur
|
Vorgehensbaustein |
Sinn und Zweck
Ausgehend von den funktionalen und nicht-funktionalen Anforderungen an das System ist es Aufgabe des Systemarchitekten, eine geeignete Systemarchitektur zu entwerfen. Die Architekturprodukte dienen dabei sowohl als Leitfaden als auch zur Dokumentation der Entwurfsentscheidungen.
In einem ersten Schritt werden richtungsweisende Architekturprinzipien festgelegt und mögliche Entwurfsalternativen untersucht. Entsprechend der gewählten Entwurfsalternative wird die Zerlegung (Dekomposition) des Systems in Segmente, HW-, SW- und Externe Einheit beschrieben (vergleiche Strukturelle Produktabhängigkeiten).
Beziehungen und Schnittstellen zwischen den Elementen und zur Umgebung werden identifiziert und im Überblick dargestellt. Zusätzlich werden querschnittliche Systemeigenschaften wie Sicherheitskonzept, Transaktionskonzept oder Loggingkonzept festgelegt.
Die gewählte Architektur wird hinsichtlich ihrer Eignung für das zu entwickelnde System bewertet. Offene Fragen können beispielsweise im Rahmen einer prototypischen Entwicklung geklärt werden.
Hauptverantwortlicher für den Architekturentwurf ist der Systemarchitekt. Unterstützt wird er von verschiedenen Experten zu Einzelthemen wie HW-Entwicklung, SW-Entwicklung, Logistik, Sicherheit oder Ergonomie.
Die Architektur stellt das zentrale Dokument für die Erstellung weiterer Produkte dar. Sie legt alle Segmente, HW-, SW- und Externe Einheiten des Systems fest. Entsprechend den Vorgaben werden für jede HW- oder SW-Einheit eine Architektur sowie für die jeweiligen Elemente die 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 |
Systemarchitektur erstellen |
Ausgehend von den Anforderungen in der Gesamtsystemspezifikation (Pflichtenheft) wird eine mögliche Struktur der Systemarchitektur beziehungsweise einer Unterstützungssystemarchitektur erarbeitet. Der Entwurf erfolgt im Rahmen eines iterativen Entwurfsprozesses.
Der Architektur-Erstellungsprozess beginnt mit der Identifikation der Architekturtreiber sowie - parallel dazu - der Festlegung von Bewertungskriterien. Architekturtreiber sind üblicherweise explizit oder implizit in den Anforderungen gegeben und legen grundlegende Eigenschaften der Architektur fest (zum Beispiel Busstruktur bei der Kommunikation oder Schichtenarchitektur bei der Dekomposition). Bei der Erstellung eines Unterstützungssystems ist zu berücksichtigen, dass diese möglichst integriert und - soweit möglich und sinnvoll - homogen sind (zum Beispiel Werkzeug-Kette von einem Hersteller). Insbesondere sollten sie einen nachvollziehbaren und durchgängigen Entwicklungsprozess unterstützen.
Parallel werden, ausgehend von den Anforderungen, Bewertungskriterien für die zu entwerfende Architektur definiert. Diese sind im Architekturentwurf zu berücksichtigen und sind Grundlage der späteren Designabsicherung.
Die Dokumentation eines Architekturentwurfs erfolgt durch Modellierung unterschiedlicher Sichten auf das System. In einem ersten Schritt sind alle Sichten, die das System geeignet beschreiben, festzulegen. Diese Sichten werden mit Hilfe von Werkzeugen und Modellierungssprachen (zum Beispiel UML) modelliert und um erläuternde Texte ergänzt.
Die so erarbeitete und dokumentierte Architektur wird im Hinblick auf die Anforderungen und die Bewertungskriterien einer Designverifikation unterzogen.
Folgende Teilschritte sind dabei enthalten:
- Architektur bewerten
- Architektursichten erarbeiten
- Architektursichten identifizieren
- Architekturtreiber identifizieren
- Bewertungskriterien festlegen
Welche Abhängigkeiten hat das Produkt?
|
Erzeugt durch |
Systemspezifikationen |
|
Erzeugt |
Anforderungen und Analysen Prüfung
Systemelemente
Systementwurf Systemspezifikationen |
|
Hängt inhaltlich ab von |
Anforderungen und Analysen IT-Organisation und Betrieb Planung und Steuerung Systementwurf Systemspezifikationen |
4.3.9.1.1 Architekturprinzipien und Entwurfsalternativen
Grundsätzlich gibt es für ein System beziehungsweise Unterstützungssystem mehrere Architekturlösungen, von denen jede ihre Vor- und Nachteile hat. Durch die Beschreibung der zugrunde liegenden Architekturprinzipien sowie möglicher Entwurfsalternativen wird der Entscheidungsprozess zur letztendlich gewählten Architektur dokumentiert und die Basis für eine Architekturbewertung gelegt.
Architekturprinzipien sind Vorgaben, die beispielsweise auf Grund der Systemart oder anderer Systemeigenschaften richtungweisend für den Architekturentwurf sind. Auf Systemebene kann dies beispielsweise die Festlegung der Anwendungsdomäne (Eingebettetes System, Informationssystem) oder die Entscheidung für ein verteiltes System sein.
Entwurfsalternativen beschreiben unterschiedliche Möglichkeiten der Dekomposition des Systems in Segmente, HW-, SW- und Externe Einheiten. Für jede Alternative werden anhand einer zu definierenden Kriterienliste Vor- und Nachteile identifiziert und die Lösung bewertet. Als Grundlage für die Suche nach möglichen Entwurfsalternativen eignen sich auf Systemebene beispielsweise Musterarchitekturen.
Vorgaben zu Architekturprinzipien sowie Einschränkungen bei möglichen Entwurfsalternativen ergeben sich vor allem aus den Anforderungen der Systemspezifikation beziehungsweise der Gesamtsystemspezifikation.
4.3.9.1.2 Dekomposition des Systems
Im Rahmen der Dekomposition wird die statische Struktur des Systems beziehungsweise Unterstützungssystems festgelegt. Die statische Struktur beschreibt die Zerlegung in Segmente und Einheiten. Das Entwurfsergebnis wird als Graph der zu realisierenden Segmenttypen und Einheitentypen sowie ihrer Beziehungen untereinander dokumentiert.
Für jede im Rahmen der Dekomposition identifizierte Einheit wird festgelegt, ob es sich um eine HW-, eine SW- oder eine Externe Einheit handelt.
Grundlage der Dekomposition sind die Anforderungen aus der Systemspezifikation. Randbedingungen für die Zerlegung werden durch die in der Systemarchitektur oder Unterstützungs-Systemarchitektur identifizierten Architekturprinzipien sowie die getroffenen Entwurfsentscheidungen vorgegeben.
4.3.9.1.3 Querschnittliche Systemeigenschaften
In einem System beziehungsweise Unterstützungssystem lassen sich systemelementspezifische und systemübergreifende Eigenschaften unterscheiden. Lösungen für systemelementspezifische Eigenschaften werden in den Spezifikationen der jeweiligen Systemelemente ausgearbeitet. Lösungen für systemübergreifende Eigenschaften werden hier beschrieben.
Zu typischen systemübergreifenden Eigenschaften zählen bei SW-Systemen beispielsweise Transaktionsanforderungen, Persistierung von Daten oder Anforderungen an Logging und Tracing. Für HW-Systeme können dies beispielsweise einheitliche Steckerbelegungen oder systemübergreifende Sicherheitsanforderungen sein. Welche querschnittlichen Systemeigenschaften zu berücksichtigen sind, wird im Rahmen dieses Themas festgelegt.
4.3.9.1.4 Schnittstellenübersicht
In der Schnittstellenübersicht der Systemarchitektur beziehungsweise der Unterstützungs-Systemarchitektur werden die Schnittstellen des Systems sowie die Schnittstellen seiner Systemelemente im Überblick dargestellt. Zur Beschreibung der Schnittstellenübersicht wird jeweils nur die Kommunikation auf einer Ebene betrachtet:
- Auf Ebene des Systems beziehungsweise Unterstützungssystems werden die Schnittstellen der Systeme untereinander sowie zur Umgebung beschrieben.
- Auf Ebene der Segmente werden die Schnittstellen zwischen den Segmenten innerhalb des Systems beziehungsweise Unterstützungssystems beschrieben.
- Auf Ebene der Einheiten werden die Schnittstellen zwischen den Einheiten innerhalb des Segments beschrieben.
Umgebungsschnittstellen eines Systems oder eines Systemelements können beispielsweise zum Anwender (Anwenderschnittstelle), zur Logistik (Dokumentation) oder zu verschiedenen Unterstützungssystemen (Mess- und Prüfgeräte, Ersatzteile) existieren. Die detaillierte Beschreibung der Schnittstellen erfolgt in den jeweiligen Spezifikationen der Systemelemente.
4.3.9.1.5 Übergreifender Datenkatalog
Systeme und Systemelemente tauschen zur Kommunikation Daten aus. Auf Hardwareebene handelt es sich beispielsweise um Signale, auf Softwareebene um serialisierbare Objekte zum Datentransport. Im übergreifenden Datenkatalog des Systems beziehungsweise Unterstützungssystems werden alle Datenstrukturen und Signale beschrieben, die an den Schnittstellen ausgetauscht werden, sowie mögliche Wertebelegungen.
Daten und Signale des Systems dienen als Vorgaben für den Datenkatalog der SW-Einheiten sowie den Daten- und Signalkatalog der HW-Einheiten.
4.3.9.1.6 Designabsicherung
Wurde ein Architekturentwurf gewählt und bis auf Einheitenebene ausgearbeitet, so ist sicherzustellen, dass der gewählte Entwurf Anforderungen in geeigneter Weise umsetzt. Dies wird im Rahmen einer Designverifikation geprüft und dokumentiert.
Im Thema Designabsicherung wird festgelegt, welche Methoden zur Designverifikation eingesetzt werden und nach welchen Kriterien geprüft wird, ob das Design die Anforderungen abdeckt. Eine häufig eingesetzte Methode zur Designverifikation ist die Entwicklung von Prototypen. Werden diese in einem Vorprojekt eingesetzt, haben die Anwender zusätzlich die Möglichkeit, anhand des Prototypen die Anforderungen auf Vollständigkeit zu prüfen.
Vorgaben zur Designverifikation sind die funktionalen und nicht-funktionalen Anforderungen der Systemspezifikation sowie die identifizierten Architekturprinzipien. Durchführung und Ergebnisse der Verifikation werden dokumentiert. Sie können eventuell eine Neubewertung der Entwurfsentscheidungen sowie eine Überarbeitung der Architektur nach sich ziehen.
4.3.9.1.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.
4.3.9.1.8 Zu spezifizierende Systemelemente
Die Erstellung einer Spezifikation für ein Systemelement ist aufwändig und nicht in allen Fällen erforderlich. Zur individuellen Anpassung des Spezifikationsaufwands an die Projekterfordernisse hat der Systemarchitekt abhängig von den Vorgaben im Projekthandbuch und den Anforderungen die Möglichkeit festzulegen, für welche Systemelemente eine Systemspezifikation zu erstellen ist.
Kriterien für die Notwendigkeit einer Spezifikation können beispielsweise sein: die Sicherheit des Systemelements, die Komplexität der Anforderungen an das Systemelement oder die Vorgaben zur Prüfung aus dem QS-Handbuch sowie dem jeweiligen Implementierungs, Integrations- und Prüfkonzept. Für Systemelemente, die einer Prüfung unterzogen werden, ist in jedem Fall eine Systemspezifikation zu erstellen, da sie als Vorgabe der Prüfspezifikation Systemelement dient.
Wenn Systemelemente als nicht zu spezifizieren eingestuft werden, ist jeweils eine Begründung aufzuführen.