C Referenz Produkte
C.1 Produkte
C.1.12 Systementwurf
C.1.12.1 Systemarchitektur
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 Produktstrukturierung).
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.
|
Verantwortlich |
|
Mitwirkend |
|
Hilfsmittel |
System entwerfen (Aktivität), Modellierungswerkzeug (Werkzeug), Systemarchitektur(.odt|.doc) |
|
Erzeugt durch |
Gesamtsystemspezifikation (Pflichtenheft) (Lebenszyklusanalyse und Gesamtsystemarchitektur) |
|
Entscheidungsrelevant bei |
C.1.12.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.
C.1.12.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. Für Externe Einheiten, die dem Projekt noch nicht vorliegen, muss dokumentiert werden, wie deren Beschaffung erfolgt. Zudem wird geregelt, für welche HW- und SW-Einheiten die Erstellung einer separaten Architektur notwendig ist. Abhängig vom Umfang und der Komplexität kann die Architektur des übergeordneten Systems auch bereits eine Betrachtung bis auf Modulebene enthalten.
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.
|
Erzeugt |
Architekturen der Einheiten des Systems: SW-Architektur (SW-Einheit) Beschaffung der Externen Einheiten des Systems: Make-or-Buy-Entscheidung (Externe Einheit), Marktsichtung für Fertigprodukte (Externe Einheit) Elemente des Systems: |
C.1.12.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.
C.1.12.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.
C.1.12.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.
|
Erzeugt |
Datenbankentwurf für das System: Datenbankentwurf (System) |
C.1.12.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.
C.1.12.1.7 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.
|
Erzeugt |
Spezifikation des Systems: Externe-Einheit-Spezifikation, Systemspezifikation (Segment; System) |
C.1.12.1.8 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.