Strukturierung des XS-Modells

Einführung zum Handbuch

Das XS Vorgehensmodell für sicherheitsrelevante Systeme ist eine Spezialisierung und Vereinfachung des V-Modells [ V-Modell Umdruck 250 ] [ V-Modell Browser ].

Viele der Erkenntnisse dieses Berichtes stammen aus dem ESPRESS-Projekt. Die verfolgte Methodologie im ESPRESS-Projekt ist allerdings unterschiedlich zu der hier beschriebenen.

Das XS-Modell benutzt die Terminologie (Wortschatz) des System-Entwicklers, und nur an den Stellen, wo der Entwickler keinen eigenen Begriff hat, wird die Terminologie des V-Modells benutzt. Um den Zusammenhang zum Original-V-Modell nachvollziehen zu können, werden die Texte aus dem V-Modell mit dieser Farbe angegeben. Die Stellen, wo etwas gestrichen wurde, werden so <> markiert.

Das XS-Modell führt neue Verfahren in die Submodelle Softwareentwicklung (SWE) und Qualitätssicherung (QS) aus dem V-Modell ein. Die anderen Submodelle (Projektmanagement PM und Konfigurationsmanagement KM) werden nicht extra behandelt und können direkt aus dem Original V-Modell übernommen werden.

Struktur der Beschreibung des XS-Modells (Bedienungsanleitung)

Die Modellbeschreibung besteht aus dem Vorgehensmodell mit sienen Aktivitäten, Produkte und Beziehungen.

Die Texte sind durch Hypertext-Links stark verknüpft. Beim Lesen des Modells können Sie die passende Experimente holen und lessen. Später kann ein Entwicklungsassisten (Werkzeug) den Entwickler durch die Beschreibung führen.

Um die Komponenten einfach identifizieren zu können und um die Beziehungen zwischen Submodellen deutlich darzustellen, wurden die Submodelle mit verschiedenen Farben gezeichnet: SWE Hellblau, QS Gold und Extern grün. Manche Aktivitäten, Produkte und Beziehungen, die das XS-Modell benötigt, aber im V-Modell nicht vorgesehen sind, wurden hinzugefügt. Um sie deutlich zu machen, wurden sie rot gezeichnet.

Aktivitäten sind eckige Kästchen. Produkte sind gerundete Kästchen. Normalerweise kommunizieren die Aktivitäten formal durch Produkte oder geschriebene Dokumente (Fall A). Oft ist eine unbürokratische Kommunikation ausreichend (Fall B). Hier wird von Aktivität direkt zu Aktivität (Person - Person) mündlich kommuniziert.

XS-Modell

Ziel von XS ist die Entwicklung von Software für sichere Systeme. Dennoch, um Systemsicherheit garantieren zu können, muß das gesamte System mit seinen nicht-DV-Anteilen sowie Hardware mitspezifiziert werden. Die Integration endet beim Softwareanteil, dennoch werden Test und Verifikationsprozeduren hin bis zum System erstellt. Jede Ebene bestimmt als erstes die entsprechenden Anforderungen. Danach wird die Architektur definiert, indem eine Aufteilung stattfindet. Die kleineren Teile werden an die nächste Ebene zur Implementierung weitergeleitet. Wenn die verschiedenen fertigen Teile zurück von den unteren Ebenen kommen, werden sie zusammen integriert und weiter nach oben weitergegeben.

Die Systemebene teilt (später integriert) das ganze System in mehrere Segmente auf, die DV-Anteile haben und andere, die keine DV-Anteile haben. Die Segmentebene kümmert sich nur um die Segmente mit DV-Anteilen und teilt (später integriert) sie in mehrere Konfigurationseinheiten auf. Einige davon bestehen aus Software (SW) und andere aus Hardware (HW). Die Modulebene kümmert sich nur um die SW-Konfigurationseinheiten. Sie werden in Module aufgeteilt/integriert.

Submodelle, Aktivitäten und Produkte

Das XS-Modell führt neue Verfahren in den Submodellen Softwareentwicklung (SWE) und Qualitätssicherung (QS) ein. Qualität bedeutet bei XS Sicherheit. Das Softwareentwicklungssubmodell macht Analyse, Entwurf, Realisierung und Integration des Projekts. Das Qualitätssicherungs-Submodell kontrolliert die Sicherheitsaspekte aller sicherheitsrelevanten Produkte. Sicherheit ist ein Zusammenspiel von SWE und QS:

Jedes Submodell besteht aus vielen Aktivitäten und Produkten. Es wird eine logische Sequenz von Aktivitäten verfolgt, die auch Aktivitäten, die parallel durchgeführt werden können enthält. Die Steuerung der Parallelität der Aktivitäten erfolgt nach dem Modell der Datenfluß-Graphen. Eine Aktivität startet, sobald sie selbst geplant ist und alle benötigten Produkte (Eingaben) vorhanden und akzeptiert sind. Eine Aktivität endet, wenn alle ihre Ergebnisse (Ausgaben) akzeptiert sind. Daher können viele Aktivitäten parallel laufen.

Die Produkte werden von Aktivitäten erzeugt, weiterbearbeitet und geprüft. Jedes Produkte hat einen Zustand:

last update 14.11.96: sergio Montenegro email: sergio@first.gmd.de