 |
 |
 |
|
 |
|||
| SE 4.1-SW: SW-Architektur entwerfen |
SD4.1-SW - SW Architecture Design
 Inhalt
|
|
|
|---|
Produktfluß
| von | Produkt | nach | Methoden | Werkzeug Anf. | Ext. Normen | |||
|---|---|---|---|---|---|---|---|---|
| Aktivität | Zustand | Kapitel | Titel | Aktivität | Zustand | |||
| SE1 | akzeptiert | Alle | Anwenderforderungen | - | - |
/ISO IEC 12207/
Devlp. Proc.: |
||
| SE2 | akzeptiert | Alle | Systemarchitektur | - | - | |||
| SE3 | akzeptiert | Alle | Technische Anforderungen | - | - | |||
| SE2 | in Bearb. | Existierend | Schnittstellenübersicht | SE4.2-SW SE5-SW KM4.3 |
vorgelegt |
KOM (2) MODIAG (2) SSM (2) |
LSE22 LSE23 LSE24 LSE29 LSE30 LSE31 |
|
| SE3 | in Bearb. | Existierend | Betriebsinformationen: Anwendungshandbuch Diagnosehandbuch Betriebshandbuch Sonstige Einsatzinformationen |
SE4.3-SW | in Bearb. | |||
| - | - | Alle | SW-Architektur | SE4.2-SW SE4.3-SW SE5-SW |
vorgelegt |
AVK (7) KOM (2) DVER (6) FS (5) IAM (2) MODIAG (2) OBJE (8) PZIM (3) PRODIAG (2) SSM (2) ZUST (4) STRD (8) |
LSE01 LSE03 LSE04 LSE20 LSE22 LSE23 LSE24 LSE25 LSE28 LSE29 LSE30 LSE31 |
|
+ "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250
Abwicklung
* SW-Architektur entwerfen
Die SW-Architektur beschreibt die Zerlegung einer SW-Einheit in SW-Komponenten, Prozesse, SW-Module und Datenbanken. Vorschläge für mögliche SW-Architekturen werden erarbeitet und bewertet; für die weitere Bearbeitung ist ein Lösungsvorschlag auszuwählen.SW-Einheiten bestehen im allgemeinen aus mehreren Prozessen oder Tasks, die parallel oder quasi-parallel ablaufen. Ziel ist es, eine SW-Einheit unter dem Gesichtspunkt notwendiger oder möglicher Parallelverarbeitung zu strukturieren. Dabei sind die Gegebenheiten des Betriebs- und Laufzeitsystems und die Erfordernisse und Einschränkungen der Hardware und der Programmiersprache zu berücksichtigen. Die SW-Architektur enthält eine Beschreibung des Prozeß-Ensembles samt seiner Strukturierung, Kommunikation, Synchronisation und Darstellung des dynamischen Ablaufmodells.
Zu jedem Baustein (Prozeß, SW-Komponente, SW-Modul, Datenbank) des ausgewählten Vorschlags sind eine kurze Leistungsbeschreibung und die Relevanz hinsichtlich der Sicherheit (Kritikalitätsstufe, sicherheitsspezifische Funktion, sicherheitsrelevante Funktion) anzugeben.
Die aufgrund von Architekturentscheidungen festgelegten Schnittstellen sind in der SW-Architektur zu identifizieren und in der Schnittstellenübersicht zu dokumentieren.
Die vollständige Abdeckung der Anforderungen durch die in der SW-Architektur definierten Prozesse, SW-Komponenten, SW-Module und Datenbanken ist nachzuweisen.
Auf der Basis der SW-Architektur sind Angaben für die Betriebsinformationen (Anwendungshandbuch, Diagnosehandbuch, Betriebshandbuch, Sonstige Einsatzinformationen) zu erarbeiten.
* IT-Sicherheitsaspekte beachten
Neben den Abhängigkeiten der IT-Sicherheitsfunktionen sind die Wechselwirkungen der IT-Sicherheitsmechanismen, die zur Realisierung der IT-Sicherheitsfunktionen gewählt wurden, zu untersuchen. Es sind die Auswirkungen, die die Realisierung der IT-Sicherheitsfunktionen auf andere SW-Einheiten haben könnte, zu untersuchen. Ebenso sind die Abhängigkeiten von Funktionen hinsichtlich der Kritikalität zu untersuchen.Es ist festzustellen, ob und gegebenenfalls welche IT-sicherheitsspezifischen oder IT-sicherheitsrelevanten Anteile(1) in anderen SW-Komponenten/SW-Modulen/Datenbanken bei der Realisierung entstehen.
Die Schnittstellen vom IT-sicherheitsrelevanten zum IT-sicherheitsunkritischen Teil sind in jeder SW-Einheit zu minimieren. Diese Schnittstellen in jeder SW-Einheit und zwischen den einzelnen SW-Einheiten sind exakt zu definieren.
Erläuterungen
In der Regel werden neben den für die Realisierung von operationellen Anwendungsfunktionen erforderlichen SW-Komponenten/SW-Modulen auch SW-Komponenten/SW-Module benötigt, die lediglich technische Hilfsfunktionen zur Verfügung stellen und deshalb nicht aus den operationellen Anforderungen, sondern aus den Gegebenheiten des technischen Lösungsansatzes herzuleiten sind (z. B. Gateway-Elemente). Diese sind bei der Festlegung der SW-Architektur mit zu berücksichtigen.
Einfluß auf diese Modularisierungsentscheidungen haben::
- Prozeßstruktur der SW-Einheit,
- zusätzlich notwendige (systeminterne) Funktionen,
- Zielrechner (Laufzeitsystem, Protokolle, usw.),
- Konzepte der Fehlerbehandlung, Kommunikation, usw.,
- Kriterien wie: Information Hiding, Datenabstraktion, Abgeschlossenheit, Minimalität der Schnittstellen, Überschaubarkeit, Prüfbarkeit, Integrierbarkeit, Wiederverwendbarkeit, usw.,
- Anforderungen an Zeitverhalten und Zuverlässigkeit.
Rollen
| Rolle | Beteilungsarten | ||
|---|---|---|---|
| SW-Entwickler | verantwortlich
| Technischer Autor |
mitwirkend |
|
Werkzeuganforderungen
Externe Normen
| Norm | Prozeß | Kapitel | Bemerkung |
|---|---|---|---|
| /ISO IEC 12207/ | Development Prozeß | Software Architectural Design | (s. Part 3 - ISO 3.2.1) |
Verknüpfungen mit der V-Modell Mailingliste
Mail 0724 - Re: Abdeckungsmatrix (724)Mail 0524 - Mehrere Fragen zum V-Modell (524)
Mail 0251 - Midestanforderungen (251)
(1 ) Unter "IT-sicherheitsspezifischen oder IT-sicherheitsrelevanten Anteilen" werden auch die Funktionen hoher Kritikalität verstanden, die durch entsprechende Maßnahmen realisiert werden.
(2 ) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.
(3 ) Die Methode PZIM ist anzuwenden, wenn der Entwurf mehrere parallel auszuführende Prozesse enthält.
(4 ) Die Methode ZUST ist anzuwenden, wenn beim Ablauf der Funktion oder des Prozesses komplexe Situationen zu berücksichtigen sind.
(5 ) Die Methode FS ist anzuwenden bei besonderen Anforderungen an die Korrektheit, z. B. aufgrund sehr hoher Kritikalität. FS wird gemäß [ITSEC] ab Korrektheitsstufe E4 für die Beschreibung des formalen Sicherheitsmodells gefordert. Der Einsatz von FS für den Grobentwurf wird gemäß [ITSEC] in E6 verlangt.
(6 ) Voraussetzung für den Einsatz von DVER ist eine formale Spezifikation auf zwei verschiedenen Abstraktionsebenen. Aufgrund des hohen Aufwands sind die kritischsten Anteile einer Spezifikation auszuwählen, für die DVER einzusetzen ist. Die Methode DVER ist gemäß [ITSEC] ab Korrektheitsstufe E4 für den Beweis des formalen Sicherheitsmodells anzuwenden. Der Einsatz von DVER zum Beweis, daß der Grobentwurf mit dem Sicherheitsmodell konsistent ist, wird gemäß [ITSEC] in E6 gefordert.
(7 ) Die Methode AVK ist gemäß [ITSEC] anzuwenden, wenn verdeckte Kanäle in den Sicherheitsvorgaben ausgeschlossen werden und ab der Evaluationsstufe E4 für die Bewertung der Konstruktions- und der operationellen Schwachstellen; als formale Analyse ist AVK ab E6 einzusetzen.
(8 ) Die Methode OBJE ist anzuwenden für eine realzeitorientierte Entwicklung mit nebenläufigen Prozessen; sonst ist die Methode STRD anzuwenden.
This page online
•
GDPA Online
•
Last Updated 07.Mar.2004 by
C. Freericks