Previous Next V-Model Official Homepage by IABG  
Header  
SE 2.1: System technisch entwerfen  

  SD2.1 - Technical System Design

Inhalt  
  • Produktfluß
  • Abwicklung
  • Rollen
  • Methoden
  •  
  • Werkzeuganforderungen
  • Externe Normen
  • Pre-Tailoring-Formblätter
  • Verknüpfungen mit der V-Modell Mailingliste
  • Produktfluß

    von Produkt nach Methoden Werkzeug Anf. Ext. Normen
    Aktivität Zustand Kapitel Titel Aktivität Zustand
    PM2 akzeptiert Existierend Angebotsbewertung (1) - -     /ISO IEC 12207/

    Devlp. Proc.:
    Sys. Arch. Design

    SE1 akzeptiert Existierend Anwenderforderungen - -    
    SE2.2
    SE2.3
    in Bearb. Existierend Systemarchitektur - -    
    - - 2.1.1 Systemarchitektur.
    Technischer Aufbau
    SE2.2
    SE2.3
    SE2.4
    in Bearb. KOM
    CRC
    PRODIAG
    SSM
    LSE22
    LSE23
    LSE25
    - - 2.1.2 Systemarchitektur.
    Identifikation der Schnittstellen
       
    - - 2.2 Systemarchitektur.
    Zusammenarbeit der technischen Elemente
    IAM (2) LSE28
    - - 3.1 Systemarchitektur.
    Lösungsvorschläge
    KOM
    CRC
    FKTD
    SSM
    LSE22
    LSE23
    - - 4 Systemarchitektur.
    IT-Sicherheitskonzept
       
    - - 5 Systemarchitektur.
    IT-Sicherheitsmodell
       
    - - Alle Betriebsinformationen:
    Anwendungshandbuch
    Diagnosehandbuch
    Betriebshandbuch
    Sonstige Einsatzinformationen
    SE2.6 in Bearb.    
    - - Alle Technische Anforderungen SE2.6
    SE3
    in Bearb. KOM
    CRC
    PRODIAG
    SSM
    LSE01
    LSE05
    LSE22
    LSE23
    LSE25
    - - Alle Schnittstellenübersicht SE2.5
    SE4-SW
    KM4.3
    in Bearb. KOM
    DFM
    SSM
    LSE07
    LSE22
    LSE23

    + "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

    Produkt Methodenzuordnung Benutzung
    Kapitel 2
    Systemarchitektur.
    Technischer Aufbau
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    CRC - Class Responsibility Collaboration (2) Erstellen
    PRODIAG - Prozeßdiagramme (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 2.2
    Systemarchitektur.
    Erläuterungen of the
    Cooperation of
    Technical Elements
    IAM - Interaktionsmodellierung (2) Erstellen
    Kapitel 3.1
    Systemarchitektur.
    Lösungsvorschläge
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    CRC - Class Responsibility Collaboration (2) Erstellen
    FKTD - Funktionale Dekomposition Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 5.x.2
    Technische Anforderungen.
    Overall Function of Element
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    CRC - Class Responsibility Collaboration (2) Erstellen
    PRODIAG - Prozeßdiagramme (2) Erstellen
    Kapitel 5.x.3
    Technische Anforderungen.
    Technische Anforderungen for the Interfaces
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    SSM - Subsystemmodellierung (2) Erstellen
    Kapitel 2
    Schnittstellenübersicht.
    System-Extern Interfaces
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    DFM - Datenfluß-Modellierung Erstellen
    Kapitel 3
    Schnittstellenübersicht.
    System-Internal Interfaces
    KOM - Klassen-/Objektmodellierung (2) Erstellen
    DFM - Datenfluß-Modellierung Erstellen
    SSM - Subsystemmodellierung (2) Erstellen

    Hinweise
    (1) Falls Fertigprodukte verwendet werden sollen.
    (2) Die Methoden sind bei objektorientierter Entwicklung einzusetzen.

    Werkzeuganforderungen

    Produkt Funktionale Werkzeuganforderungen
    Kapitel 2.1
    Systemarchitektur.
    Representation of the Technical Systemarchitektur
    LSE22 - Klassen-/Objektmodellierung
    LSE23 - Subsystemmodellierung
    LSE25 - Prozeßdiagramme
    Kapitel 2.2
    Systemarchitektur.
    Zusammenarbeit der technischen Elemente
    LSE28 - Interaktionsmodellierung
    Kapitel 3.1
    Systemarchitektur.
    Lösungsvorschläge
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung
    Technische Anforderungen LSE01 - Anforderungen erfassen
    Kapitel 5.x.2
    Technische Anforderungen.
    Overall Function of Element
    LSE05 - Funktionsstrukturierung unterstützen
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE25 - Prozeßdiagramme unterstützen
    Kapitel 5.x.3
    Technische Anforderungen.
    Technische Anforderungen for the Interfaces
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen
    Kapitel 2
    Schnittstellenübersicht.
    System-Extern Interfaces
    LSE07 - Modellierung der Informationsflüsse unterstützen
    LSE22 - Klassen-/Objektmodellierung unterstützen
    Kapitel 3
    Schnittstellenübersicht.
    System-Internal Interfaces
    LSE07 - Modellierung der Informationsflüsse unterstützen
    LSE22 - Klassen-/Objektmodellierung unterstützen
    LSE23 - Subsystemmodellierung unterstützen

    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   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Mittlere administrative IT-Vorhaben   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Große administrative IT-Vorhaben   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Kleine/mittlere technisch-wissenschaftliche IT-Vorhaben   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Große technisch-wissenschaftliche IT-Vorhaben   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          
    Auswahl, Beschaffung und Anpassung von Fertigprodukten   SD2.1 x System Architecture SD2.1 x Technical Requirements SD2.1 x Interface Overview             SD2.1 x Operational Information             SD2.1 x Basic Requirements          

    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)

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Feb.2003 by C. Freericks