 |
 |
 |
|
 |
|||
| SE 2.1: System technisch entwerfen |
SD2.1 - Technical System Design
 Inhalt
|
|
|
|---|
Produktfluß
+ "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250
Abwicklung
* Lösungsvorschläge erarbeiten
Auf der Basis der Anwenderforderungen wird der Lösungsvorschlag für eine mögliche technische Struktur des Systems (Systemarchitektur) erarbeitet. Falls mehrere alternative Lösungsvorschläge notwendig sind, wird unter Beteiligung des Projektmanagements einer ausgewählt und verfeinert. Falls die Auswahl der Lösung hier nicht durchgeführt wird oder mehrere Varianten offen läßt, müssen die nachfolgenden Aktivitäten je Lösungsvariante durchgeführt werden. Augenmerk ist hierbei speziell auf die Einsatzmöglichkeit von Fertigprodukten zu legen. Die im Rahmen von Aktivität SE2.3 - Realisierbarkeit untersuchen durchgeführte Prüfung auf die Verfügbarkeit geeigneter Fertigprodukte kann eine Änderung der Entwurfsentscheidung bewirken.Der Lösungsvorschlag wird auf der Basis der in Aktivität SE1.5 - System fachlich strukturieren definierten bzw. angesprochenen Bereiche formuliert. Dadurch werden fachliche abgrenzbare Problemstellungen betrachtet und in den nachfolgenden Realisierbarkeitsuntersuchungen bewertet.
* Definition of Systemarchitektur
Der ausgewählte Lösungsvorschlag wird detailliert. Die Teile des Systems, die durch Fertigprodukte realisiert werden oder in denen Fertigprodukte eingesetzt werden sollen, sind auszuweisen. Sind bereits konkrete Fertigprodukte ausgewählt, so sind diese hier zu nennen. Sofern der Einsatz der Fertigprodukte zusätzliche Entwicklungsarbeiten erfordert, sind diese auszuweisen. Die im Rahmen der Aktivität PM 2 "Vergabe/Beschaffung" bei der Angebotsbewertung gewonnenen Erkenntnisse sind entsprechend zu detaillieren.Die Definition der Systemarchitektur umfaßt die Darstellung des technischen Aufbaus des Systems und die Identifikation der Schnittstellen zwischen den Elementen der Architektur und des Gesamtsystems nach außen. Alle in der Systemarchitektur identifizierten Schnittstellen sind in der Schnittstellenübersicht festzuhalten.
Dazu sind die Elemente des Systems - wenn möglich - bereits jetzt technisch zu charakterisieren, um geeignete Fertigprodukte frühzeitig positionieren zu können.
Die Darstellung des Aufbaus des Systems wird ergänzt durch die Beschreibung des technischen Ablaufs (Interaktion zwischen den Elementen der Architektur). Die Architekturbeschreibung muß nachvollziehbar plausibel machen, daß die fachlichen Anforderungen und die im Rahmen der Anwenderforderungen definierten Randbedingungen durch die beschriebene technische Lösung abgedeckt werden können.
Die Festlegung der Systemarchitektur hat unter der Maßgabe zu erfolgen, möglichst bewährte Fertigprodukte einzusetzen. Nötigenfalls kann über das Forderungscontrolling eine Modifikation/Reduktion der Anwenderforderungen durchgeführt werden.
Die Systemarchitektur wird hier in einem ersten Schritt erstellt. Im Rahmen des Entwurfs der Segmente wird die Systemarchitektur schrittweise ergänzt.
* Technische Anforderungen ermitteln
Das Gesamtbild der Forderungen ergibt sich aus den Anwenderforderungen und den daraus abgeleiteten Technische Anforderungen.Soweit möglich und aus den Anwenderforderungen ableitbar, sind Technische Anforderungen an die Funktionalität, an die Schnittstellen, an die Qualität und die Entwicklungs- und SWPÄ-Umgebung der Elemente der Systemarchitektur zu definieren. Die Kritikalität des Architekturelements ist festzulegen.
Anforderungen an die Entwicklungs- und SWPÄ-Umgebung sind auf der Systemebene anzugeben. Falls für einzelne Elemente gesonderte Anforderungen existieren, sind diese zusätzlich im Rahmen der Technische Anforderungen an dieses Element anzugeben.
Sofern technische Anforderungen keinem Element der Systemarchitektur zugeordnet werden können, sind diese als allgemeine Anforderungen festzuhalten.
Bei den Technische Anforderungen handelt es sich um ergänzende und interpretierende Forderungen, die aus der technischen Sicht an ein Element der technischen Architektur gestellt werden. Anwenderforderungen sollen hier nicht wiederholt werden.
An die IT-Sicherheitsfunktionen sind Anforderungen hinsichtlich der Mechanismen zu stellen, mit denen sie realisiert werden sollen. Dies sind die angestrebte Mechanismenstärke und die E-Stufe der Implementierung.
Abhängig von der Kritikalität der kritischen Funktionen/Komponenten ist das Konzept der Realisierung und die Qualität der Implementierung (E-Stufe oder Safety Integrity Level) zu bestimmen. Requirements concerning the mechanisms they are to be realized with have to be made for the IT security functions. They are the required mechanism strength and the E-level of the implementation.
* Betriebsinformationen dokumentieren
Auf der Basis der Systemarchitektur und der Anwenderforderungen sind die systembezogenen Angaben für die Betriebsinformationen (Anwendungshandbuch, Diagnosehandbuch, Betriebshandbuch, Sonstige Einsatzinformationen) zu erstellen.* IT-Sicherheitsaspekte beachten
Um speziell die Anforderungen an die IT-Sicherheit abzudecken, werden Lösungsmöglichkeiten durch geeignete IT- und Nicht-IT-Maßnahmen (z. B. organisatorische oder bautechnische Maßnahmen) vorgeschlagen und für jeden Vorschlag das verbleibende Restrisiko bestimmt. Durch die Summe aller IT-Maßnahmen wird der Sicherheitsanteil des IT-Systems festgelegt. Unter Zugrundelegung der Ergebnisse der Realisierbarkeitsuntersuchung wird die geeignete Lösung einschließlich ihrer Begründung als IT-Sicherheitskonzept ausgewiesen.Eine IT-Sicherheitsfunktion kann entweder durch ein bereits vorhandenes Fertigprodukt abgedeckt werden, oder sie muß als SW-Einheit oder HW-Einheit entwickelt werden.
Hardwaremäßig realisierte Anteile sind für die Evaluation relevant. Gegebenenfalls müssen bestimmte Kriterien bei der Vorlage zur Evaluation abhängig von der angestrebten Evaluationsstufe erfüllt sein (z. B. Vorlage der Hardware-Konstruktionszeichnungen).
Diejenigen Anforderungen an die Systemsicherheit, die durch den IT-Sicherheitsanteil abgedeckt werden, sind zu identifizieren. Falls gefordert, ist ein IT-Sicherheitsmodell zu erstellen, das das Zusammenwirken der IT-sicherheitsrelevanten Funktionen stark vereinfacht, in dieser Vereinfachung aber präzise und vollständig darstellt.
Beim Verfeinerungsprozeß der IT-Sicherheitsfunktionen werden im allgemeinen neue Elemente eingeführt und zusätzliche Schnittstellen geschaffen, die neue Schwachstellen bedeuten können. Sofern diese neu entstehenden Schwachstellen ausnutzbar sind, um das vorgegebene IT-Sicherheitsziel zu verletzen, sind weitere Maßnahmen in das IT-Sicherheitskonzept mit aufzunehmen, die dem entgegenwirken. Ebenso können beim Verfeinerungsprozeß Schwachstellen in Form von unerwünschten Abhängigkeiten und Beziehungen auftreten (Fehlerfortpflanzung, single point of failure, Vererbung einer hohen Kritikalität auf zu viele Komponenten). Dies kann eine Wiederholung früherer Aktivitäten wie z. B. der Aktivität SE1.6 "Bedrohung und Risiko analysieren" erfordern.
* Infrastrukturmaßnahmen planen und umsetzen
Alle erforderlichen Infrastrukturmaßnahmen sind zu identifizieren und zu planen. Die Umsetzung der geplanten Maßnahmen ist in die Wege zu leiten. Die Dokumentation der durchzuführenden Infrastrukturmaßnahmen wird nicht im V-Modell geregelt.* IT-Sicherheitsanteil abgrenzen
Eine klare Abgrenzung des IT-Sicherheitsanteil (sicherheitsspezifische und sicherheitsrelevante Funktionen einschließlich Funktionen hoher Kritikalität) von den übrigen Elementen der Systemarchitektur muß erfolgen. Die Anzahl der Schnittstellen zwischen IT-Sicherheitsanteil und nicht sicherheitskritischer Software ist so klein wie möglich zu halten.Aufgrund von Wechselwirkungen innerhalb der gewählten Architektur neu entstandene Schnittstellen im IT-Sicherheitsanteil und die zusätzlichen Schnittstellen zwischen dem verfeinerten IT-Sicherheitsanteil und der übrigen Software müssen in die Schnittstellenübersicht mit aufgenommen werden.
In der Schnittstellenübersicht muß auch die Notwendigkeit jeder Schnittstelle des IT-Sicherheitsanteil zu den übrigen Elementen der Systemarchitektur und die Notwendigkeit jeder Schnittstelle innerhalb des IT-Sicherheitsanteil begründet werden.
Die Schnittstellen zur Einsatzumgebung sind exakt zu beschreiben. Beispielsweise werden bei den Stufen gemäß ITSEC erhöhte Anforderungen an die Beschreibungsformen gestellt.
---------- Der folgende Teil ist eine erweiterung zum Originalausdruck AU 250 -----------
Rollen
| Rolle | Beteilungsarten | ||||||
|---|---|---|---|---|---|---|---|
| Projektleiter | mitwirkend
| Systemdesigner |
verantwortlich
| Technischer Autor |
mitwirkend
| IT-Beauftragter |
mitwirkend |
|
Methoden
Hinweise
(1) Falls Fertigprodukte verwendet werden sollen.
(2) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.
Werkzeuganforderungen
Externe Normen
| Norm | Prozeß | Kapitel | Bemerkung |
|---|---|---|---|
| /ISO IEC 12207/ | Development Prozeß | System Architectural Design | (s. Part 3 - ISO 3.2.1) |
Pre-Tailoring-Formblätter
| Pre-Tailoring-Formblätter | SE Produkte |  |
Durchführungs- bedingungen |
||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
| ||
| Kleine administrative IT-Vorhaben |  |
|
|
|
|
||||||||||||||||||
| Mittlere administrative IT-Vorhaben | |
|
|
|
|
||||||||||||||||||
| Große administrative IT-Vorhaben | |
|
|
|
|
||||||||||||||||||
| Kleine/mittlere technisch-wissenschaftliche IT-Vorhaben | |
|
|
|
|
||||||||||||||||||
| Große technisch-wissenschaftliche IT-Vorhaben | |
|
|
|
|
||||||||||||||||||
| Auswahl, Beschaffung und Anpassung von Fertigprodukten | |
|
|
|
|
||||||||||||||||||
Matrixeinträge:
immer erforderlich
unter den geg. Umständen erforderl.
nicht erforderlich
nur Daten bzw. Datenbank beschreiben
Verknüpfungen mit der V-Modell Mailingliste
Mail 0617 - Erstellen von Programmierrichtlinie (617)Mail 0246 - Re: Umfang von SE 1.2 bei inkrementeller Entwicklung (246)
Mail 0197 - IT-Sicherheitskonzept (197)
Mail 0156 - Re: SE 2, Systemarchitektur (156)
|
|
|
This page online • GDPA Online • Last Updated 03.Feb.2003 by C. Freericks |