Schlagworte wie "ingenieurmaessige SW-Entwicklung" werden taeglich zitiert. Wie detailliert und auf welcher Ebene in einem Projekt Standards vorgegeben werden sollen, ist dagegen oft ungeklaert. Als Massstab muss hier gelten, was die Standardisierungen bezueglich folgender Ziele bringen koennen:

- Eindaemmung der SW-Kosten ueber den Lebenszyklus hinaus,

- Verbesserung beziehungsweise Gewaehrleistung der SW-Qualitaet,

- Optimierung der Kommunikation zwischen Auftraggeber und Auftragnehmer.

Das Standardisierungskonzept der deutschen Bundesbehoerden verfolgt diese Zielsetzung durch Regelungen in den Bereichen Vorgehensweise, anzuwendende Methoden und funktionale Anforderungen an die eingesetzten Werkzeuge.

Vorgabe von Aktivitaeten und Produkten

Bei der Festlegung der Vorgehensweise wird die Frage geklaert: "Was ist zu tun?" Es wird definiert, welche Taetigkeiten im Verlauf der Software-Entwicklung durchzufuehren und welche Ergebnisse dabei zu produzieren sind.

Die Methodenfrage betrifft die Art und Weise, wie die vorgeschriebenen Taetigkeiten durchgefuehrt werden und welche Darstellungsmittel zu verwenden sind. Schliesslich ist bei den Werkzeuganforderungen zu entscheiden, welche funktionalen Eigenschaften die Tools aufweisen muessen, die bei der Software-Entwicklung eingesetzt werden sollen.

Auf allen drei Ebenen werden die Taetigkeitsbereiche Software- Erstellung, Qualitaetssicherung, Konfigurations- und Projekt- Management unterschieden. Die Bundesbehoerden haben fuer jeden der drei Bereiche Entwicklungsstandards erarbeitet. Im Mittelpunkt dieses Artikels steht das Vorgehensmodell (V-Modell) als Standard der ersten Ebene.

Das V-Modell regelt die Software-Entwicklung mittels einer einheitlichen und verbindlichen Vorgabe von Aktivitaeten (Taetigkeiten) und Produkten (Ergebnissen), die bei der Software- Erstellung und den begleitenden Taetigkeiten fuer Qualitaetssicherung, Konfigurations- und Projekt-Management zu beruecksichtigen sind. Zu jeder Aktivitaet gibt es eine Beschreibung als Arbeitsanleitung und zu jedem Entwicklungsdokument steht eine Beschreibung zur Verfuegung, die seine Inhalte festlegt.

Das V-Modell wurde unter mehreren Anwendungsaspekten entwickelt. Es dient unter anderem als

- Vertragsgrundlage, indem es den Lieferumfang einer Software und die Vollstaendigkeit der Dokumentation definiert;

- Arbeitsanleitung oder Leitfaden bei der Software-Entwicklung, indem es die Aktivitaeten und Entwicklungsdokumente beschreibt sowie als

- Kommunikationsbasis zwischen Auftraggeber, Nutzer, Auftragnehmer und Entwicklern, indem die Entwicklungsdokumente beschrieben und ein Glossar bereitgestellt werden.

Das V-Modell hat urspruenglich im Auftrag des Bundesministeriums fuer Verteidigung (BMVg) sowie in Zusammenarbeit mit dem Bundesamt fuer Wehrtechnik und Beschaffung (BWB) in Koblenz die Industrieanlagen-Betriebsgesellschaft mbH (IABG) in Ottobrunn bei Muenchen erarbeitet. Das Bundesministerium des Innern (BMI) uebernahm das Modell im Sommer 1992 fuer die zivile Verwaltung. Damit existiert ein einheitlicher Standard fuer den gesamten oeffentlichen Bereich.

Die im V-Modell aufgestellten Regeln sind streng organisationsneutral gehalten. Sie beschraenken sich ausschliesslich auf den technischen Entwicklungsgang. Deshalb ist das V-Modell nicht nur fuer die oeffentliche Verwaltung, sondern auch fuer Industrieunternehmen als Entwicklungsstandard geeignet.

Der Einsatz im industriellen Bereich wird wesentlich dadurch erleichtert, dass die Anwendung keinen Nutzungsrechten unterliegt. Das Modell ist nicht proprietaer und nicht kopiergeschuetzt, das heisst, jeder Interessent kann es ohne lizenzrechtliche Verpflichtungen fuer den eigenen Bedarf beliebig kopieren und einsetzen.

Fuer internationale Projekte wurde das V-Modell ins Englische uebersetzt. Diese Ausfuehrung ist auch Gegenstand des EG-Projekts Euromethod, das seit 1989 mit dem Ziel der DV-technischen Methodensichtung und -harmonisierung laeuft (Siehe auch CW Nr.52 vom 25. Dezember 1992, Seite 28: "Software-Entwicklungsverfahren lassen sich einheitlich beschreiben"). In den EG-Gremien ist Deutschland durch das Bundesministerium des Innern vertreten. In Anbetracht der eigenen Erfahrungen hat das BMI das V-Modell als deutschen Standardisierungsbeitrag eingebracht.

Das Vorgehensmodell beruecksichtigt

- die Erfordernisse, die Software nach den IT-Sicherheitskriterien zertifizierbar machen;

- die Besonderheiten detaillierter Informationsmodellierung, wie sie bei der Entwicklung von Informationssystemen erforderlich ist;

- die Wechselwirkungen zwischen Software und Verfahrensdefinition, wie sie bei der Entwicklung von Informationssystemen im Vordergrund steht;

- die Besonderheiten kritischer Realzeitsoftware, wie sie insbesondere in Embedded-Computer-Systems- (ECS) Anwendungen zum Einsatz kommt sowie

- die Wechselwirkungen zwischen Software und Hardware bei der Entwicklung von ECS-Software.

Beim Einsatz im wehrtechnischen Bereich erfuellt das V-Modell als SW-Entwicklungs- und Qualitaetssicherungsstandard die Forderungen der Nato-Standards AQAP-13 beziehungsweise AQAP-150. Ferner entspricht es im gesamten oeffentlichen Bereich den wesentlichen technischen "Mindestanforderungen der Rechnungshoefe des Bundes und der Laender zum Einsatz der Informationstechnik". Im industriellen Umfeld wird es den technischen Forderungen der Normen aus der Reihe ISO 9000 (in der softwarebezogenen Interpretation der ISO 9000-3)gerecht und ist damit eine Hilfestellung und Grundlage bei ISO-9000-Zertifizierungen.

Das V-Modell enthaelt auch Regelungen zur Entwicklung sicherheitskritischer Software. "Sicherheitskritisch" bezieht sich dabei sowohl auf Aspekte, die im Englischen mit dem Begriff "Safety" bezeichnet werden, als auch auf die Vertrauenswuerdigkeit ("Security"). Es gewaehrleistet die Erfuellung der derzeit geltenden nationalen (ITSK) und europaeischen (ITSEC) Sicherheitskriterien. Die Zertifizierung der so entwickelten Software wird dadurch erleichtert.

Durch die Einberufung besonderer Fachgruppen wurden sowohl Anwender aus dem industriellen als auch dem oeffentlichen Bereich in den Entwicklungs- und Pflegeprozess eingebunden. Die Nutzer erhalten durch eine etwa jaehrlich tagende Aenderungskonferenz mit Industrie- und Behoerdenvertretern den erforderlichen Einfluss auf Pflege und Aenderung des V-Modells. Die Konferenz ist nach ihrer Geschaeftsordnung verpflichtet, saemtliche Aenderungsantraege sorgfaeltig zu bearbeiten.

Neben dem eigentlichen Regelungsteil enthaelt das V-Modell drei Anlagen:

- "Erlaeuterungen zur Anwendung des V-Modells": Dieser Teil bietet Hintergrundinformationen und soll die Einarbeitung erleichtern.

- "Erlaeuterungen zu den Produkten": Fuer jedes im V-Modell definierte Produkt (Software, Dokument) werden detaillierte Erlaeuterungen zum geforderten Inhalt gegeben.

- "Behoerdenspezifische Ergaenzungen": Diese Anlage unterscheidet sich je nach Einsatz im wehrtechnischen oder im zivilen Bereich. Dargestellt wird, wie das Modell in Verbindung mit den jeweils geltenden Vorschriften anzuwenden ist (zum Beispiel globales Phasenkonzept im wehrtechnischen, "Besondere Vertragsbedingungen des Bundes- und der Laender (BVB)" im zivilen Bereich).

Das Vorgehensmodell ist projektunabhaengig und kann auf verschiedenen Gebieten zum Einsatz kommen. Um es fuer ein konkretes Vorhaben zu nutzen, muss entschieden werden, welche Aktivitaeten und Entwicklungsdokumente aus sachlichen Gruenden erforderlich sind. In jedem Fall sollte eine uebermaessige Papierflut, aber auch das Fehlen wichtiger Informationen verhindert werden. Die projektspezifische Anpassung wird Tailoring genannt.

Das Tailoring erfolgt in zwei Stufen:

1. Beim "ausschreibungsrelevanten Tailoring" vor Vertragsabschluss und Beginn des eigentlichen Projekts, ist eine Auswahl an Aktivitaeten und Produkten vorzunehmen. Ausserdem werden Bedingungen festgelegt, unter denen einzelne zu Anfang als erforderlich eingestuften Aktivitaeten im Laufe des Projektes entfallen koennen. Die entstehende Teilmenge des V-Modells wird zusammen mit weiteren Vereinbarungen im Projekthandbuch fixiert, das einen wesentlichen Vertragsbestandteil ausmacht. Das ausschreibungsrelevante Tailoring ist auch dann von Bedeutung, wenn ein Projekt nicht extern vergeben, sondern in Eigenentwicklung durchgefuehrt wird.

2. Im "technischen Tailoring" werden die im Projekthandbuch festgeschriebenen Ausfuehrungsbedingungen ausgewertet. Man entscheidet, welche der im Projekthandbuch enthaltenen Aktivitaeten tatsaechlich erfolgen sollen. Dies geschieht kontinuierlich waehrend der Projektabwicklung.

Damit alle Angebote hinsichtlich Durchfuehrungsart und Dokumentation vergleichbar sind, erfolgt die projektspezifische Anpassung des V-Modells bei externer Auftragsvergabe bereits vor der Ausschreibung. Das dabei erstellte Projekthandbuch definiert die vom Auftragnehmer zu erbringende Leistung. Damit wird das Projekthandbuch zur einheitlichen Handlungsgrundlage fuer alle Projektbeteiligten.

Da in der oeffentlichen und der industriellen Praxis bestimmte Projekteigenschaften fuer weite Anwendungsgebiete konstant sind, werden fuer haeufig auftretende Vorhaben im Rahmen eines Vor- Tailoring einfach anzuwendende Aktivitaeten- und Produktauswahl- Empfehlungen auf Formblaettern gegeben. Damit laesst sich das Tailoring erheblich vereinfachen.

Das Vorgehensmodell legt verschiedene Rollen fest, die auf den fuer Projektaufgaben noetigen Erfahrungen und Kenntnissen basieren. So ist die Unabhaengigkeit von organisatorischen und projektspezifischen Randbedingungen zu erreichen. Die Zuordnung von Rollen zu Aktivitaeten des Vorgehensmodells wird fuer jedes der Submodelle Software-Erstellung, Qualitaetssicherung, Konfigurations- und Projekt-Management durch eine Matrix beschrieben, wobei einer Aktivitaet mehrere Rollen zugeordnet sein koennen. Diese Regelungen machen keine Vorschriften darueber, welche organisatorische Einheiten oder Personen welche Rollen uebernehmen. Diese Zuordnung muss vielmehr jeweils bei Projektbeginn individuell erfolgen.

Das V-Modell laesst sich mit Hilfe von Werkzeugen leichter anwenden. Solche Tools sollten mindestens das Tailoring, die Begleitung durch die Projektaktivitaeten und die Generierung der Dokumente erleichtern.

Durch die starke Verbreitung des Modells gehen immer mehr Werkzeughersteller dazu ueber, dessen Regelungen in ihre Werkzeuge zu integrieren.

Die genannten Submodelle des V-Modells, naemlich Software- Erstellung (SWE), Qualitaetssicherung (QS), Konfigurations- (KM) und Projekt-Management (PM), sind eng miteinander vernetzt und beeinflussen sich ueber den Austausch von Produkten gegenseitig. Das Projekt-Management plant, kontrolliert und informiert die anderen drei Submodelle. Die Qualitaetssicherung gibt Qualitaetsanforderungen, Prueffaelle und -kriterien vor und kontrolliert sowohl die Produkte als auch die Einhaltung der Standards. Das Konfigurationsmodell verwaltet die in den Submodellen erzeugten Produkte (vgl. Abbildung 1).

Das V-Modell stellt die Schnittstellen zwischen den Submodellen SWE und QS ausfuehrlich dar. Besondere Bedeutung wird der Kritikalitaet von Software beigemessen, also der Zuverlaessigkeit, Sicherheit oder allgemein der Wichtigkeit bestimmter Softwarebestandteile. Das Modell schlaegt Mechanismen vor, wie der Erstellungs- und der Pruefaufwand den unterschiedlichen Kritikalitaetsstufen der Software angepasst werden kann.

Im Submodell SWE sind alle unmittelbar zur SW-Erstellung noetigen Aktivitaeten und die jeweiligen Entwicklungsdokumente zusammengefasst. Folgende Aktivitaeten werden unterschieden:

- In der Phase Systemanforderungs-Analyse und -Entwurf (SWE 1) werden die Anforderungen an das zu erstellende System und seine Umgebung beschrieben. Hier sind die Bedrohungs- und Risikoanalyse, das Sicherheitskonzept, ein fachliches Modell fuer Funktionen, Daten und Objekte sowie die Strukturierung des Systems in Subsysteme und Segmente zu erarbeiten.

- Die Beschreibung der Anforderungen an ein in SWE 1 konzipiertes DV-Segment und seine Umgebung ist Gegenstand der Phase DV- Anforderungsanalyse und -entwurf (SWE 2). Hier wird ein Sicherheitsmodell entwickelt, das fachliche Modell verfeinert und das gesamte Segment in seine Software- und Hardwarekonfigurations- Einheiten (SWKE und HWKE) unterteilt.

- Die Formulierung der Anforderungen an eine in SWE 2 konzipierte SWKE und ihre Umgebung ist Aufgabe der SW-Anforderungsanalyse (SWE 3).

- Ein Grobentwurf (SWE 4) entsteht aus der Strukturierung der SWKE in Softwarekomponenten, Module und Datenbanken. Hier erfolgt auch - sofern relevant - die Spezifikation der Schnittstellen und des Zusammenspiels zwischen Komponenten, Modulen und Datenbanken.

- Der Feinentwurf (SWE 5) beinhaltet die Beschreibung der Komponenten, Module und Datenbanken hinsichtlich der softwaretechnischen Realisierung ihrer Funktionen, der Datenhaltung und Fehlerbehandlung bis hin zu einer Programmiervorgabe.

- In der Implementierungsphase (SWE 6) werden die Programmiervorgaben in Anweisungen der vorgegebenen Programmiersprache umgesetzt. Hier erfolgt zudem die Pruefung des erzielten Codes sowie eventuell die Realisierung von Datenbanken.

- Die Integration von Modulen und Komponenten sowie die von Komponenten mit der SWKE ist Gegenstand der SW-Integration (SWE 7).

- In der DV-Integration (SWE 8) werden die verschiedenen Software- und Hardwarebestandteile (SWKE und HWKEzu einem DV-Segment verschmolzen.

- Die Systemintegration (SWE 9) schliesslich sieht die Integration der Subsysteme (falls vorhanden) vor. (Einen Ueberblick ueber das Submodell Software-Erstellung gibt Abbildung 2).

Submodell Qualitaetssicherung

Die Aufgaben und Funktionen der Qualitaetssicherung innerhalb des Software-Entwicklungsprozesses regelt das Submodell Qualitaetssicherung. Im Gegensatz zu den informellen Pruefungen im Submodell SWE wird hier im Rahmen einer Nachweisfuehrung die Erfuellung vorgegebener Anforderungen gezeigt. Diese Anforderungen finden sich in den Dokumenten System-, DV- und Software-Anforderungen des Submodells SWE.

Die Regelungen beruehren jedoch wie bei den anderen Submodellen in keiner Weise organisatorische Festlegungen. Das Submodell umfasst die Hauptaktivitaeten QS-Initialisierung, Prozesspruefung von Aktivitaeten (nach DIN 55 350), Vorbereiten der Produktpruefung, Durchfuehrungsentscheidung, Pruefung des Fertigproduktes und QS- Berichtswesen (vgl. Abbildung 3).

Das Submodell Konfigurations-Management (KM) stellt sicher, dass Produkte eindeutig identifizierbar sind. Es garantiert, dass Zusammenhaenge und Unterschiede zwischen verschiedenen Versionen einer Konfiguration erkennbar bleiben und Produktaenderungen nur kontrolliert durchgefuehrt werden koennen.

Das Submodell KM beinhaltet die Hauptaktivitaeten KM-Initialisierung, Konfigurationsverwaltung, Aenderungs-Management, Datensicherung und KM-Berichtswesen.

Der Bereich Projekt-Management schliesslich regelt die Aufgaben und Funktionen des technischen PM innerhalb des Software- Entwicklungsprozesses. Die Regelungen beruehren in keiner Weise organisatorische Festlegungen und sind abzugrenzen von den Funktionen des System-Managements. Die hier festgelegten Aufgaben umfassen unter anderem die Planung, Kontrolle und Steuerung projektinterner Taetigkeiten sowie die Definition von Schnittstellen zu projektexternen Einheiten.

Das Submodell PM ist in die Hauptaktivitaeten Projektinitialisierung, -begleitung und - abschluss unterteilt.

(wird fortgesetzt)

*Klaus Ploegert ist bei der Industrieanlagen-Betriebsgesellschaft zustaendig fuer Marketing und Vertrieb des Vorgehensmodells.

Das V-Modell kann bei folgenden Stellen bezogen werden:

- Bundesministerium fuer Verteidigung - FueS I 1, Postfach 13 28, 5300 Bonn 1 (fuer den wehrtechnischen Bereich);

- Bundesanzeiger-Verlagsgesellschaft mbH, Postfach 10 80 06, 5000 Koeln 1 (Schriftenreihe der KBSt, Band 27/1 und 27/2);

- Industrieanlagen-Betriebsgesellschaft mbH, Abt. ITE, Einsteinstr. 20, 8012 Ottobrunn (wehrtechnisch und zivil).

Abb. 1: Beispiel fuer den Aktivitaeten- und Produktfluss ueber die vier Submodelle Software-Erstellung, Qualitaetssicherung, Konfigurations- und Projektmanagement

Abb. 2: Aktivitaeten und Produkte im Submodell Software-Erstellung

Abb. 3: Aktivitaeten und Produkte im Submodell Qualitaetssicherung