5 Teil 5: V-Modell-Referenz Produkte

5.3 Produkte

5.3.10 Systementwurf

5.3.10.1 Systemarchitektur

Verantwortlich: Systemarchitekt (bei Verwendung des Vorgehensbausteins Systemerstellung)

Mitwirkend: SW-Architekt, HW-Architekt, Logistikverantwortlicher

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

Wird erzeugt von

Gesamtsystemspezifikation (Pflichtenheft) (siehe Produktabhängigkeit 4.26)

Erzeugt

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, HW-Architektur, HW-Einheit, HW-Spezifikation, Implementierungs-, Integrations- und Prüfkonzept HW, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.4)

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur, SW-Einheit, SW-Spezifikation, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.15)

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, Marktsichtung für Fertigprodukte, Externe Einheit, Externe-Einheit-Spezifikation, Make-or-Buy-Entscheidung, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.20)

Prüfprotokoll Benutzbarkeit, Prüfspezifikation Benutzbarkeit, Prüfprotokoll Systemelement, Prüfprozedur Systemelement, Prüfspezifikation Systemelement, Segment, Systemspezifikation, Datenschutzkonzept, Informationssicherheitskonzept, Sicherheitsanalyse (siehe Produktabhängigkeit 4.23)

Hängt inhaltlich ab von

Logistische Berechnungen und Analysen, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 5.22)

Gesamtsystemspezifikation (Pflichtenheft), Altsystemanalyse (siehe Produktabhängigkeit 5.59)

Beispielprodukte

»FWD:Systemarchitektur

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

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

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

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

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

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

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