8.2.2 Systemarchitektur



		8.2.2 Systemarchitektur (SysArc)

System Architecture

Inhalt
Einleitung
Inhalt des Dokuments
Aufbau des Dokuments
Produktfluß
Verknüpfungen mit der V-Modell Mailingliste

Inhalt		Einleitung Inhalt des Dokuments Aufbau des Dokuments Produktfluß Verknüpfungen mit der V-Modell Mailingliste

Einleitung

Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur, mit den Elementen der generischen Erzeugnisstruktur. Betrachtet werden dabei die Elemente der Erzeugnisstruktur bis einschließlich der SW-Einheiten/HW-Einheiten. Die Architekturen der SW-Einheiten und HW-Einheiten finden sich in den zugehörigen Architekturdokumenten.

Das Produkt Systemarchitektur enthält mögliche Lösungsvorschläge, Ergebnisse von Realisierbarkeitsuntersuchungen, das IT-Sicherheitskonzept, das IT-Sicherheitsmodell und die Zuordnung zwischen Anwenderforderungen und den Elementen der Systemarchitektur.

Inhalt des Dokuments

1. Allgemeines
2. Struktur des Systems
2.1. Darstellung der technischen Systemarchitektur
2.1.1. Technischer Aufbau des Systems
2.1.2. Identifikation der Schnittstellen
2.1.3. Anforderungszuordnung
2.2. Erläuterung der Zusammenarbeit der technischen Elemente
3. Realisierung
3.1. Lösungsvorschläge
3.2. Realisierbarkeitsuntersuchungen
4. IT-Sicherheitskonzept
5. IT-Sicherheitsmodell

Aufbau des Dokuments

1. Allgemeines

Siehe Gliederungspunkt 1. Allgemeines.

2. Struktur des Systems

2.1.Darstellung der technischen Systemarchitektur

2.1.1. Technischer Aufbau des Systems

Das System wird als Netzwerk der Elemente der technischen Architektur dargestellt. Dabei werden die Möglichkeiten der generischen Erzeugnisstruktur möglichst eingesetzt, um SW-Einheiten/HW-Einheiten geeignet zu Segmenten und diese zu Systemen zusammenzufassen. Die Bestandteile der Architektur werden auf der Basis der Angaben aus dem KM-Plan eindeutig gekennzeichnet und verbindlich identifiziert. Die Architektur muß in der Aufzählung ihrer Elemente vollständig und konsistent sein.

Die Teile des Systems, die durch Fertigprodukte realisiert werden sollen, oder in denen Fertigprodukte eingesetzt werden sollen, sind festzulegen.

Beim Entwurf der Systemarchitektur ist zu beachten, daß sich die technische Struktur eines IT-Systems und die Organisation beim Anwender in der Regel gegenseitig beeinflussen. Die Anwenderorganisation ist bei den Überlegungen zur Systemarchitektur einerseits als wichtiger Einflußfaktor für mögliche Lösungsansätze heranzuziehen. Bei IT-Systemen mit Client-Server-Architektur sind andererseits in der Anwenderorganisation gegebenenfalls Kapazitäten für System- und Nutzerbetreuung vor Ort vorzusehen. Bei diesen Überlegungen ist darüberhinaus auch die Verteilung neuer Systemversionen und -varianten während der Nutzung zu bedenken und organisatorisch zu regeln. Dabei sind sowohl technische als auch wirtschaftliche Aspekte zu berücksichtigen.

2.1.2. Identifikation der Schnittstellen

Aus der Architektur ergibt sich die Identifikation der Schnittstellen, die hier tabellarisch eindeutig mit der Nennung der jeweiligen Partner geschieht. Die Schnittstellen werden im Rahmen des technischen Entwurfs festgelegt. Hier werden die systeminternen wie die systemexternen Schnittstellen identifiziert. Hier werden technische Schnittstellen identifiziert, die im allgemeinen nicht deckungsgleich mit fachlichen Schnittstellen sind.

2.1.3. Anforderungszuordnung

In Tabellenform werden die Bezüge zwischen den Elementen der Systemarchitektur (Segmente und SW-Einheiten/HW-Einheiten) und den im Produkt "Anwenderforderungen" enthaltenen Anforderungen (Schnittstellenanforderungen, funktionale Anforderungen, Qualitätsforderungen, etc.) und Randbedingungen hergestellt. Damit soll der Nachweis erbracht werden, daß alle gestellten Anforderungen und Randbedingungen durch die Elemente der Systemarchitektur adressiert werden.

Die Tabelle enthält

die Zuordnung der Anforderungen zu den Elementen der technischen Architektur und
Hinweise auf den technischen Ablauf.

Folgende Punkte sind dabei zu beachten:

Jede Forderung muß auf mindestens ein Element der technischen Architektur, im Idealfall auf genau ein Architekturelement, zugeordnet werden.

Jede Forderung wird auf das in der Detaillierungsschichtung niedrigste Element zugeordnet, das die Erfüllung der Forderung vollständig ermöglicht. Im Normalfall muß die Gesamtmenge der Forderungen auf verschiedene Detaillierungsschichten zugeordnet werden.

Sofern eine Forderung von Element-übergreifender Bedeutung ist, muß im Rahmen der Zuordnung genau abgewägt werden, welche einzelnen Architekturelemente diese Anforderung letztendlich zu erfüllen haben.

Die Zuordnung muß so erfolgen, daß durch die Prüfung des entsprechenden Architekturelements die Erfüllung der Forderung nachgewiesen werden kann.

Bei der Zuordnung von Anwenderforderungen zu Elementen können Hinweise auf die Vorgaben bzgl. des technischen Ablaufs gegeben werden. Dabei kann auf die technische Architektur Bezug genommen werden.

Bei der objektorientierten Entwicklung ist zu beachten: Die funktionalen Anwenderforderungen werden in Form von Anwendungsfällen, den "Use Cases" beschrieben. Diese Anwenderforderungen werden letztendlich in Klassenhierarchien und deren Zusammenwirken realisiert. Die Zuordnung der Anwenderforderungen kann daher bei der objektorientierten Entwicklung durch eine Zuordnung von "Use Cases" zu Gruppen von Klassen (-hierarchien) erfolgen, durch deren Zusammenwirken diese Anforderungen erfüllt werden können.

2. 2. Erläuterung der Zusammenarbeit der technischen Elemente

Hier werden die technischen Abläufe dargestellt, wie sie sich als Auswirkung der technischen Architekturentscheidungen ergeben. Dies geschieht ausschließlich auf der Basis der technischen Architektur. (In keinem Fall handelt es sich hier um eine Änderung oder inhaltliche Überschneidung zu den fachlichen Geschäftsprozessen.)

Zusätzlich ist hier gegebenenfalls die Rechner-übergreifende Prozeßkommunikation zu beschreiben, die später im Rahmen der SW-Architektur zu verfeinern ist.

Beispiele: Technischer Ablauf der Kommunikation der Nutzer über ein Client-Server-Netzwerk auf der Basis eines Novell-Netzwerks; technische Lösung für den Zugang ausgewählter Nutzer zum Internet; technische Unterstützung der Mitzeichnungswege über E-Mail usw.

3. Realisierung

3.1. Lösungsvorschläge

Lösungsvorschläge können frei gewählte Ausschnitte der Architektur betreffen. Sie sind weder auf eine Ebene der generischen Erzeugnisstruktur noch auf einzelne Elemente eines Systems zu beschränken.

Lösungsskizzen für die Struktur des Systems oder von Systemteilen beschreiben die Architekturidee und die Zerlegung des Systems oder Systemteils. Grundlage der Systemskizzen sind in jedem Fall die Anwenderforderungen.

Der mögliche Einsatz von Fertigprodukten ist bei der Erarbeitung der Lösungsvorschläge zu berücksichtigen.

3.2. Realisierbarkeitsuntersuchungen

Die Lösungsvorschläge werden so bewertet, daß die Vor- und Nachteile in bezug auf die Realisierbarkeit dargestellt werden.

Die Ergebnisse der Marktsichtung hinsichtlich der Verfügbarkeit geeigneter Fertigprodukte sind zu dokumentieren.

Folgende Aspekte können im Rahmen der Realisierbarkeitsuntersuchung betrachtet werden:

Entwicklungsanforderungen (z. B. Einsatz von speziellen Programmiersprachen)
Berücksichtigung der besonderen Anforderungen an kritische Systemteile (insbesondere Verflechtung mit anderen Komponenten)
Auswirkungen der besonderen Ausstattung des Zielrechners
Auswirkungen des Einsatzes von Fertigprodukten (Bezug zum Forderungscontrolling)
Fehlerbehandlungskonzept/LI>
Synchronisations- und Kommunikationsmechanismen
notwendige Spezialentwicklungen
Ergebnisse von Benchmarks

Für den ausgewählten Lösungsvorschlag muß die Auswahlentscheidung nachvollziehbar dokumentiert werden.

4. IT-Sicherheitskonzept

Dieses Kapitel beschreibt die IT-Sicherheitsstrategie und begründet auf dieser Basis die Maßnahmen im System selbst und in der Systemumgebung, die in ihrem Zusammenwirken die Anforderungen an die IT-Sicherheit abdecken. Die Aufgaben der Maßnahmen und die Verantwortung bei ihrer Durchführung sind zu beschreiben. Die Wirksamkeit der Gesamtheit der Maßnahmen, ihre Verträglichkeit mit Vorschriften und Richtlinien, das Kosten-Nutzen-Verhältnis und das verbleibende Restrisiko sind zu begründen.

5. IT-Sicherheitsmodell

Falls ein IT-Sicherheitsmodell gefordert ist, ist hier nachzuweisen, daß die IT-Sicherheitsanforderungen in sich konsistent sind und daß die Zielsetzungen des IT-Sicherheitskonzepts durch die modellierten IT-Sicherheitsfunktionen und deren externe Schnittstellen eingehalten werden.

Produktfluß

Kapitel		Aktivität	von		nach		Methoden	Werkzeug Anf.	Externe Normen
NR.	Titel	Aktivität	Aktivität	Zustand	Aktivität	Zustand	Methoden	Werkzeug Anf.	Externe Normen
2.1.1	Technischer Aufbau des Systems	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.	COM CRC PRODIAG SSM	SSD22 SSD23 SSD25
2.1.2	Identifikation der Schnittstellen	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.
2.1.3	Anforderungszuordnung	SE2.4	-	-	SE1 SE2.5 SE2.6 SE3 SE4-SW PM4 PM5	submitted	ER	SSD01 SSD09
2.2	Erläuterung der Zusammenarbeit der technischen Elemente	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.	IAM	SSD28
3.1	Lösungsvorschläge	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.	COM CRC FCTD SSM	SSD22 SSD23
3.2	Realisierbarkeitsuntersuchungen	SE2.3	-	-	SE2.1 PM5	being proc.	BA SIMU	SSD18 SSD19
4	IT-Sicherheitskonzept	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.
4	IT-Sicherheitskonzept	SE2.2	-	-	SE2.1	being proc.
5	IT-Sicherheitsmodell	SE2.1	-	-	SE2.2 SE2.3 SE2.4	being proc.
Existing		SE2.1	SE2.2	being proc.	-	-
Existing		SE2.1	SE2.3	being proc.	-	-
Existing		SE2.1	SE2.4	being proc.	-	-

Verknüpfungen mit der V-Modell Mailingliste

Mail 0653 - QS-Plan: Fragen zu Festlegung der Kritikalität, Vererbung, Infizierung und zughörigen Dokumenten (653)
Mail 0594 - Unterstützung der Betriebseinführung (594)
Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0197 - IT-Sicherheitskonzept (197)
Mail 0156 - Re: SE 2, Systemarchitektur (156)
Mail 0148 - SE 2, Systemarchitektur (149)

This page online • GDPA Online • Last Updated 06.Mar.2003 by C. Freericks