Previous Next V-Model Official Homepage by IABG  
Header  
SE 4-SW: SW-Grobentwurf  

  SD4-SW - Preliminary SW Design

Inhalt  
  • Produktfluß
  • Abwicklung
  • Rollen
  • Teilaktivitäten
  •  
  • Werkzeuganforderungen
  • Externe Normen
  • Verknüpfungen mit der V-Modell Mailingliste
  • Produktfluß

    von Produkt nach Methoden Werkzeug Anf. Ext. Normen
    Aktivität Zustand Kapitel Titel Aktivität Zustand
    SE1 akzeptiert Alle Anwenderforderungen - -      
    SE2 akzeptiert Alle Systemarchitektur - -    
    SE3 akzeptiert Alle Technische Anforderungen - -    
    SE2 in Bearb. Existierend Schnittstellenbeschreibung SE5-SW
    KM4
    vorgelegt AVK (7)
    KOM (2)
    DVER (6)
    FS (5)
    IAM (2)
    ZUSTO (3)
     
    SE2 in Bearb. Existierend Schnittstellenübersicht SE5-SW
    KM4
    vorgelegt KOM (2)
    MODIAG (2)
    SSM (2)
     
    SE2 in Bearb. Existierend Integrationsplan SE7-SW
    SE8
    QS2
    vorgelegt    
    SE3 in Bearb. Existierend Betriebsinformationen:
    Anwendungshandbuch
    Diagnosehandbuch
    Betriebshandbuch
    Sonstige Einsatzinformationen
    SE5-SW in Bearb.    
    - - Alle SW-Architektur SE5-SW vorgelegt AVK (7)
    KOM (2)
    DVER (6)
    FS (5)
    MODIAG (2)
    OBJE (8)
    PZIM (3)
    PRODIAG (2)
    SSM (2)
    ZUST (4)
    STRD (8)
     

    + "Kapitel" sind zusätzliche Spalten zum Originalausdruck AU 250

    Abwicklung

    Abbildung 4.5

    Abbildung 4.5: SD4 - SW-Grobentwurf

    Diese Aktivität beinhaltet den Entwurf der SW-Architektur, inklusive der Vervollständigung der Schnittstellenübersicht, die Beschreibung der SW-Schnittstellen und die Fortführung des Integrationsplans auf SW-Ebene.

    Der Entwurf der SW-Architektur hat die Aufgabe, aus Sicht der Dynamik der SW-Einheit SW-Prozesse zu bilden und gegebenenfalls die Aufteilung auf Prozessoren vorzunehmen sowie die Kommunikation und Synchronisation der Prozesse zu entwerfen und aus Sicht der statischen Struktur der SW-Einheit SW-Module, SW-Komponenten und Datenbanken zu definieren. Zu jedem dieser Architekturelemente ist eine kurze Leistungsbeschreibung zu verfassen und die entstehenden Schnittstellen sind zu identifizieren. In der Schnittstellenbeschreibung muß dann das Zusammenspiel der SW-Module/Prozesse, SW-Komponenten und Datenbanken spezifiziert werden. Diese Informationen dienen als Ausgangspunkt für den SW-Feinentwurf.

    Die bereits auf System-Ebene begonnenen Betriebsinformationen (Anwendungshandbuch, Diagnosehandbuch, Betriebshandbuch, Sonstige Einsatzinformationen) sind hier um Angaben für die betrachtete SW-Einheit zu ergänzen.

    Rollen

    Rolle Beteilungsarten
    SW-Entwickler verantwortlich (SE4.1-SW, SE4.2-SW, SE4.3-SW)
    Technischer Autor mitwirkend (SE4.1-SW, SE4.3-SW)

    Teilaktivitäten

    SE4.1 - SW-Architektur entwerfen,
    SE4.2 - SW-interne und -externe Schnittstellen entwerfen,
    SE4.3 - SW-Integration spezifizieren

    Werkzeuganforderungen

    Im Bearbeitung

    Externe Normen

    Im Bearbeitung

    Verknüpfungen mit der V-Modell Mailingliste

    Mail 0524 - Mehrere Fragen zum V-Modell (524)
    Mail 0139 - Re: V-Modell 97 (139)
    Mail 0134 - V-Modell 97 (134)


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

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster