Copyright: Online-Hilfe erstellt von IABG (Bonn)


Übersicht 'Allgemeiner Umdruck Nr. 250'
Entwicklungsstandard
für IT-Systeme
des Bundes

Vorgehensmodell

Juni 1997

Regelungsteil (Teil 1)

Behördenspezifische Erweiterungen (Teil 2)

Handbuchsammlung (Teil 3)


Übersicht 'Allgemeiner Umdruck Nr. 250/1'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/1'   (Regelungsteil)

Vorbemerkungen

1	Zielsetzung und Anwendung des Vorgehensmodells

2	Einführung in das V-Modell

3	Allgemeine Regelungen

4	Regelungen Submodell Systemerstellung

5	Regelungen Submodell Qualitätssicherung

6	Regelungen Submodell Konfigurationsmanagement

7	Regelungen Submodell Projektmanagement

8	Produktmuster

Anhang

A	Definitionen

B	Verzeichnisse


Übersicht 'Allgemeiner Umdruck Nr. 250/2'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/2'   (Behördenspezifische Ergänzungen)

Vorbemerkungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

2	V-Modell und AU 220

3	Erstellung von Prototypen

4	Überleitungsstrategie

5	V-Modell in der Nutzung

6	Internationale Vorhaben

7	Zuordnung V-Modell zu STANAG 4159

Anhang

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

B	SWPÄ

C	Definitionen

D	Verzeichnisse


Übersicht 'Allgemeiner Umdruck Nr. 250/3'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (Handbuchsammlung)

Vorbemerkungen

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

HW	Hardwareerstellung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

OOS	Berücksichtigung objektorientierter Sprachen

R	Rollenkonzept im V-Modell

RE	Reverse Engineering

SEC	Anwendung des V-Modells und ITSEC

SI	Sicherheit und Kritikalität

SZ	Szenarien

T	Tailoring und projektspezifisches V-Modell

UMF	Einordnung des V-Modells in sein Umfeld


'Allgemeiner Umdruck Nr. 250/1'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/1'   (Regelungsteil)

Vorbemerkungen

1	Zielsetzung und Anwendung des Vorgehensmodells

1.1	Zielsetzung

1.2	Anwendung des V-Modells

1.3	Systembegriff im V-Modell

1.4	Anpassung an die konkrete Projektsituation

1.5	Erfüllung von QS-Vorschriften

1.6	Erfüllung von Sicherheitskriterien

2	Einführung in das V-Modell

2.1	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

2.2	Randbedingungen zur IT-Systemerstellung

2.3	Inhalt und Darstellungsmittel

2.3.1	Aktivitäten und Produkte

2.3.2	Produktzustände

2.3.3	Aktivitätenschema

2.3.3.1	Abschnitt ”Produktfluß”

2.3.3.2	Abschnitt ”Abwicklung”

2.3.3.3	Empfehlungen und Erläuterungen

2.3.4	Produktmuster

2.3.5	Submodelle

3	Allgemeine Regelungen

3.1	Projektspezifisches V-Modell und Tailoring

3.2	Projektorganisation und Rollen

3.3	Anwendung der Szenarien

3.4	Operative Module

3.5	Behandlung fortzuschreibender Produkte

4	Regelungen Submodell Systemerstellung

4.1	Überblick

4.2	Die Aktivitäten des Submodells SE

SE 1:	System-Anforderungsanalyse

SE 1.1:	Ist-Aufnahme/-Analyse durchführen

SE 1.2:	Anwendungssystem beschreiben

SE 1.3:	Kritikalität und Anforderungen an die Qualität definieren

SE 1.4:	Randbedingungen definieren

SE 1.5:	System fachlich strukturieren

SE 1.6:	Bedrohung und Risiko analysieren 5)

SE 1.7:	Forderungscontrolling durchführen

SE 1.8:	Software-Pflege- und Änderungs-Konzept erstellen

SE 2:	System-Entwurf

SE 2.1:	System technisch entwerfen

SE 2.2:	Wirksamkeitsanalyse durchführen

SE 2.3:	Realisierbarkeit untersuchen

SE 2.4:	Anwenderforderungen zuordnen

SE 2.5:	Schnittstellen beschreiben

SE 2.6:	System-Integration spezifizieren

SE 3:	SW-/HW-Anforderungsanalyse

SE 3.1:	Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren

SE 3.2:	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren

SE 3.3:	Anforderungen an die Funktionalität definieren

SE 3.4:	Anforderungen an die Qualität der SW-/HW-Einheit definieren

SE 3.5:	Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren

SE 4-SW:	SW-Grobentwurf

SE 4.1-SW:	SW-Architektur entwerfen

SE 4.2-SW:	SW-interne und -externe Schnittstellen entwerfen

SE 4.3-SW:	SW-Integration spezifizieren

SE 5-SW:	SW-Feinentwurf

SE 5.1-SW:	SW-Komponente/-Modul/Datenbank beschreiben

SE 5.2-SW:	Betriebsmittel- und Zeitbedarf analysieren

SE 6-SW:	SW-Implementierung

SE 6.1-SW:	SW-Module codieren

SE 6.2-SW:	Datenbank realisieren

SE 6.3-SW:	Selbstprüfung des SW-Moduls/der Datenbank durchführen

SE 7-SW:	SW-Integration

SE 7.1-SW:	Zur SW-Komponente integrieren

SE 7.2-SW:	Selbstprüfung der SW-Komponente durchführen

SE 7.3-SW:	Zur SW-Einheit integrieren

SE 7.4-SW:	Selbstprüfung der SW-Einheit durchführen

SE 8:	System-Integration

SE 8.1:	Zum System integrieren

SE 8.2:	Selbstprüfung des Systems durchführen

SE 8.3:	Bereitstellung des Produktes

SE 9:	Überleitung in die Nutzung

SE 9.1:	Beitrag zur Einführungsunterstützung leisten

SE 9.2:	System installieren

SE 9.3:	Inbetriebnahme

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.1	Konstruktive Maßnahmen

5.1.2	Analytische Maßnahmen

5.1.3	Rollenverteilung bei der Durchführung von Prüfaktivitäten

5.1.4	Klassifizierung der QS-Aktivitäten

5.1.5	Ausprägungen von Prüfaktivitäten

5.2	Die Aktivitäten des Submodells QS

QS 1:	QS-Initialisierung

QS 1.1:	QS-Plan erstellen

QS 1.2:	Prüfplan erstellen

QS 2:	Prüfungsvorbereitung

QS 2.1:	Prüfmethoden und -kriterien festlegen

QS 2.2:	Prüfumgebung definieren

QS 2.3:	Prüffälle festlegen

QS 2.4:	Prüfprozedur erstellen

QS 3:	Prozeßprüfung von Aktivitäten

QS 4:	Produktprüfung

QS 4.1:	Prüfbarkeit feststellen

QS 4.2:	Produkt inhaltlich prüfen

QS 5:	QS-Berichtswesen

6	Regelungen Submodell Konfigurationsmanagement

6.1	Überblick

6.2	Die Aktivitäten des Submodells KM

KM 1:	KM-Planung

KM 1.1:	KM-Plan erstellen

KM 1.2:	KM einrichten

KM 2:	Produkt- und Konfigurationsverwaltung

KM 2.1:	Produkt initialisieren

KM 2.2:	Konfiguration initialisieren

KM 2.3:	Produkt verwalten

KM 2.4:	Konfiguration fortschreiben

KM 2.5:	Zugriffsrechte verwalten

KM 3:	Änderungsmanagement (Konfigurationssteuerung)

KM 3.1:	Änderung bewerten

KM 3.2:	Änderungsvorgehen entscheiden und Änderung einleiten

KM 3.3:	Änderung abschließen

KM 4:	KM-Dienste

KM 4.1:	Daten administrieren

KM 4.2:	SW-/HW-Produkte katalogisieren

KM 4.3:	Schnittstellen koordinieren

KM 4.4:	Ergebnisse sichern

KM 4.5:	KM-Dokumentation führen

KM 4.6:	Release-Management durchführen

KM 4.7:	Projekthistorie führen

7	Regelungen Submodell Projektmanagement

7.1	Überblick

7.2	Die Aktivitäten des Submodells PM

PM 1:	Projektinitialisierung

PM 1.1:	Projekt einrichten

PM 1.2:	Projektkriterien und Entwicklungsstrategie festlegen

PM 1.3:	Projektspezifisches V-Modell erstellen

PM 1.4:	Toolset-Management durchführen

PM 1.5:	Grobplan erstellen

PM 2:	Vergabe/Beschaffung

PM 3:	Auftragnehmer-Management

PM 4:	Feinplanung

PM 5:	Kosten-/Nutzenanalyse

PM 6:	Durchführungsentscheidung

PM 7:	Risikomanagement

PM 8:	Projektkontrolle und -steuerung

PM 9:	Informationsdienst/Berichtswesen

PM 10:	Schulung/Einarbeitung

PM 11:	Bereitstellung der Ressourcen

PM 12:	Vergabe von Arbeitsaufträgen

PM 13:	Einweisung der Mitarbeiter

PM 14:	Projektabschluß

8	Produktmuster

8.1	Allgemeine Erläuterungen

8.1.1	Kapitelnumerierung mit Präfix

8.1.2	Seitenlayout

8.1.3	Gliederungspunkt ”1 Allgemeines”

8.2	Produkte des Submodells SE

8.2.1	Anwenderforderungen (AFo_)

8.2.2	Systemarchitektur (SysArc_)

8.2.3	Technische Anforderungen (TAnf_)

8.2.4	Schnittstellenübersicht (SSÜb_)

8.2.5	Schnittstellenbeschreibung (SSB_)

8.2.6	Integrationsplan (IntPl_)

8.2.7	SWPÄ-Konzept (SWPÄK_)

8.2.8	SW-Produkte

8.2.8.1	SW-Architektur (SwArc_)

8.2.8.2	SW-Entwurf (SwEnt_)

8.2.8.3	Datenkatalog (DatK_)

8.2.9	Implementierungsdokumente (ImplD_)

8.2.10	Betriebsinformationen

8.2.10.1	Informationen zum Anwendungshandbuch (AHb_)

8.2.10.2	Informationen zum Diagnosehandbuch (DiagHb_)

8.2.10.3	Informationen zum Betriebshandbuch (BetrHb_)

8.2.10.4	Sonstige Einsatzinformationen (EinInf_)

8.3	Produkte des Submodells QS

8.3.1	QS-Plan (QPl_)

8.3.2	Prüfplan (PrPl_)

8.3.3	Prüfspezifikation (PrSpez_)

8.3.4	Prüfprozedur (PrProz_)

8.3.5	Prüfprotokoll (PrProt_)

8.4	Produkte des Submodells KM

8.4.1	KM-Plan (KPl_)

8.4.2	Konfigurations-Identifikationsdokument (KID_)

8.4.3	Änderungsformulare

8.4.3.1	Änderungsantrag/Problemmeldung (ÄA_)

8.4.3.2	Änderungsvorschlag (ÄVor_)

8.4.3.3	Änderungsauftrag (ÄAuf_)

8.4.3.4	Änderungsmitteilung (ÄMit_)

8.4.3.5	Änderungsstatusliste (ÄStat_)

8.4.4	Projekthistorie (PHis_)

8.5	Produkte des Submodells PM

8.5.1	Projekthandbuch (PHb_)

8.5.2	Projektplan (PPl_)

8.5.3	Angebotsbewertung (AnBew_)

8.5.4	Kosten-/Nutzenanalyse (KNA_)

8.5.5	Arbeitsauftrag (ArbAuf_)

8.5.6	Berichtsdokumente

8.5.6.1	Protokoll (Prot_)

8.5.6.2	Sachstandsbericht (SStB_)

8.5.6.3	Projektabschlußbericht (PAB_)

8.5.6.4	Sachbericht (SaB_)

8.5.6.5	Aktennotiz (AktNo_)

8.5.6.6	Interne Mitteilung (IntMit_)

8.5.6.7	Einladung (Einl_)

Anhang


'Allgemeiner Umdruck Nr. 250/1 - Anhang'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/1'   (Regelungsteil - Anhang)

A	Definitionen

B	Verzeichnisse

B.1	Abkürzungsverzeichnis

B.2	Abbildungsverzeichnis

B.3	Tabellenverzeichnis

B.4	Literaturverzeichnis

B.5	Stichwortverzeichnis


'Allgemeiner Umdruck Nr. 250/2'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/2'   (Behördenspezifische Ergänzungen)

Vorbemerkungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.1	Wann ist das V-Modell anzuwenden?

1.2	Anwendung des V-Modells bei DV-Vorhaben

1.3	Anwendung des V-Modells im Rahmen des EBMat

1.3.1	Entwicklung von DV/IT-Anteilen im Kontext der Systementwicklung

1.3.2	Erfordernis einer übergeordneten Einheitlichkeit

1.4	Zuordnung der Rollen des V-Modells zu den Aufgabenträgern im Amtsbereich

1.5	Vergabevorbereitung, Vertragsabschluß und Vertragsabwicklung

2	V-Modell und AU 220

2.1	Zusammenhang zwischen V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.1	Initiierung eines Vorhabens

2.2.2	Definition der Anforderungen und der technischen Struktur des Systems

2.2.3	Forderungscontrolling

2.2.4	Prozeßplanung

2.2.5	Qualitätssicherung/Konfigurationsmanagement

2.3	Vom Vorhabenmanager zu berücksichtigende Schnittstellen

2.3.1	Initiierung des Vorhabens in der Definitionsphase

2.3.2	Behandlung der Anforderungen

2.3.3	Qualitätssicherung/Konfigurationsmanagement

2.3.4	Nutzung

2.4	Phasenunabhängige Schnittstellen

2.4.1	Berücksichtigung technischer Produkte des V-Modells bei der Erstellung der Stufenentscheidungen/Phasendokumente

2.4.2	Entscheidungsdokumentation

2.4.3	Vorhabenplanung und -steuerung

3	Erstellung von Prototypen

4	Überleitungsstrategie

4.1	Entscheidungsprozeß

4.2	Durchführung der Überleitung von V-Modell August 1992 nach V-Modell Juni 1997

4.3	Überleitung eines Produkts

5	V-Modell in der Nutzung

5.1	BMVg-spezifische Ausprägung des SWPÄ-Konzepts

5.2	Planung und Durchführung von SWPÄ-Maßnahmen

5.3	Operatives Modul ”Pflege/Änderung”

6	Internationale Vorhaben

6.1	AU 253: Zuordnungshandbuch GAM-T17 (V2) - V-Modell

6.1.1	Ziel des Einsatzes des AU 253

6.1.2	Einsatzumgebung des AU 253

6.1.3	Aufbau und Einsatz des AU 253

6.2	V-Modell und der Entwicklungsstandard des US-DoD: MIL-STD-498

6.2.1	Systemstruktur

6.2.2	Aktivitäten

7	Zuordnung V-Modell zu STANAG 4159

7.1	Baselines

7.2	Konfigurationsmanagement-Plan

Anhang


'Allgemeiner Umdruck Nr. 250/2 - Anhang'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/2'   (Behördenspezifische Ergänzungen - Anhang)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.1	Phasenvorlauf Wehrmaterial

A.1.2	Definitionsphase Wehrmaterial

A.1.3	Entwicklungsphase Wehrmaterial

A.1.4	Beschaffungsphase Wehrmaterial

A.1.5	Nutzung Wehrmaterial

A.2	DV-Vorhaben

A.2.1	Phasenvorlauf DV-Vorhaben

A.2.2	Definitionsphase DV-Vorhaben

A.2.3	Entwicklungsphase DV-Vorhaben

A.2.4	Einführungsphase DV-Vorhaben

A.2.5	Nutzung DV-Vorhaben

B	SWPÄ

B.1	Produktmuster SWPÄ-Konzept

B.2	Die Aktivitäten des operativen Moduls ”Pflege/Änderung”

PÄ 1:	Änderung der Anwenderforderungen

PÄ 2:	Änderung der Systemarchitektur

PÄ 3:	Änderung der Technischen Anforderungen

PÄ 4:	Änderung der Schnittstellenübersicht und Schnittstellenbeschreibung

PÄ 5:	Änderung der Software

PÄ 5.1:	SW-Architektur ändern

PÄ 5.2:	SW-Entwurf ändern

PÄ 5.3:	Datenkatalog ändern

PÄ 5.4:	SW-Implementierung ändern

PÄ 5.5:	Selbstprüfung durchführen

PÄ 6:	Änderung des Integrationplans

PÄ 7:	Integration

PÄ 8:	Änderung der Betriebsinformationen

PÄ 9:	Überleitung in die Nutzung

C	Definitionen

D	Verzeichnisse

D.1	Abkürzungsverzeichnis

D.2	Abbildungsverzeichnis

D.3	Tabellenverzeichnis

D.4	Literaturverzeichnis


'Allgemeiner Umdruck Nr. 250/3'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (Handbuchsammlung)

Vorbemerkungen

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

HW	Hardwareerstellung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

OOS	Berücksichtigung objektorientierter Sprachen

R	Rollenkonzept im V-Modell

RE	Reverse Engineering

SEC	Anwendung des V-Modells und ITSEC

SI	Sicherheit und Kritikalität

SZ	Szenarien

T	Tailoring und projektspezifisches V-Modell

UMF	Einordnung des V-Modells in sein Umfeld


Übersicht 'Handbuch BRH'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (BRH)

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

BRH.1	Vorbemerkungen

BRH.2	Abgleich der BRH-Forderungen und der Regelungen des V-Modells

BRH.3	Zuordnung der V-Modell-Produkte und -Aktivitäten zu den BRH-Forderungen

Anhang

A.1	Literaturverzeichnis


Übersicht 'Handbuch GPO'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (GPO)

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

DPO.1	Geschäftsprozesse und IT-Systeme

DPO.2	Organisationsentwicklung und ”Business Process Reengineering”

DPO.3	Systemanforderungsanalyse und Geschäftsprozeßoptimierung

DPO.4	Relevante Aktivitäten und Produkte

DPO.5	Allgemeines zur GPO

Anhang

A.1	Abbildungsverzeichnis


Übersicht 'Handbuch HW'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (HW)

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW:	HW-Grobentwurf

SE 4.1-HW:	Lösungsvorschläge erarbeiten und bewerten

SE 4.2-HW:	Grobentwurf einer HW-Einheit erarbeiten

SE 4.3-HW:	HW-interne Schnittstellen spezifizieren

SE 4.4-HW:	HW-Integration spezifizieren

SE 5-HW:	HW-Feinentwurf

SE 5.1-HW:	Detailentwürfe für HW-Komponenten/HW-Module erstellen

SE 5.2-HW:	Zeichnungssatz erstellen

SE 5.3-HW:	Analysen und Nachweise durchführen

SE 6-HW:	HW-Realisierung

SE 6.1-HW:	HW-Komponente/HW-Modul anfertigen

SE 6.2-HW:	Selbstprüfung durchführen

SE 7-HW:	HW-Integration

SE 7.1-HW:	Zur HW-Teilstruktur integrieren

SE 7.2-HW:	HW-Teilstrukturen-Selbstprüfung durchführen

SE 7.3-HW:	Zur HW-Einheit integrieren

SE 7.4-HW:	HW-Einheiten-Selbstprüfung

HW.2	Produkte der Hardwareerstellung

HW.2.1	Hardware-Anforderungen (als Teil der Technischen Anforderungen)

HW.2.2	HW-Architektur

HW.2.3	Zeichnungssatz

HW.2.4	Realisierungsdokumente

HW.2.5	Analysebericht

HW.3	Submodell Qualitätssicherung (QS)

HW.3.1	QS-Produkte

HW.3.2	QS-Prüfungen

HW.3.3	Entwurf von Prüfmitteln

HW.4	Submodell Konfigurationsmanagement (KM)

HW.5	Submodell Projektmanagement (PM)

HW.6	Produktmuster

HW.6.1	Hardware-Anforderungen

HW.6.2	HW-Architektur (HwArc_)

HW.6.3	Zeichnungssatz (ZeiS_)

HW.6.4	Realisierungsdokumente (RealD_)

HW.6.5	Analysebericht (AnaB_)

HW.6.6	Sonstige HW-relevante Unterlagen

Anhang

A.1	Literaturverzeichnis


Übersicht 'Handbuch ISO'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (ISO)

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.1	Einleitung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.1	Zusammenhang der Qualitätsnormen

ISO.2.2	ISO 9001-Konformität auf der Basis des V-Modells

ISO.2.3	AQAP-150-Konformität auf der Basis des V-Modells

ISO.2.4	AQAP-110/150-Konformität auf der Basis eines ISO-9001-Zertifikats

ISO.2.4.1	Formelle nicht vertragsbezogene Bestätigung

ISO.2.4.2	Formlose vertragsbezogene Bestätigung

ISO.2.5	Zusammenhang von V-Modell, ISO 900x und AQAP

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.1	Überblick über die ISO 12207

ISO.3.2	Abdeckung der Prozesse der ISO 12207 durch das V-Modell

ISO.3.2.1	Zuordnung von Aktivitäten des V-Modells zu den Primary Processes

ISO.3.2.2	Supporting Processes

ISO.3.2.3	Organizational Processes

Anhang

A.1	Abbildungsverzeichnis

A.2	Tabellenverzeichnis

A.3	Literaturverzeichnis


Übersicht 'Handbuch OOS'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (OOS)

OOS	Berücksichtigung objektorientierter Sprachen

OOS.1	Überblick

OOS.2	Auswirkung objektorientierter Vorgehensweisen

OOS.2.1	Grundsätzliche Sichtweise des V-Modells

OOS.2.2	Regeln und Kriterien für die praktische Umsetzung

OOS.3	Anwendung von Ada 95

OOS.3.1	Die Strukturierungsmittel von Ada 95

OOS.3.2	Abbildung auf die Erzeugnisstruktur

OOS.3.3	Übersicht

OOS.4	Anwendung von C++

OOS.4.1	Die Strukturierungsmittel von C++

OOS.4.2	Abbildung auf die Erzeugnisstruktur

OOS.4.3	Übersicht

OOS.5	Anwendung anderer objektorientierter oder objektbasierter Sprachen

OOS.5.1	Übersicht der Sprachzuordnung für OO-COBOL

OOS.5.2	Übersicht der Sprachzuordnung für FORTRAN 90

Anhang

A.1	Tabellenverzeichnis

A.2	Literaturverzeichnis


Übersicht 'Handbuch R'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (R)

R	Rollenkonzept im V-Modell

R.1	Allgemeines

R.2	Die Rollen im V-Modell

R.2.1	Projektmanager, PM

R.2.2	Projektleiter, PM

R.2.3	Rechtsverantwortlicher, PM

R.2.4	Projektadministrator, PM

R.2.5	Controller, PM

R.2.6	Q-Manager, QS

R.2.7	QS-Verantwortlicher, QS

R.2.8	Prüfer, QS

R.2.9	KM-Manager, KM

R.2.10	KM-Verantwortlicher, KM

R.2.11	KM-Administrator, KM

R.2.12	Systemanalytiker, SE

R.2.13	Systemdesigner, SE

R.2.14	SW-Entwickler, SE

R.2.15	HW-Entwickler, SE

R.2.16	Technischer Autor, SE

R.2.17	IT-Beauftragter, SE

R.2.18	SEU-Betreuer, SE

R.2.19	Datenadministrator, SE

R.2.20	Datenschutzbeauftragter, SE

R.2.21	IT-Sicherheitsbeauftragter, SE

R.2.22	Anwender, SE

R.2.23	Systembetreuer, SE

R.3	Rollen/Aktivitäten-Zuordnung

Anhang

A.1	Tabellenverzeichnis


Übersicht 'Handbuch RE'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (RE)

RE	Reverse Engineering

RE.1	Vorbemerkungen

RE.2	Begriffsbestimmung: Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.1	Überblick

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1:	Erhebung des Anwenderbedarfs

RE 1.1:	Ist-Aufnahme durchführen

RE 1.2:	Ist-Analyse durchführen

RE 1.3:	Lösungsvorschläge formulieren

RE 1.4:	Technische Durchführbarkeit untersuchen

RE 1.5:	Wirtschaftlichkeit untersuchen

RE 2:	Durchführung softwaretechnischer Verbesserungen

RE 2.1:	Vorhandenen Quellcode messen

RE 2.2:	Remodularisierung / Restrukturierung

RE 2.3:	Reformatierung

RE 2.4:	Verbesserten Quellcode messen

RE 2.5:	Weiterverwendungsfähige Softwarebausteine festlegen

RE 3:	Wiedergewinnung der technischen Sicht

RE 3.1:	Systemarchitektur wiedergewinnen

RE 3.2:	Systeminterne und -externe Schnittstellen wiedergewinnen

RE 3.3:	Prozeßentwurf wiedergewinnen

RE 3.4:	SW-Architektur beschreiben

RE 3.5:	SW-interne Schnittstellen beschreiben

RE 3.6:	SW-Entwurf beschreiben

RE 3.7:	Datenkatalog erstellen

RE 3.8:	Technische Anforderungen beschreiben

RE 3.9:	SW-Integration spezifizieren

RE 3.10:	Systemintegration spezifizieren

RE 4:	Wiedergewinnung der fachlichen Sicht

RE 4.1:	Anwenderforderungen wiedergewinnen

RE 4.2:	Datenkatalog vervollständigen

RE 5:	Abbildung der fachlichen auf die technische Sicht

RE 5.1:	Fachliche Funktionseinheiten technischen Funktionseinheiten zuordnen

RE 5.2:	Rekommentierung

RE 6:	SW-Integration

RE 6.1:	Zur SW-Einheit integrieren

RE 6.2:	Selbstprüfung der SW-Einheit durchführen

RE 7:	Systemintegration

RE 7.1:	Zum System integrieren

RE 7.2:	Selbstprüfung des Systems durchführen

RE 7.3:	Produkt bereitstellen

RE 8:	Wiedereinführung des Systems

RE 8.1:	Beitrag zur Wiedereinführungsunterstützung leisten

RE 8.2:	SWPÄ-Konzept erstellen

RE 8.3:	System installieren

RE 8.4:	Wiederinbetriebnahme

RE 9:	Ermittlung wiederverwendungsfähiger Softwarebausteine

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.1	Anwenderforderungen (AFo_)

RE.3.3.2	Systemarchitektur (SysArc_)

RE.3.3.3	Technische Anforderungen (TAnf_)

RE.3.3.4	SW-Architektur (SwArc_)

RE.3.3.5	SW-Entwurf (SwEnt_)

RE.3.3.6	Anwenderbedarf (ABed_)

RE.3.3.7	Sachbericht ”Messung des Quellcodes” (SbMes_)

RE.3.3.8	Sachbericht ”Wiederverwendungsfähige Softwarebausteine” (SbWv_)

RE.3.4	Überblick über Aktivitäten und entstehende Produkte


Übersicht 'Handbuch SEC'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (SEC)

SEC	Anwendung des V-Modells und der ITSEC

SEC.1	Einleitung

SEC.2	Erläuterungen zum Submodell SE

SEC.3	Erläuterungen zum Submodell QS

SEC.4	Erläuterungen zum Submodell KM

SEC.5	Erläuterungen zum Submodell PM


Übersicht 'Handbuch SI'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (SI)

SI	Sicherheit und Kritikalität

SI.1	Behandlung der Sicherheit

SI.2	Behandlung der Kritikalität

SI.2.1	Kritikalitätszuordnung

SI.2.2	Vererbung der Kritikalität

SI.2.3	Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten

Anhang

A.1	Abbildungsverzeichnis

A.2	Tabellenverzeichnis


Übersicht 'Handbuch SZ'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (SZ)

SZ	Szenarien

SZ.1	Überblick

SZ.2	Inkrementelle Entwicklung

SZ.2.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.2.2	Zusammenspiel mit den übrigen Submodellen

SZ.2.2.1	Zusammenspiel der Submodelle SE und PM

SZ.2.2.2	Zusammenspiel der Submodelle SE und QS

SZ.2.2.3	Zusammenspiel der Submodelle SE und KM

SZ.2.3	Kriterien für die Auswahl des Szenarios

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.3.2	Zusammenspiel mit den übrigen Submodellen

SZ.3.2.1	Zusammenspiel der Submodelle SE und PM

SZ.3.2.2	Zusammenspiel der Submodelle SE und QS

SZ.3.2.3	Zusammenspiel der Submodelle SE und KM

SZ.3.3	Kriterien für die Auswahl des Szenarios

SZ.4	Einsatz von Fertigprodukten

SZ.4.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.4.2	Zusammenspiel mit den übrigen Submodellen

SZ.4.2.1	Zusammenspiel der Submodelle SE und PM

SZ.4.2.2	Zusammenspiel der Submodelle SE und QS

SZ.4.2.3	Zusammenspiel der Submodelle SE und KM

SZ.4.3	Kriterien für die Auswahl des Szenarios

SZ.5	Objektorientierte Entwicklung

SZ.5.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.5.2	Zusammenspiel mit den übrigen Submodellen

SZ.5.3	Kriterien für die Auswahl des Szenarios

SZ.6	Entwicklung wissensbasierter Systeme

SZ.6.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.6.2	Zusammenspiel mit den übrigen Submodellen

SZ.6.3	Kriterien für die Auswahl des Szenarios

SZ.7	Pflege und Änderung

SZ.7.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

SZ.7.2	Zusammenspiel mit den übrigen Submodellen

SZ.7.2.1	Zusammenspiel der Submodelle SE und PM

SZ.7.2.2	Zusammenspiel der Submodelle SE und QS

SZ.7.2.3	Zusammenspiel der Submodelle SE und KM

SZ.7.3	Kriterien für die Auswahl des Szenarios

Anhang

A.1	Abbildungsverzeichnis


Übersicht 'Handbuch T'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (T)

T	Tailoring und projektspezifisches V-Modell

T.1	Gründe und Ziele

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.1	Berücksichtigung der Mindestanforderungen

T.2.1.2	Standardisiertes Vortailoring

T.2.1.3	Tailoring mit Streichbedingungen

T.2.1.4	Berücksichtigung von Entwicklungsstrategien beim Tailoring

T.2.1.5	Anwendung der Tailoringverfahren

T.2.2	Prüfung des projektspezifischen V-Modells

T.2.3	Dokumentation des projektspezifischen V-Modells

T.2.3.1	Aktivitäten- und Produktbeschreibungen

T.2.3.2	Aufzeichnung der Streichbedingungen für das Projekt

T.3	IT-Vorhabentypen

T.3.1	Merkmale mit ihren Quantifizierungen

T.3.1.1	Projektgrößeneinstufung

T.3.1.2	Komplexitätseinstufung von Funktionen und Daten

T.3.1.3	Quantifizierung der Wartbarkeitsanforderungen

T.3.2	Administrative IT-Vorhaben

T.3.2.1	Kleine administrative IT-Vorhaben

T.3.2.2	Mittlere administrative IT-Vorhaben

T.3.2.3	Große administrative IT-Vorhaben

T.3.3	Technisch-wissenschaftliche IT-Vorhaben

T.3.3.1	Kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

T.3.3.2	Große technisch-wissenschaftliche IT-Vorhaben

T.3.4	Auswahl, Beschaffung und Anpassung von Fertigprodukten

T.3.5	Darstellung der Vorhabentypen im Überblick

T.3.6	Tailoring-Formblätter

T.3.6.1	Anwendung der Formblätter

T.3.6.2	Formblattsammlung

T.4	Streichbedingungen

T.4.1	Vorbemerkungen

T.4.2	Konventionen

T.4.3	Streichen von Aktivitäten

T.4.3.1	Submodell PM

T.4.3.2	Submodell QS

T.4.3.3	Submodell KM

T.4.3.4	Submodell SE

T.4.4	Streichen von Produkten

T.5	Aktivitäten- und Produkte-Auswahlformblatt

Anhang

A.1	Abbildungsverzeichnis

A.2	Tabellenverzeichnis


Übersicht 'Handbuch UMF'
Entwicklungsstandard für IT-Systeme des Bundes

Inhaltsverzeichnis   'Allgemeiner Umdruck Nr. 250/3'   (UMF)

UMF	Einordnung des V-Modells in sein Umfeld

UMF.1	Zielsetzung des V-Modells

UMF.2	Anwendung des V-Modells

UMF.2.1	Verwendung als Leitfaden

UMF.2.2	Verwendung als Checkliste

UMF.2.3	Verwendung als Qualitätszieldefinition

UMF.3	Unterschiedliche Einsatzsituationen

UMF.4	Adressaten des V-Modells

UMF.5	Konzeption des V-Modells

UMF.6	Das Richtlinienumfeld des V-Modells

UMF.7	V-Modell und Phasenmodelle

UMF.8	Verwendungsformen des V-Modells

Anhang

A.1	Abbildungsverzeichnis


Index
Fettschrift verweist auf die Definition des betreffenden Begriffs

-- A --

Abbildungsverzeichnis	→	Abbildungsverzeichnis

→	Abbildungsverzeichnis

Abkürzungsverzeichnis	→	Abkürzungsverzeichnis

→	Abkürzungsverzeichnis

Ablauforganisation	→	PM 4: Feinplanung

Ablaufprüfung	→	Definitionen

Abnahme	→	Anwenderforderungen (AFo_)

→	Definitionen

Akquisition	→	Definitionen

Akquisition:evolutionäre	→	Definitionen

Akquisition:klassische	→	Definitionen

Aktivität	→	Aktivitäten und Produkte

→	Definitionen

Aktivität:operative	→	Definitionen

Aktivität:periodisch durchzuführende	→	Überblick

Aktivitäten/Rollen-Matrix	→	PM 1.3: Projektspezifisches V-Modell erstellen

Aktivitätenklasse	→	Definitionen

Aktivitätenschema	→	Aktivitätenschema

→	Definitionen

Aktivitätentyp	→	Definitionen

Aktivitätenzerlegung	→	Definitionen

Änderbarkeit	→	Definitionen

Anwender	→	Definitionen

Anwenderforderungen	→	Definitionen

Arbeitsabschnitt	→	Überblick

→	PM 12: Vergabe von Arbeitsaufträgen

→	PM 12: Vergabe von Arbeitsaufträgen

→	PM 13: Einweisung der Mitarbeiter

Ausbaustufe	→	Definitionen

Ausbildungs-Software	→	Projekthandbuch (PHb_)

→	Definitionen

Austauschbare Einheit	→	Definitionen

-- B --

Baseline	→	PM 1.5: Grobplan erstellen

→	PM 4: Feinplanung

→	Projektplan (PPl_)

→	Definitionen

Baustein	→	Definitionen

Bedrohung	→	Definitionen

Bedrohungsanalyse	→	Anwenderforderungen (AFo_)

→	SE 1: System-Anforderungsanalyse

→	Definitionen

Benutzbarkeit	→	Definitionen

Beschaffung	→	Überblick

Big Bang	→	Definitionen

→	Definitionen

Bottom-up-Integration	→	SE 7.1-SW: Zur SW-Komponente integrieren

Bw-IT-Standards	→	Definitionen

-- C --

-- D --

Daten	→	Definitionen

Datenbank	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Datenbanksystem	→	Definitionen

Datensicherheit	→	Definitionen

Datensicherung:kontinuierliche	→	KM 4.4: Ergebnisse sichern

Datensicherung:Meilenstein-	→	KM 4.4: Ergebnisse sichern

Datensicherung:Projekt-abschließende	→	KM 4.4: Ergebnisse sichern

Datenstruktur	→	Definitionen

Definitionen	→	Definitionen

→	Definitionen

Durchführungsplan	→	Definitionen

-- E --

Effizienz	→	Definitionen

Einsatzmittel	→	Definitionen

Element der Systemarchitektur	→	Definitionen

→	Definitionen

Element	→	Überblick

Endekriterien	→	Prüfspezifikation (PrSpez_)

Entwicklung:inkrementelle	→	Definitionen

→	Definitionen

Entwicklung:klassische	→	Definitionen

Erzeugnisstruktur	→	Überblick

→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

Evaluation	→	Definitionen

evolutionäre Akquisition	→	Definitionen

evolutionäres Prototyping	→	Definitionen

experimentelles Prototyping	→	Definitionen

exploratives Prototyping	→	Definitionen

-- F --

Fehlverhalten	→	Definitionen

Fertigprodukt	→	SE 4.3-SW: SW-Integration spezifizieren

→	Definitionen

Festspeicher	→	Definitionen

Firmware	→	Definitionen

Forderungscontrolling	→	Definitionen

formelle Prüfung	→	Ausprägungen von Prüfaktivitäten

Funktionalität	→	Definitionen

Funktionseinheit	→	Definitionen

→	Definitionen

Funktionsstruktur	→	Definitionen

-- G --

Gesamthorizont	→	SE 1: System-Anforderungsanalyse

→	Definitionen

Geschäftsbereich des BMVg	→	Definitionen

Geschäftsprozeß	→	SE 1.1: Ist-Aufnahme/-Analyse durchführen

→	SE 1.5: System fachlich strukturieren

→	Definitionen

Grand Design	→	Definitionen

-- H --

Hardware	→	Definitionen

Hardware-Einheit	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Hardware-Komponente	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Hardware-Modul	→	Definitionen

Hauptaktivität	→	Aktivitäten und Produkte

→	Definitionen

HW-Einheit	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

HW-Komponente	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

-- I --

Inkrement	→	Definitionen

inkrementelle Entwicklung	→	Definitionen

→	Definitionen

inkrementelles Prototyping	→	Definitionen

Instantiierung	→	Definitionen

Instanz	→	Definitionen

IT-Ausstattungsvorgaben	→	Definitionen

IT-Normen	→	Definitionen

IT-Sicherheit	→	Anwenderforderungen (AFo_)

→	Anwenderforderungen (AFo_)

→	Systemarchitektur (SysArc_)

→	Prüfspezifikation (PrSpez_)

→	Erfüllung von Sicherheitskriterien

→	SE 9.2: System installieren

IT-Sicherheitsanteil	→	Definitionen

IT-Sicherheitskonzept	→	Systemarchitektur (SysArc_)

→	Prüfspezifikation (PrSpez_)

IT-Sicherheitsmodell	→	Systemarchitektur (SysArc_)

→	Prüfspezifikation (PrSpez_)

IT-Sicherheitsziel	→	KM 1.2: KM einrichten

→	Anwenderforderungen (AFo_)

IT-Standards	→	Definitionen

→	Definitionen

IT-System	→	Systembegriff im V-Modell

→	Definitionen

IT-Vorhaben	→	Definitionen

-- J --

-- K --

klassische Akquisition	→	Definitionen

klassische Entwicklung	→	Definitionen

Konfiguration	→	Überblick

→	KM 2: Produkt- und Konfigurationsverwaltung

→	KM 2.4: Konfiguration fortschreiben

→	KM 4.5: KM-Dokumentation führen

→	Definitionen

Konfiguration:Konfigurationskennung	→	QS 2.2: Prüfumgebung definieren

Konfigurationseinheit	→	Definitionen

Kritikalität	→	SE 2.1: System technisch entwerfen

→	SE 2.1: System technisch entwerfen

→	SE 4.1-SW: SW-Architektur entwerfen

→	Definitionen

Kritikalität:der Datenbank	→	SW-Architektur (SwArc_)

→	SE 6.3-SW: Selbstprüfung des SW-Moduls/der Datenbank durchführen

Kritikalität:der Komponente	→	SE 7.2-SW: Selbstprüfung der SW-Komponente durchführen

Kritikalität:der SW-Einheit	→	SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen

Kritikalität:der SW-Komponente	→	SW-Architektur (SwArc_)

Kritikalität:des Elements	→	Technische Anforderungen (TAnf_)

Kritikalität:des Moduls	→	SE 6.3-SW: Selbstprüfung des SW-Moduls/der Datenbank durchführen

Kritikalität:des Prozesses	→	SW-Architektur (SwArc_)

Kritikalität:des Prüfgegenstandes	→	QS 2.1: Prüfmethoden und -kriterien festlegen

Kritikalität:des SW-Moduls	→	SW-Architektur (SwArc_)

Kritikalität:des Systems	→	Anwenderforderungen (AFo_)

→	SE 8.2: Selbstprüfung des Systems durchführen

Kritikalität:Einstufung der Funktionseinheit	→	Prüfspezifikation (PrSpez_)

Kritikalität:Kritikalitäten/Methoden-Matrix	→	QS 2.1: Prüfmethoden und -kriterien festlegen

Kritikalität:Kritikalitätsstufe	→	SE 4.1-SW: SW-Architektur entwerfen

kritisch:kritische Erfolgsfaktoren	→	PM 1.2: Projektkriterien und Entwicklungsstrategie festlegen

→	PM 1.2: Projektkriterien und Entwicklungsstrategie festlegen

→	Projekthandbuch (PHb_)

kritisch:kritische Funktion	→	SE 2.1: System technisch entwerfen

→	SE 7.1-SW: Zur SW-Komponente integrieren

→	SE 8.2: Selbstprüfung des Systems durchführen

kritisch:kritische Komponente	→	SE 2.1: System technisch entwerfen

kritisch:kritische Situation	→	SE 8.2: Selbstprüfung des Systems durchführen

-- L --

Lademodul	→	Definitionen

Literaturverzeichnis	→	Literaturverzeichnis

→	Literaturverzeichnis

-- M --

Maßnahmen:analytische	→	Analytische Maßnahmen

→	Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten

Maßnahmen:konstruktive	→	Konstruktive Maßnahmen

→	Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten

Meilenstein	→	Definitionen

Meilensteinplan	→	Definitionen

-- N --

Nachweis	→	Definitionen

Nachweis-Software	→	Projekthandbuch (PHb_)

→	Definitionen

Nachweisführung	→	Ausprägungen von Prüfaktivitäten

→	QS 1: QS-Initialisierung

Nutzer	→	Definitionen

-- O --

One Shot	→	Definitionen

→	Definitionen

operationelles System	→	Definitionen

operative Aktivität	→	Definitionen

operative Hardware	→	SE 7.1-SW: Zur SW-Komponente integrieren

operative Software	→	Projekthandbuch (PHb_)

→	SE 7.1-SW: Zur SW-Komponente integrieren

→	Definitionen

operatives Modul	→	Definitionen

Organisationsplanung	→	PM 1.1: Projekt einrichten

-- P --

Planungsabschnitt	→	Überblick

Platzhalter	→	SE 7.1-SW: Zur SW-Komponente integrieren

→	SE 7.1-SW: Zur SW-Komponente integrieren

→	SE 8: System-Integration

→	SE 8.1: Zum System integrieren

→	Definitionen

Portabilität	→	Definitionen

Produkt	→	Aktivitäten und Produkte

→	Definitionen

Produktbibliothek	→	KM 1: KM-Planung

→	KM 2.1: Produkt initialisieren

→	KM 2.3: Produkt verwalten

→	KM-Plan (KPl_)

Produktklasse	→	Definitionen

Produktmuster	→	Produktmuster

Produktprüfung	→	Definitionen

Produktschema	→	Definitionen

Projekt	→	Überblick

→	Definitionen

Projektplanung	→	PM 1.5: Grobplan erstellen

→	Definitionen

Prototyp	→	Definitionen

Prototyping	→	Definitionen

Prototyping:evolutionäres	→	Definitionen

Prototyping:experimentelles	→	Definitionen

Prototyping:exploratives	→	Definitionen

Prototyping:inkrementelles	→	Definitionen

Prozeß-Ensemble	→	SE 4.1-SW: SW-Architektur entwerfen

Prozeßprüfung	→	Definitionen

Prüfaktivitäten	→	Ausprägungen von Prüfaktivitäten

Prüfanforderungen	→	QS 2.2: Prüfumgebung definieren

Prüfbarkeit eines HW-Bausteins	→	Definitionen

Prüffälle:Festlegung in der Prüfspezifikation	→	QS 2.3: Prüffälle festlegen

Prüfkriterien	→	QS 2.2: Prüfumgebung definieren

→	Definitionen

Prüfkriterien:Festlegung im QS-Plan	→	QS 2.1: Prüfmethoden und -kriterien festlegen

Prüfmethode	→	QS 2.2: Prüfumgebung definieren

Prüfmethoden:Festlegung im QS-Plan	→	QS 2.1: Prüfmethoden und -kriterien festlegen

Prüfumgebung	→	QS 2.2: Prüfumgebung definieren

Prüfumgebung:System-Prüfumgebung	→	KM 3.1: Änderung bewerten

Prüfung	→	Definitionen

Prüfung:formelle	→	Ausprägungen von Prüfaktivitäten

Prüfung:Selbstprüfung	→	SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen

→	SE 8.2: Selbstprüfung des Systems durchführen

→	SE 8.2: Selbstprüfung des Systems durchführen

Pseudocode	→	SE 6.1-SW: SW-Module codieren

→	Definitionen

-- Q --

Qualifikation	→	Definitionen

Qualität	→	Definitionen

Qualitätsforderung	→	QS 2.3: Prüffälle festlegen

→	Definitionen

Qualitätsmanagement	→	Definitionen

Qualitätsmaße	→	Definitionen

Qualitätsmerkmal	→	SE 8.2: Selbstprüfung des Systems durchführen

Qualitätsmerkmale	→	SE 1.3: Kritikalität und Anforderungen an die Qualität definieren

→	SE 3.4: Anforderungen an die Qualität der SW-/HW-Einheit definieren

→	Definitionen

Qualitätssicherung	→	Definitionen

Quellcode	→	Implementierungsdokumente (ImplD)

-- R --

Randbedingungen	→	Definitionen

Ressourcenplanung	→	PM 4: Feinplanung

Risikoanalyse	→	SE 1: System-Anforderungsanalyse

→	Definitionen

Risikomanagement	→	PM 7: Risikomanagement

Rollen (des V-Modells)	→	Definitionen

Rollen (des V-Modells):bei Prüfaktivitäten	→	Rollenverteilung bei der Durchführung von Prüfaktivitäten

→	Ausprägungen von Prüfaktivitäten

Rollen (des V-Modells):beim Änderungsmanagement	→	KM 3: Änderungsmanagement (Konfigurationssteuerung)

-- S --

Sandwich-Integration	→	SE 7.1-SW: Zur SW-Komponente integrieren

Schnittstelle	→	Definitionen

Schnittstelle:externe der SW-Einheit/HW-Einheit	→	SE 3.2: Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren

Schnittstelle:SW-externe	→	SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen

Schnittstelle:SW-interne	→	SE 3.1: Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren

→	SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen

Schulung	→	PM 10: Schulung/Einarbeitung

Segment	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Selbstprüfung	→	SE 6-SW: SW-Implementierung

→	SE 6.3-SW: Selbstprüfung des SW-Moduls/der Datenbank durchführen

→	SE 7.2-SW: Selbstprüfung der SW-Komponente durchführen

→	SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen

→	SE 8.2: Selbstprüfung des Systems durchführen

→	Ausprägungen von Prüfaktivitäten

→	Definitionen

Sicherheitsbestimmungen	→	Informationen zum Betriebshandbuch (BetrHb_)

Software	→	Definitionen

Software-Einheit	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Software-Komponente	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Software-Modul	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Software-Pflege und -Änderung	→	PM 1.4: Toolset-Management durchführen

→	Technische Anforderungen (TAnf_)

→	SE 3.5: Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren

→	SE 5.2-SW: Betriebsmittel- und Zeitbedarf analysieren

Software-Pflege und -Änderung:Projekt	→	KM 3.2: Änderungsvorgehen entscheiden und Änderung einleiten

Software-Pflege und -Änderung:Software-Pflege	→	Definitionen

Software-Pflege	→	Definitionen

Software:Ausbildungs-	→	Projekthandbuch (PHb_)

→	Definitionen

Software:Nachweis-	→	Projekthandbuch (PHb_)

→	Definitionen

Software:operative	→	Projekthandbuch (PHb_)

→	Definitionen

Software:SWPÄ-	→	Projekthandbuch (PHb_)

→	Definitionen

Software:Unterstützungs-	→	Projekthandbuch (PHb_)

→	Definitionen

Softwarebaustein	→	Definitionen

Spezifikationssprache	→	SE 6.1-SW: SW-Module codieren

Status:einer Änderung	→	KM 3: Änderungsmanagement (Konfigurationssteuerung)

Stub	→	SE 7.1-SW: Zur SW-Komponente integrieren

Submodell	→	Submodelle

→	Definitionen

SW-Einheit	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

SW-Komponente	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

SW-Modul	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

SW-Teilstruktur	→	SE 7-SW: SW-Integration

→	Definitionen

SWPÄ-Software	→	Projekthandbuch (PHb_)

→	Definitionen

System (Produkt)	→	Behandlung der Sicherheit

System	→	Definitionen

System:teilintegriertes	→	SE 8: System-Integration

System_Integration spezifizieren (Aktivität)	→	Erläuterungen zum Submodell SE

→	Erläuterungen zum Submodell SE

Systemarchitektur	→	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

→	Definitionen

Systemsicherheit	→	Definitionen

Szenario	→	Definitionen

-- T --

Tabellenverzeichnis	→	Tabellenverzeichnis

→	Tabellenverzeichnis

Tailoring	→	Projekthandbuch (PHb_)

→	Anpassung an die konkrete Projektsituation

Tailoring:Ausschreibungsrelevantes	→	PM 1.3: Projektspezifisches V-Modell erstellen

Tailoring:Technisches	→	PM 1.3: Projektspezifisches V-Modell erstellen

→	PM 4: Feinplanung

technische Anforderungen	→	Definitionen

Testabdeckung	→	Definitionen

Top-down-Integration	→	SE 7.1-SW: Zur SW-Komponente integrieren

traditionelle Entwicklung	→	Definitionen

Treiber	→	SE 7.1-SW: Zur SW-Komponente integrieren

-- U --

Übertragbarkeit	→	Definitionen

Unterauftrag	→	PM 4: Feinplanung

Unterbrechung	→	SE 8.2: Selbstprüfung des Systems durchführen

→	Definitionen

Unterstützungs-Software	→	Projekthandbuch (PHb_)

→	Definitionen

-- V --

V-Modell	→	Definitionen

V-Modell:Anpassung	→	Anpassung an die konkrete Projektsituation

V-Modell:Anwendung	→	Anwendung des V-Modells

V-Modell:Erfüllung der IT-Sicherheitskriterien	→	Erfüllung von Sicherheitskriterien

V-Modell:Erfüllung von QS-Vorschriften	→	Erfüllung von QS-Vorschriften

V-Modell:Rolle	→	Definitionen

V-Modell:Systembegriff	→	Systembegriff im V-Modell

Validierung	→	Definitionen

Variante	→	Definitionen

Verfügbarkeit	→	Definitionen

Vergabe	→	Überblick

Verifizierung	→	Definitionen

Version	→	Überblick

→	KM 2.4: Konfiguration fortschreiben

→	KM 4.5: KM-Dokumentation führen

→	KM-Plan (KPl_)

→	Definitionen

vor Ort austauschbare Einheit	→	Definitionen

-- W --

Wasserfallmodell	→	Definitionen

-- X --

-- Y --

-- Z --

Zertifikation	→	Definitionen

zugesicherte Eigenschaften	→	Definitionen

Zustände:eines Produkts	→	Überblick

→	KM 1.1: KM-Plan erstellen

→	KM-Plan (KPl_)

→	Produktzustände

→	Definitionen

Zuverlässigkeit	→	Definitionen


Glossar
-- A --

Abnahme

Akquisition

Aktivität

Aktivitätenklasse

Aktivitätenschema

Aktivitätenzerlegung

Änderbarkeit

Anwender

Anwenderforderungen

Ausbaustufe

Ausbildungs-Software

Austauschbare Einheit

-- B --

Baseline

Bedrohung

Bedrohungsanalyse

Benutzbarkeit

Bw-IT-Standards

-- C --

-- D --

Daten

Datenbank

Datenbanksystem

Datensicherheit

Datenstruktur

De-facto-Standards

Durchführungsplan

-- E --

Effizienz

Einsatzmittel

Element der Systemarchitektur

Evaluation

Evolutionäre Akquisition

Experimentelles Prototyping

Exploratives Prototyping

-- F --

Fehlverhalten

Fertigprodukt

Festspeicher

Firmware

Forderungscontrolling

Funktionalität

Funktionseinheit

Funktionsstruktur

-- G --

Gesamthorizont

Geschäftsbereich des BMVg

Geschäftsprozeß

-- H --

Hardware

Hardware-Einheit (HW-Einheit)

Hardware-Komponente (HW-Komponente)

Hardware-Modul (HW-Modul)

Hauptaktivität

-- I --

Individuelles IT-System

Inkrementelle Entwicklung

Instanz, Instantiierung

IT-Ausstattungsvorgaben

IT-Normen

IT-Planungsvorgaben

IT-Sicherheitsanteil

IT-Standards

IT-System

-- J --

-- K --

Klassische Akquisition

Klassische Entwicklung

Konfiguration

Konfigurationseinheit (KE)

Kritikalität

-- L --

Lademodul

-- M --

Meilenstein

Meilensteinplan

-- N --

Nachweis

Nachweis-Software

Nutzer

-- O --

Operationelles System

Operative Aktivität

Operative Software

Operatives Modul

-- P --

Platzhalter

Portabilität

Produkt

Produktklasse

Produktprüfung

Produktschema

Produktzustand

Projekt

Projektplanung

Prototyp

Prototyping

Prozeßprüfung

Prüfbarkeit eines HW-Bausteins

Prüfkriterien

Prüfung

Pseudocode

-- Q --

Qualifikation

Qualität

Qualitätsforderung

Qualitätsmanagement

Qualitätsmaße

Qualitätsmerkmale

Qualitätssicherung

-- R --

Randbedingungen

Risikoanalyse

Rolle

-- S --

Schnittstelle

Segment

Selbstprüfung

Software

Software-Einheit (SW-Einheit)

Software-Komponente (SW-Komponente)

Software-Modul (SW-Modul)

Software-Pflege und -Änderung

Softwarebaustein

Submodell

SW-Teilstruktur

SWPÄ-Software

System

Systemarchitektur

Systemsicherheit

Szenario

-- T --

Technische Anforderungen

Testabdeckung

-- U --

Übertragbarkeit

Unterbrechung

Unterstützungs-Software

-- V --

V-Modell

Validierung

Variante

Verfügbarkeit

Verifizierung

Version

Vor Ort austauschbare Einheit

-- W --

-- X --

-- Y --

-- Z --

Zertifikation

Zugesicherte Eigenschaften

Zuverlässigkeit


Liste der Aktivitäten im Submodell SE
SE	KM	Produkte

Aktivitäten	Tabellen

QS	PM	Abbildungen

SE 1:	System-Anforderungsanalyse

SE 1.1:	Ist-Aufnahme/-Analyse durchführen

SE 1.2:	Anwendungssystem beschreiben

SE 1.3:	Kritikalität und Anforderungen an die Qualität definieren

SE 1.4:	Randbedingungen definieren

SE 1.5:	System fachlich strukturieren

SE 1.6:	Bedrohung und Risiko analysieren 5)

SE 1.7:	Forderungscontrolling durchführen

SE 1.8:	Software-Pflege- und Änderungs-Konzept erstellen

SE 2:	System-Entwurf

SE 2.1:	System technisch entwerfen

SE 2.2:	Wirksamkeitsanalyse durchführen

SE 2.3:	Realisierbarkeit untersuchen

SE 2.4:	Anwenderforderungen zuordnen

SE 2.5:	Schnittstellen beschreiben

SE 2.6:	System-Integration spezifizieren

SE 3:	SW-/HW-Anforderungsanalyse

SE 3.1:	Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren

SE 3.2:	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren

SE 3.3:	Anforderungen an die Funktionalität definieren

SE 3.4:	Anforderungen an die Qualität der SW-/HW-Einheit definieren

SE 3.5:	Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren

SE 4-SW:	SW-Grobentwurf

SE 4.1-SW:	SW-Architektur entwerfen

SE 4.2-SW:	SW-interne und -externe Schnittstellen entwerfen

SE 4.3-SW:	SW-Integration spezifizieren

SE 5-SW:	SW-Feinentwurf

SE 5.1-SW:	SW-Komponente/-Modul/Datenbank beschreiben

SE 5.2-SW:	Betriebsmittel- und Zeitbedarf analysieren

SE 6-SW:	SW-Implementierung

SE 6.1-SW:	SW-Module codieren

SE 6.2-SW:	Datenbank realisieren

SE 6.3-SW:	Selbstprüfung des SW-Moduls/der Datenbank durchführen

SE 7-SW:	SW-Integration

SE 7.1-SW:	Zur SW-Komponente integrieren

SE 7.2-SW:	Selbstprüfung der SW-Komponente durchführen

SE 7.3-SW:	Zur SW-Einheit integrieren

SE 7.4-SW:	Selbstprüfung der SW-Einheit durchführen

SE 8:	System-Integration

SE 8.1:	Zum System integrieren

SE 8.2:	Selbstprüfung des Systems durchführen

SE 8.3:	Bereitstellung des Produktes

SE 9:	Überleitung in die Nutzung

SE 9.1:	Beitrag zur Einführungsunterstützung leisten

SE 9.2:	System installieren

SE 9.3:	Inbetriebnahme


Liste der Aktivitäten im Submodell QS
SE	KM	Produkte

Aktivitäten	Tabellen

QS	PM	Abbildungen

QS 1:	QS-Initialisierung

QS 1.1:	QS-Plan erstellen

QS 1.2:	Prüfplan erstellen

QS 2:	Prüfungsvorbereitung

QS 2.1:	Prüfmethoden und -kriterien festlegen

QS 2.2:	Prüfumgebung definieren

QS 2.3:	Prüffälle festlegen

QS 2.4:	Prüfprozedur erstellen

QS 3:	Prozeßprüfung von Aktivitäten

QS 4:	Produktprüfung

QS 4.1:	Prüfbarkeit feststellen

QS 4.2:	Produkt inhaltlich prüfen

QS 5:	QS-Berichtswesen


Liste der Aktivitäten im Submodell KM
SE	KM	Produkte

Aktivitäten	Tabellen

QS	PM	Abbildungen

KM 1:	KM-Planung

KM 1.1:	KM-Plan erstellen

KM 1.2:	KM einrichten

KM 2:	Produkt- und Konfigurationsverwaltung

KM 2.1:	Produkt initialisieren

KM 2.2:	Konfiguration initialisieren

KM 2.3:	Produkt verwalten

KM 2.4:	Konfiguration fortschreiben

KM 2.5:	Zugriffsrechte verwalten

KM 3:	Änderungsmanagement (Konfigurationssteuerung)

KM 3.1:	Änderung bewerten

KM 3.2:	Änderungsvorgehen entscheiden und Änderung einleiten

KM 3.3:	Änderung abschließen

KM 4:	KM-Dienste

KM 4.1:	Daten administrieren

KM 4.2:	SW-/HW-Produkte katalogisieren

KM 4.3:	Schnittstellen koordinieren

KM 4.4:	Ergebnisse sichern

KM 4.5:	KM-Dokumentation führen

KM 4.6:	Release-Management durchführen

KM 4.7:	Projekthistorie führen


Liste der Aktivitäten im Submodell PM
SE	KM	Produkte

Aktivitäten	Tabellen

QS	PM	Abbildungen

PM 1:	Projektinitialisierung

PM 1.1:	Projekt einrichten

PM 1.2:	Projektkriterien und Entwicklungsstrategie festlegen

PM 1.3:	Projektspezifisches V-Modell erstellen

PM 1.4:	Toolset-Management durchführen

PM 1.5:	Grobplan erstellen

PM 2:	Vergabe/Beschaffung

PM 3:	Auftragnehmer-Management

PM 4:	Feinplanung

PM 5:	Kosten-/Nutzenanalyse

PM 6:	Durchführungsentscheidung

PM 7:	Risikomanagement

PM 8:	Projektkontrolle und -steuerung

PM 9:	Informationsdienst/Berichtswesen

PM 10:	Schulung/Einarbeitung

PM 11:	Bereitstellung der Ressourcen

PM 12:	Vergabe von Arbeitsaufträgen

PM 13:	Einweisung der Mitarbeiter

PM 14:	Projektabschluß


Liste der Produkte im Submodell SE
SE	KM	Aktivitäten

Produkte	Tabellen

QS	PM	Abbildungen

Anwenderforderungen	(AFo_)

Systemarchitektur	(SysArc_)

Technische Anforderungen	(TAnf_)

Schnittstellenübersicht	(SSÜb_)

Schnittstellenbeschreibung	(SSB_)

Integrationsplan	(IntPl_)

SWPÄ-Konzept	(SWPÄK_)

SW-Produkte

SW-Architektur	(SwArc_)

SW-Entwurf	(SwEnt_)

Datenkatalog	(DatK_)

Implementierungsdokumente	(ImplD_)

Betriebsinformationen

Informationen zum Anwendungshandbuch	(AHb_)

Informationen zum Diagnosehandbuch	(DiagHb_)

Informationen zum Betriebshandbuch	(BetrHb_)

Sonstige Einsatzinformationen	(EinInf_)


Liste der Produkte im Submodell QS
SE	KM	Aktivitäten

Produkte	Tabellen

QS	PM	Abbildungen

QS-Plan	(QPl_)

Prüfplan	(PrPl_)

Prüfspezifikation	(PrSpez_)

Prüfprozedur	(PrProz_)

Prüfprotokoll	(PrProt_)


Liste der Produkte im Submodell KM
SE	KM	Aktivitäten

Produkte	Tabellen

QS	PM	Abbildungen

KM-Plan	(KPl_)

Konfigurations-Identifikationsdokument	(KID_)

Änderungsformulare

Änderungsantrag/Problemmeldung	(ÄA_)

Änderungsvorschlag	(ÄVor_)

Änderungsauftrag	(ÄAuf_)

Änderungsmitteilung	(ÄMit_)

Änderungsstatusliste	(ÄStat_)

Projekthistorie	(PHis_)


Liste der Produkte im Submodell PM
SE	KM	Aktivitäten

Produkte	Tabellen

QS	PM	Abbildungen

Projekthandbuch	(PHb_)

Projektplan	(PPl_)

Angebotsbewertung	(AnBew_)

Kosten-/Nutzenanalyse	(KNA_)

Arbeitsauftrag	(ArbAuf_)

Berichtsdokumente

Protokoll	(Prot_)

Sachstandsbericht	(SStB_)

Projektabschlußbericht	(PAB_)

Sachbericht	(SaB_)

Aktennotiz	(AktNo_)

Interne Mitteilung	(IntMit_)

Einladung	(Einl_)


Liste aller Tabellen
Aktivitäten	Tabellen

Produkte	Abbildungen

AU250/1

Tabelle 5.1:	Beteiligung von Rollen bei den Prüfaktivitäten

Tabelle 8.1:	Beispiel einer Aktivitäten-/Produktübersicht

Tabelle 8.2:	Beispiel einer Methoden-/Werkzeugzuordnung

AU250/2

Tabelle 2.1:	Regelzuordnung von Aktivitäten des V-Modells zu den Phasen des AU 220

Tabelle 3.1:	Mindestbedarf an Dokumentation für die Erstellung von Prototypen

Tabelle 4.1:	Gegenüberstellung Anwenderforderungen vs. Systemanforderungen

Tabelle 6.1:	Zuordnung der Phasen und der Stufenentscheidungen/Phasendokumente

Tabelle 7.1:	Baselines gemäß STANAG 4159 und zugehörige Produkte des V-Modells

Tabelle 7.2:	Konfigurationsmanagement-Plan gemäß STANAG 4159 und Entsprechung im V-Modell

Tabelle A.1:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 1 (Regelfall)

Tabelle A.2:	Taktisches Konzept und Produkte des V-Modells

Tabelle A.3:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 2 (Regelfall)

Tabelle A.4:	Taktisch-Technische Forderung und Produkte des V-Modells

Tabelle A.5:	Aktivitäten und Arbeitsschritte in der Definitionsphase Wehrmaterial (Regelfall)

Tabelle A.6:	Endgültigen Spezifikationen und Produkte des V-Modells

Tabelle A.7:	Militärisch-Technisch-Wirtschaftliche Forderung und Produkte des V-Modells

Tabelle A.8:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase Wehrmaterial (Regelfall)

Tabelle A.9:	Aktivitäten und Arbeitsschritte im Phasenvorlauf DV-Vorhaben (Regelfall)

Tabelle A.10:	Informationsversorgungskonzept und Produkte des V-Modells

Tabelle A.11:	Organisatorisch-Technische Forderung und Produkte des V-Modells

Tabelle A.12:	Aktivitäten und Arbeitsschritte in der Definitionsphase DV-Vorhaben (Regelfall)

Tabelle A.13:	Realisierungsplan und Produkte des V-Modells

Tabelle A.14:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase DV-Vorhaben (Regelfall)

Tabelle A.15:	Aktivitäten und Arbeitsschritte in der Einführungsphase DV-Vorhaben (Regelfall)

AU250/3 - ISO

Tabelle ISO.1:	Abdeckung der ISO 9001 durch das V-Modell

Tabelle ISO.2:	Entsprechungen des V-Modells zum QS-Plan des AQAP-150

Tabelle ISO.3:	Zuordnung der Primary Processes zu Aktivitäten des V-Modells

−	Acquisition Process

−	Supply Process

−	Development Process (1)

−	Development Process (2)

−	Operation Process

−	Maintenance Process

Tabelle ISO.4:	Zuordnung der Supporting Processes zu Aktivitäten des V-Modells

−	Documentation Process

−	Configuration Management Process

−	Quality Assurance Process

−	Verification Process

−	Validation Process

−	Joint Review Process

−	Audit Process

−	Problem Resolution Process

Tabelle ISO.5:	Zuordnung der Organizational Processes zu Aktivitäten des V-Modells

−	Management Process

−	Infrastructure Process

−	Improvement Process

−	Training Process

AU250/3 - OOS

Tabelle OOS.1:	Zuordnung von Ada-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.2:	Zuordnung von C++-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.3:	Zuordnung von OO-COBOL-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.4:	Zuordnung von FORTRAN-Sprachelementen zur Erzeugnisstruktur

AU250/3 - R

Tabelle R.1:	Rollen im V-Modell

Tabelle R.2:	Beteiligungsarten

Tabelle R.3:	Aktivitäten/Rollen-Matrix für PM

Tabelle R.4:	Aktivitäten/Rollen-Matrix für QS

Tabelle R.5:	Aktivitäten/Rollen-Matrix für KM

Tabelle R.6:	Aktivitäten/Rollen-Matrix für SE

AU250/3 - SI

Tabelle SI.1:	Festlegung von Kritikalität für technische Systeme

Tabelle SI.2:	Festlegung von Kritikalität für administrative Informationssysteme

Tabelle SI.3:	Festlegung von Kritikalität für Realzeitanwendungen

Tabelle SI.4:	Beispiel einer Kritikalitäten/Methoden-Matrix

AU250/3 - T

Tabelle T.1:	Mindestanforderungen im Submodell SE

Tabelle T.2:	Mindestanforderungen in den Submodellen QS, KM und PM


Liste aller Abbildungen
Aktivitäten	Tabellen

Produkte	Abbildungen

AU250/1

Abbildung 2.1:	Erzeugnisstruktur und Anwendungsbereich des V-Modells

Abbildung 2.2:	Randbedingungen zur IT-Systemerstellung

Abbildung 2.3:	Symbole für Aktivitäten und Produkte

Abbildung 2.4:	Zulässige Zustandsübergänge von Produkten

Abbildung 2.5:	Muster eines Produktflusses (Aktivität SE 2.4 "Anwenderforderungen zuordnen")

Abbildung 2.6:	Zusammenspiel der Submodelle

Abbildung 2.7:	Produkte des V-Modells (Produktbaum)

Abbildung 3.1:	Planung einer Systementwicklung

Abbildung 4.1:	Funktionsüberblick Submodell SE

Abbildung 5.1:	Konstruktive und analytische Maßnahmen

Abbildung 5.2:	Begriffshierarchie Prüfung

Abbildung 5.3:	Mögliche Stufen der Abwicklung von Selbstprüfungen

Abbildung 5.4:	Funktionsüberblick Submodell QS

Abbildung 6.1:	Zulässige Zustandsübergänge von zu entwickelnden Produkten

Abbildung 6.2:	Status einer Änderung

Abbildung 6.3:	Funktionsüberblick Submodell KM

Abbildung 7.1:	Funktionsüberblick Submodell PM

AU250/2

Abbildung 1.1:	Zuordnung von Wehrmaterial und DV-Vorhaben zu AU 220 und AU 250

Abbildung 1.2:	Zusammenhang IT-Leitlinie, AU 220 (Teil III, EEDV) und AU 250

Abbildung 1.3:	Anwendung des V-Modells bei der Vergabe von Einzelaufträgen

Abbildung 2.1:	SE-Aktivitäten und die Phasen des EEDV bei einer inkrementeller Entwicklung

Abbildung 2.2:	Forderungscontrolling

Abbildung 5.1:	Vorgehensweisen bei der Produktfortschreibung

AU250/3 - GPO

Abbildung GPO.1:	Geschäftsprozesse, IT-Systeme und V-Modell

Abbildung GPO.2:	Organisationsentwicklung vs. "Business Process Reengineering"

Abbildung GPO.3:	Aufbau und Analyse von Geschäftsprozessen

AU250/3 - ISO

Abbildung ISO.1:	Zusammenhang der Qualitätsstandards

Abbildung ISO.2:	Beziehungen der Standards und ihrer Ausprägung

Abbildung ISO.3:	Die Prozesse der ISO 12207

AU250/3 - SI

Abbildung SI.1:	SE- und QS-Zusammenarbeit bezüglich der Kritikalität

AU250/3 - SZ

Abbildung SZ.1:	Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung

Abbildung SZ.2:	PM-Zyklus bei einer inkrementellen Entwicklung

Abbildung SZ.3:	Ablauf der SE-Aktivitäten beim Grand Design

Abbildung SZ.4:	Ablauf der SE-Aktivitäten bei einem Einsatz von Fertigprodukten

Abbildung SZ.5:	Ablauf der SE-Aktivitäten bei einer objektorientierten Entwicklung

Abbildung SZ.6:	Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme

Abbildung SZ.7:	Vorgehensweisen bei der Produktfortschreibung

Abbildung SZ.8:	Ablauf der SE-Aktivitäten bei der Durchführung einer Pflege/Änderung

AU250/3 - T

Abbildung T.1:	Beispiel für die unterschiedliche Relevanz von Regelungen

Abbildung T.2:	Anwendung des Tailoring

Abbildung T.3:	Klassifizierung der Vorhabentypen

Abbildung T.4:	Anwendung der Streichbedingungen

Abbildung T.5:	Erstellung, Prüfung und Dokumentation des projektspezifischen V-Modells

Abbildung T.6:	Darstellung der unterschiedlichen Tailoringverfahren

Abbildung T.7:	Beispiel einer Aktivitätenanpassung

Abbildung T.8:	Vorhabentypen und Merkmalswerte

Abbildung T.9:	Prinzipieller Aufbau der Tailoring-Formblätter

Abbildung T.10:	SE für kleine administrative IT-Vorhaben

Abbildung T.11:	SE für mittlere administrative IT-Vorhaben

Abbildung T.12:	QS und KM für kleine und mittlere administrative IT-Vorhaben

Abbildung T.13:	SE für große administrative IT-Vorhaben

Abbildung T.14:	QS und KM für große administrative IT-Vorhaben

Abbildung T.15:	SE für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Abbildung T.16:	QS und KM für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Abbildung T.17:	SE für große technisch-wissenschaftliche IT-Vorhaben

Abbildung T.18:	QS und KM für große technisch-wissenschaftliche IT-Vorhaben

Abbildung T.19:	SE für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Abbildung T.20:	QS und KM für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Abbildung T.21:	PM für kleine und mittlere IT-Vorhaben

Abbildung T.22:	PM für große IT-Vorhaben

AU250/3 - UMF

Abbildung UMF.1:	Beispiel eines zeitlichen Aktivitätenverlaufs

Abbildung UMF.2:	V-Modell-Einsatz in unterschiedlichen Situationen

Abbildung UMF.3:	Geltungsbereich des Gesamt-Projekthandbuchs

Abbildung UMF.4:	Geltungsbereich zweier HAN-Projekthandbücher

Abbildung UMF.5:	Geltungsbereich der Projekthandbücher


Änderungsnachweis

Änderungsnachweis	AU250/1

Änderungsnachweis	AU250/2

Änderungsnachweis	AU250/3

Änderung	Geändert	Unterschrift
Nr.	Datum	von (Dienststelle), am (Datum)


Änderungsantrag / Problemmeldung

Änderungsantrag / Problemmeldung


Vorbemerkungen (Regelungsteil)
Teil 1	Vorgehensmodell / Regelungsteil

Vorbemerkungen

Mit dem Entwicklungsstandard für IT-Systeme des Bundes (EStdIT) werden alle Tätigkeiten und Ergebnisse der Entwicklung und der Pflege/Änderung von IT-Systemen geregelt. Diese Standardisierung erfolgt auf drei Ebenen:

−	Vorgehensweise,

−	anzuwendende Methoden,

−	funktionale Anforderungen an einzusetzende Werkzeuge.

Dieser Standard gilt als Ergänzung zum AU 220 als technische Richtlinie. Er wendet sich an den durchführenden Bereich mit dem Ziel, die Vielfalt der eingesetzten Methoden und Werkzeuge einzuschränken.

Er gilt für die Entwicklung von IT-Systemen in der Bundeswehr. Dazu zählen auch IT-Anteile in Systemen, unabhängig davon, ob Software im eigenen Bereich oder im Rahmen einer Auftragsvergabe durch die Industrie entwickelt wird.

Werden marktgängige Komponenten als Lösungskern bzw. als Systemlösungen verwendet, so sind diese als Fertigprodukte entsprechend den Regelungen des V-Modells zu behandeln (siehe hierzu Abschnitt 3 und Teil 3 "Handbuchsammlung").

Unterliegen Softwareprodukte nicht der Software-Pflege/-Änderung (SWPÄ) durch die Bundeswehr gemäß Erlaß BMVg-Org 1, Az 10-02-05 vom 17.05.1989 (VMBl 1989, S. 189) (z. B. marktgängige Standard-Anwendungssoftware), ist die Industrie insoweit nicht an den Entwicklungsstandard des Bundes gebunden. Dies gilt nicht bei Vorliegen besonderer sicherheitsrelevanter bzw. qualitativer Anforderungen.

Für die Entwicklung individueller IT-Systeme ist die Anwendung des V-Modells nicht zwingend vorgeschrieben.

Für die in Entwicklung bzw. in Nutzung befindlichen IT-Vorhaben ist im Einzelfall zu entscheiden.

Auf der Grundlage des Standards und unter Berücksichtigung des jeweiligen IT-Umfeldes sind vom jeweils Zuständigen für die einzelne Systementwicklungs-/SWPÄ-Einrichtung der Bundeswehr Werkzeuge zu implementieren und in Softwareentwicklungsumgebungen (SEU) zusammenzufassen. Dabei ist darauf zu achten, daß die Funktionalen Werkzeuganforderungen erfüllt werden.

Bereits vorhandene Softwareentwicklungsumgebungen dieser Einrichtungen sind auf Dauer mit den Funktionalen Werkzeuganforderungen in Einklang zu bringen.

Bei Auftragsvergabe und Nutzung Auftragnehmer-eigener Softwareentwicklungsumgebungen ist die Erfüllung der Funktionalen Werkzeuganforderungen nachzuweisen.

Bei der Anwendung dieser Regelungen sind folgende Standards zu beachten:

−	Allgemeiner Umdruck Nr. 220: Bestimmungen für Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben; September 1994.

−	BMVg-RüDV 1−62-05-06 vom 07.08.1989, Verwendung von Programmiersprachen in der Bundeswehr.

−	ISO 7498-1984, Information Processing Systems − Open Systems Interconnection − Basic Reference Model.

Die Veröffentlichungen des Entwicklungsstandards für IT-Systeme des Bundes erfolgen als Allgemeine Umdrucke:

Allgemeiner Umdruck Nr. 250	Vorgehensmodell
Teil 1:	Regelungsteil
Teil 2:	Behördenspezifische Ergänzungen
Teil 3:	Handbuchsammlung

Allgemeiner Umdruck Nr. 251	Methodenzuordnung
Anlage 1:	Erläuterungen
Anlage 2:	Komplexe Methoden

Allgemeiner Umdruck Nr. 252	Funktionale Werkzeuganforderungen
(Standardisierter Kriterienkatalog)
Anlage 1:	Erläuterungen

Der im V-Modell verwendete Begriff "Projekt" ist mit dem im Bundeswehrsprachgebrauch üblichen Begriff "Vorhaben" gleich zu setzen.

Die bei der Anwendung des V-Modells entstehenden technischen Ergebnisse gehen in die Stufenentscheidungen/Phasendokumente gemäß AU 220 ein. Der Zusammenhang zwischen V-Modell und AU 220 wird in Teil 2 "Behördenspezifische Ergänzungen" des Allgemeinen Umdrucks Nr. 250 erläutert.

IT-Anteile als integrierte Bestandteile eines Waffensystemes sind Teil des jeweiligen Vorhabens. Die Produkte, die für den IT-Anteil nach V-Modell erstellt werden, sind Bestandteile der Dokumentation des Gesamtvorhabens.

Die Allgemeinen Umdrucke sind Dienstvorschriften und als solche zu behandeln, zu vereinnahmen und nachzuweisen. Sie sind bei den Dienstvorschriftenstellen anzufordern. Ergänzungslieferungen halten den Inhalt auf dem aktuellen Stand.

Fachliche Änderungs- oder Ergänzungsvorschläge sind auf beiliegendem Änderungsantrags-/Problemmeldungs-Formular an

BWB IT I 5
Postfach 7360
56057 Koblenz

zu schicken. Die weitere Bearbeitung erfolgt im Rahmen eines geregelten Änderungsverfahrens. Telefonische Rückfragen sind zu richten an BWB IT I 5.


Vorbemerkungen (Behördenspezifische Ergänzungen)
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

Vorbemerkungen

Der Entwicklungsstandard für IT-Systeme des Bundes (EStdIT) besteht aus folgenden drei Teilen:

−	Allgemeiner Umdruck Nr. 250 "Vorgehensmodell" (Beschreibung der Aktivitäten und Produkte als Antwort auf die Frage "was" getan wird),

−	Allgemeiner Umdruck Nr. 251 "Methodenzuordnung" (Beschreibung der Mindestanforderungen an Methoden zur Beantwortung der Frage "wie" es getan wird),

−	Allgemeiner Umdruck Nr. 252 "Funktionale Werkzeuganforderungen" (Standardisierter Kriterienkatalog zur Werkzeugauswahl, der angibt "womit" etwas getan wird).

Der Allgemeine Umdruck Nr. 250 "Vorgehensmodell" besteht aus den folgenden Teilen:

Teil 1:	Regelungsteil
Teil 2:	Behördenspezifische Ergänzungen
Teil 3:	Handbuchsammlung

Teil 1 "Regelungsteil" ist die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen.

Teil 3 "Handbuchsammlung" enthält Erläuterungen zu verschiedenen Themen.

Teil 2 "Behördenspezifische Ergänzungen" beschreibt die Einbindung in den organisatorischen Rahmen und die Ablaufregelungen, die durch den Allgemeinen Umdruck Nr. 220 "Bestimmungen für die Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben" gegeben sind (Abschnitte 1 und 2). Darüber hinaus ist in Abschnitt 1 die Einbettung des V-Modells in das IT-Regelwerk des Bundes aufgezeigt. Weiterhin werden spezielle Hilfen für das amtsseitige Vorhabenmanagement gegeben (Abschnitte 3 bis 7).

Teil 2 "Behördenspezifische Ergänzungen" wird bei Änderung/Ergänzung des AU 220 unverzüglich diesem angepaßt.

Während sich Teil 1 "Regelungsteil" und Teil 3 "Handbuchsammlung" an alle Vorhabenbeteiligten sowohl auf Auftraggeber- als auch Auftragnehmerseite wenden, richtet sich Teil 2 "Behördenspezifische Ergänzungen" speziell an das amtsseitige Vorhabenmanagement.


Vorbemerkungen (Handbuchsammlung)
Teil 3	Vorgehensmodell / Handbuchsammlung

Vorbemerkungen

Der Entwicklungsstandard für IT-Systeme des Bundes (EStdIT) besteht aus folgenden drei Teilen:

−	Allgemeiner Umdruck Nr. 250 "Vorgehensmodell" (Beschreibung der Aktivitäten und Produkte als Antwort auf die Frage "was" getan wird),

−	Allgemeiner Umdruck Nr. 251 "Methodenzuordnung" (Beschreibung der Mindestanforderungen an Methoden zur Beantwortung der Frage "wie" es getan wird),

−	Allgemeiner Umdruck Nr. 252 "Funktionale Werkzeuganforderungen" (Standardisierter Kriterienkatalog zur Werkzeugauswahl, der angibt "womit" etwas getan wird).

Der Allgemeine Umdruck Nr. 250 "Vorgehensmodell" besteht aus den folgenden Teilen:

Teil 1:	Regelungsteil
Teil 2:	Behördenspezifische Ergänzungen
Teil 3:	Handbuchsammlung

Teil 1 "Regelungsteil" ist die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen.

Teil 3 "Handbuchsammlung" enthält Erläuterungen zu verschiedenen Themen. Die Handbuchsammlung wird bei Bedarf um weitere Handbücher ergänzt (unabhängig von der Herausgabe einer neuen Version des V-Modells). Die Handbücher sollen Hilfestellung bei der Arbeit mit dem V-Modell geben. Sie haben dementsprechend keinen Regelungscharakter.

Die einzelnen Handbücher sind zur einfachen Abgrenzung untereinander mit bis zu dreistelligen Buchstabenkürzeln versehen (siehe Inhaltsverzeichnis). Sie sind in der vorliegenden Handbuchsammlung alphabetisch sortiert.

Im einzelnen werden die folgenden Themen behandelt:

−	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

Dieses Handbuch stellt dar, wie das V-Modell die Forderungen des Bundesrechnungshofes (BRH) abdeckt und welche V-Modell-Aktivitäten und -Dokumente den BRH-Forderungen entsprechen.

−	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

Dieses Handbuch erläutert Zusammenhänge zwischen der Geschäftsprozeßoptimierung und dem V-Modell.

−	Hardwareerstellung

Dieses Handbuch beschreibt das operative Modul "Hardwareerstellung" zur Entwicklung von HW-Einheiten.

−	Das V-Modell in einer ISO- und AQAP-Umgebung

Dieses Handbuch behandelt die Anwendung des internationalen, weltweit gültigen Qualitätsstandards ISO 9001 und der AQAP-Normen. Es wird gezeigt, welche Rolle das V-Modell als Prozeßmodell spielt und wie das V-Modell die Forderungen der beiden QS-Standards erfüllt oder welche Zusatzforderungen erfüllt werden müssen. Weiter wird durch eine Zuordnungstabelle dargestellt, wie die Prozesse der ISO 12207 (Software Life Cycle Processes) durch die Aktivitäten des V-Modells abgedeckt werden.

−	Berücksichtigung objektorientierter Sprachen

Dieses Handbuch geht nach einer grundsätzlichen Betrachtung der Auswirkungen des Einsatzes objektorientierter Sprachen im V-Modell exemplarisch besonders auf die Sprachen Ada 95 und C++ ein. Es wird dargestellt, wie die Arbeits- und Unterstützungshilfen des V-Modells beim Einsatz objektorientierter Sprachen umgesetzt werden sollen. Insbesondere wird gezeigt, wie die Erzeugnisstruktur des V-Modells als Strukturierungshilfe für objektorientierte System- und SW-Entwürfe eingesetzt werden kann.

−	Rollenkonzept im V-Modell

Dieses Handbuch nennt für jedes Submodell eine Menge von Rollen, deren Rolleninhaber entsprechend fest definierter Rollen/Aktivitäten-Zuordnungen Aktivitäten bearbeiten.

−	Reverse Engineering

Dieses Handbuch beschreibt das operative Modul "Reverse Engineering". Handelt es sich um ein Reverse-Engineering-Projekt, so kann das gesamte Submodell SE durch dieses operative Modul ausgetauscht werden.

−	Anwendung des V-Modells und der ITSEC

In diesem Handbuch werden die Aktivitäten und Produkte genannt, die für die Evaluation von Systemen relevant sind. Es wird beschrieben, was bei den einzelnen Aktivitäten speziell unter dem Aspekt Evaluation zu tun ist bzw. welche Inhalte bei den Produkten für die Evaluation erwartet werden.

−	Sicherheit und Kritikalität

Dieses Handbuch enthält Erläuterungen zur Behandlung der Sicherheit und der Kritikalität. Beispiele für Kritikalitätsstufen werden vorgestellt.

−	Szenarien

Dieses Handbuch illustriert die Anwendung des V-Modells im Rahmen unterschiedlicher Entwicklungsstrategien. Als Regelfall einer Systementwicklung wird die inkrementelle Entwicklungstrategie erläutert.

−	Tailoring und projektspezifisches V-Modell

Dieses Handbuch beschreibt die Funktionsweise des Ausschreibungsrelevanten und Technischen Tailoring. Neben einem standardisierten Vortailoring für einzelne Vorhabentypen werden Beispiele möglicher Streichbedingungen vorgestellt.

−	Einordnung des V-Modells in sein Umfeld

Dieses Handbuch erläutert Zielsetzung und Konzeption des V-Modells. Mögliche Verwendungsformen des V-Modells werden skizziert.


Informationen zum Drucken

Einzelne Kapitel der Online-Hilfe können mittels der im Pulldown-Menü "Datei" enthaltenen Funktion "Thema drucken..." ausgedruckt werden. Der Ausdruck enthält lediglich den Textkörper der Hypertextversion ohne Seitenumbrüche und ohne Informationen der gedruckten Version des Vorgehensmodells in Kopf- und Fußzeilen. Unter Windows 95 ist diesselbe Funktionalität auch über die Schaltfläche "Drucken" zu erreichen.

Beliebige Bereiche des Vorgehensmodells können mittels des Textverarbeitungssystems Winword gedruckt werden. Die dazu benötigten Quelltexte des Vorgehensmodells sind auf der CD-ROM "V-Modell 97" in und unterhalb dem Verzeichnis "...\VM-97\EStdIT\" abgelegt. Weitere Informationen zur Ablagestruktur der Daten (Dateien im Format Winword 6) entnehmen Sie bitte der Online-Hilfe "Struktur.hlp" im oben genannten Verzeichnis.


Methodenzuordnung

Der Allgemeine Umdruck Nr. 251 "Methodenzuordnung" liegt nicht als Hypertext vor. Der vollständige Quelltext der "Methodenzuordnung" ist jedoch auf der CD-ROM "V-Modell 97" in und unterhalb dem Verzeichnis "...\VM-97\EStdIT\" abgelegt. Weitere Informationen zur Ablagestruktur der Daten (Dateien im Format Winword 6) entnehmen Sie bitte der Online-Hilfe "Struktur.hlp" im oben genannten Verzeichnis.


Funktionale Werkzeuganforderungen

Der Allgemeine Umdruck Nr. 252 "Funktionale Werkzeuganforderungen" liegt nicht als Hypertext vor. Der vollständige Quelltext der "Funktionalen Werkzeuganforderungen" ist jedoch auf der CD-ROM "V-Modell 97" in und unterhalb dem Verzeichnis "...\VM-97\EStdIT\" abgelegt. Weitere Informationen zur Ablagestruktur der Daten (Dateien im Format Winword 6) entnehmen Sie bitte der Online-Hilfe "Struktur.hlp" im oben genannten Verzeichnis.


Thema nicht vorhanden
Interne Information der Entwicklungsversion

Sie gelangen durch Eingabe von "z"

oder

Drücken der Zurück-Taste zum Text zurück


Thema nicht vorhanden
     Dieses Thema ist zur Zeit nicht implementiert.


Abnahme

Mit der erfolgreichen Abnahme wird der Auftragnehmer entlastet, und das abgenommene Produkt geht in das Eigentum des Auftraggebers über. Die Abnahme ist ein juristisch definierter Vorgang.


Änderbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf den Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist.


Akquisition

Alle Maßnahmen, die zur Beschaffung, Abwicklung der Entwicklungsschritte, Betrieb und Außerbetriebstellung eines Systems oder von Systemteilen im Rahmen des gesamten Lebenszyklus notwendig sind.


Aktivität

Im V-Modell geregelte Tätigkeit. Sie wird eindeutig durch ihre Abwicklung und ihre Ergebnisse beschrieben.


Aktivitätenklasse

Synonym: Aktivitätentyp

Eine Reihe von Aktivitäten im V-Modell werden im Rahmen eines konkreten Projekts mehrfach durchgeführt (z. B. für jede einzelne Komponente, Modul, usw.). Diese Aktivitäten werden im V-Modell als sogenannte "Aktivitätenklassen" oder "generische Aktivitäten" nur einmal beschrieben. Eine tatsächlich durchgeführte Aktivität wird als "Instanz" (auch "Ausprägung") der (generischen) Aktivität bezeichnet.

Anmerkung:

Alle Aktivitäten des V-Modells sind generische Aktivitäten (d. h. Elemente einer Aktivitätenklasse), auch wenn es einige Aktivitäten gibt, die nur einmal durchgeführt werden (z. B. SE 1, QS 1, KM 1, PM 1)


Aktivitätenschema

Schema zur Beschreibung einer Aktivität im V-Modell. Zu jeder Aktivität werden Name, Produktfluß und Abwicklung angegeben, gegebenenfalls zusätzlich Empfehlungen und Erläuterungen.


Aktivitätenzerlegung

Grafische Darstellung der hierarchischen Zerlegung von Aktivitäten.


Anwender

(Quelle: in Anlehnung an den Entwurf DIN 66285 "Anwendungssoftware")

Eine organisatorische Einheit, die die Verfügungsgewalt über die Sache erhalten soll, deren Entstehen der Zweck des jeweiligen Vorhabens ist.


Anwenderforderungen

Alle vom Anwender vorgegebenen fachlichen Anforderungen an das System und die zugehörigen Randbedingungen.


Ausbaustufe

Synonym: Inkrement

Operationell einsetzbarer Zwischenstand der Entwicklung an einem Meilenstein im Rahmen einer inkrementellen Entwicklung.


Ausbildungs-Software

Software zur Schulung der Nutzer des operationellen Systems.


Austauschbare Einheit

Engl. "Replaceable Unit"

Eine austauschbare Einheit ist ein HW-Baustein, der gegen einen bevorrateten oder nachlieferbaren Baustein ausgetauscht werden kann.


Baseline

Als "Baseline" wird eine genau spezifizierte Menge an Produkten (Dokumente, Software und Hardware) zu einem definierten Zeitpunkt verstanden, die im Rahmen des Konfigurationsmanagements verwaltet werden und die eine verläßliche Basis für das (arbeitsteilige) Weiterarbeiten bilden.

Hinweis:

Baselines markieren "Reifezustände" (Anforderungen, Lösungskonzept, Entwurf, Liefereinheit) eines Entwicklungsgegenstandes.


Bedrohung

Unter "Bedrohung" versteht man einen Umstand oder ein Ereignis, das die Einhaltung der Sicherheitspolitik und der Schutzziele an das IT-System gefährden kann.


Bedrohungsanalyse

In der Bedrohungsanalyse sind die für das System relevanten Bedrohungen unter Berücksichtigung der (vorgesehenen) Einsatzumgebung zu ermitteln und hinsichtlich ihrer Bedeutung (Art des zu erwartenden Schadens) zu bewerten.


Benutzbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken

−	auf den Aufwand, der zur Benutzung erforderlich ist und

−	auf die individuelle Beurteilung einer solchen Benutzung

durch eine festgelegte oder vorausgesetzte Gruppe von Nutzern.


Daten

Angaben, Tatsachen und Informationen oder deren kodierte Form.


Datenbank

Eine Datenbank ist die Menge der Daten, die gemäß den formalen Regeln eines zugehörigen Datenbankschemas organisiert sind und die durch ein Datenbanksystem verwaltet werden.


Datenbanksystem

Ein Datenbanksystem (Datenbank-Managementsystem, DBMS) übernimmt die technische Organisation und Bereitstellung von Daten, die in einer Datenbank abgelegt sind.


Datensicherheit

Zustand, bei dem Daten vor Beeinträchtigung bewahrt sind. Die Beeinträchtigung kann durch unerlaubtes Lesen, Kopieren, Modifizieren oder Löschen der Daten geschehen.

(Die Datensicherheit ist von der Systemsicherheit zu unterscheiden.)


Datenstruktur

Eine Datenstruktur definiert die Gliederung der von einem System, Segment oder einer SW-Einheit/HW-Einheit benutzten Daten und deren Beziehungen untereinander.


Durchführungsplan

Darstellung der Reihenfolge, zeitlichen Lage und Dauer der Tätigkeiten, die zur Realisierung eines Vorhabens unter Berücksichtigung der notwendigen und/oder verfügbaren Einsatzmittel erforderlich sind. Als Grundlage dient der Strukturplan.


Effizienz

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf das Verhältnis zwischen dem Leistungsniveau der Funktionseinheit und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.


Einsatzmittel

Leistungsfaktoren wie Arbeitskräfte, Geräte, Maschinen und sonstige technische Anlagen und Hilfsmittel sowie Kombinationen hieraus, über die eine Stelle verfügt und die bei der Erbringung einer Leistung nicht verbraucht, sondern nur in Anspruch genommen und zur Durchführung eines Vorhabens benötigt werden.


Element der Systemarchitektur

Synonym: Funktionseinheit, Baustein

Ein nach Aufgabe oder Wirkung abgrenzbares Gebilde.

Ein Element kann ein System, ein Segment, eine SW-Einheit/HW-Einheit, eine SW-Komponente, ein SW-Modul oder eine Datenbank sein.


Evaluation

Prüfung und Bewertung eines Systems anhand der IT-Sicherheitskriterien. Die Evaluationsstellen können neben der Evaluation eines fertigen Produkts auch begleitende Evaluationen durchführen, d. h. die einzelnen Prüfschritte werden während des Entwicklungsprozesses durchgeführt, sobald die entsprechenden Zwischenergebnisse den Zustand "akzeptiert" haben.


Evolutionäre Akquisition

Synonym: Evolutionäres Prototyping

Auf der Basis einer ersten Version der Anwenderforderungen, die den funktionalen Systemkern beschreibt und den Gesamthorizont des Systems vorgibt, wird eine operative, erste Systemversion akquiriert.

Zukünftige Ergänzungen und Änderungen der Anwenderforderungen sind zu diesem Zeitpunkt nicht vollständig absehbar.

Die erste Systemversion wird in weiteren Akquisitionsschritten bis zum endgültigen System ausgebaut, wobei die Anwenderforderungen in allen Teilen ergänzt und geändert werden können.


Exploratives Prototyping

Entwicklung eines Prototypen als Kommunikationsmedium. Im direkten Meinungsaustausch mit dem Anwender werden anhand des Prototypen die Anwenderforderungen verfeinert, ergänzt und geklärt.


Experimentelles Prototyping

Entwicklung, um durch Versuche technische Eigenschaften eines Systems oder Systemteils (z. B. als Entscheidungsgrundlage) zu ermitteln.


Fehlverhalten

−	Funktionsversagen, d. h. Versagen einer Funktionseinheit bei ihrer Ausführung,

−	Funktionsunterlassung, d. h. Unterlassung einer erforderlichen Ausführung oder

−	modifizierte Ausführung (z. B. Mehrfunktionalität).


Fertigprodukt

Komplett verfügbare Funktionseinheit (verfügbar im eigenen Unternehmen, im Amtsbereich oder auf dem Markt).


Festspeicher

Speicher, dessen Inhalt betriebsmäßig nicht geändert werden kann.


Firmware

Computerbefehle oder -daten, die als nur lesbare Information in einem Festspeicher gespeichert sind.


Forderungscontrolling

Das Forderungscontrolling analysiert die aufgestellten Anwenderforderungen hinsichtlich Realisierbarkeit und Wirtschaftlichkeit und basiert zumindest auf ersten Architekturüberlegungen. Die Ergebnisse der Analyse führen gegebenenfalls zu Vorschlägen für Modifikation/Reduzierung von Anwenderforderungen.


Funktionalität

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf das Vorhandensein eines Satzes von Funktionen und auf deren festgelegte Eigenschaften. Die Funktionen sind jene, die die festgelegten oder vorausgesetzten Erfordernisse erfüllen.

Anmerkung:

Diese Menge von Eigenschaften charakterisiert, was eine Funktionseinheit zur Erfüllung von Erfordernissen tut, während die anderen Qualitätsmerkmale hauptsächlich charakterisieren, wann und wie sie das tut.


Funktionseinheit

Synonym: Element der Systemarchitektur

Ein nach Aufgabe oder Wirkung abgrenzbares Gebilde.

Eine Funktionseinheit kann ein System, ein Segment, eine SW-Einheit/HW-Einheit, eine SW-Komponente, ein SW-Modul oder eine Datenbank sein.


Funktionsstruktur

Eine Funktionsstruktur definiert die (statische) Gliederung der Funktionalität eines Systems, Segments oder einer SW-Einheit/HW-Einheit in Funktionen.


Gesamthorizont

Fachliche, anwenderorientierte Beschreibung des Funktionsumfangs des IT-Systems unter Nennung der darin enthaltenen (Funktions-) Bereiche (z. B. Mail, Nutzerverwaltung). Die Beschreibung muß so detailliert sein, daß darüber entschieden werden kann, welche Funktionsteile innerhalb des Gesamthorizonts liegen.


Geschäftsprozeß

Kette der Aufgaben, die ein geschäfts- bzw. aufgabenrelevantes Ergebnis erzeugen (Arbeitsgangfolge).


Hardware

Gesamtheit oder Teil der apparativen Ausstattung von Datenverarbeitungssystemen.


Hardware-Einheit (HW-Einheit)

Element der Erzeugnisstruktur, das ausschließlich aus Hardware besteht.


Hauptaktivität

Aktivität der obersten Ebene im V-Modell.


Hardware-Komponente (HW-Komponente)

Hardware-Baustein einer HW-Einheit. HW-Komponenten können ihrerseits andere HW-Komponenten und HW-Module enthalten.

Hinweis:

Die Definition wurde in Analogie zu "SW-Komponente" getroffen.


Hardware-Modul (HW-Modul)

HW-Module sind die kleinsten Bausteine einer HW-Einheit, deren Behandlung noch durch das V-Modell geregelt wird.

Hinweis:

Der Begriff wurde in Analogie zur Definition von "SW-Modul" getroffen. HW-Module grenzen sich von HW-Bauteilen (unterste Betrachtungsebene; nicht mehr durch das V-Modell geregelt) dadurch ab, daß sie im Rahmen einer Entwicklung tatsächlich bearbeitet werden, d. h. sie haben insbesondere die Bearbeitungszustände "geplant", "in Bearb.", "vorgelegt", "akzeptiert" gemäß V-Modell.


Individuelles IT-System

Ein individuelles IT-System zeichnet sich durch folgende Bedingungen aus:

−	Es wird nur vom Ersteller selbst genutzt.

−	Es operiert auf Datenbeständen, über die der Ersteller die alleinige Verantwortlichkeit hat.

−	Es wird ausschließlich auf der Hardware des Erstellers eingesetzt.

−	Es hat keine besonderen sicherheitsrelevanten bzw. qualitativen Anforderungen zu berücksichtigen.


Inkrementelle Entwicklung

Synonym: Inkrementelles Prototyping

Stufenweise Entwicklung eines Systems (oder von Systemteilen) auf der Basis insgesamt gefestigter Anwenderforderungen.


Instanz, Instantiierung

Bevor eine im V-Modell beschriebene (generische) Aktivität durchgeführt wird, muß sie instantiiert (ausgeprägt) werden. Das Ergebnis der Instantiierung ist die Instanz. Eine Instanz ist der konkrete Bezug einer Aktivität auf ein bestimmtes Objekt (z. B. Modul, Komponente, usw.).

Oben angeführtes gilt auch für Produkte.

Anmerkung:

Werden beispielsweise in Aktivität SE 2 "System-Entwurf" drei SW-Einheiten identifiziert, so muß die Aktivität SE 3 "SW-/HW-Anforderungsanalyse" dreimal instantiiert werden (für jede SW-Einheit separat).


IT-System

Siehe: System


IT-Sicherheitsanteil

(Quelle: ITSEC, angepaßt)

Die Gesamtheit aller Elemente der technischen Architektur, die zum Erreichen der IT-Sicherheitsziele und -anforderungen von Bedeutung sind.


Klassische Akquisition

Synonyme: Big Bang, Grand Design, One Shot

Auf der Basis vollständiger Anwenderforderungen wird ein System oder Systemteil in einem Schritt akquiriert.


Klassische Entwicklung

Synonyme: Wasserfallmodell, Traditionelle Entwicklung, Big Bang, One Shot

Auf der Basis vollständiger und verfeinerter Systemanforderungen wird ein System oder Systemteil in einem Schritt (phasenorientiert) entwickelt.


Konfiguration

Eine Konfiguration ist eine benannte und formal freigegebene Menge von Entwicklungsergebnissen, mit den jeweils gültigen Versionsangaben, die in ihrer Wirkungsweise und ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorgegebene Aufgabe erfüllen sollen.

Hinweise:

Als Entwicklungsergebnisse werden alle Ergebnisse betrachtet, die im Verlauf der SW-Entwicklung nach dem V-Modell entstehen, und nicht nur der freigegebene Code.
Der eindeutige Aufbau von Softwaresystemen erfolgt über eine Konfigurationen-Hierarchie, in der jedes Entwicklungsergebnis genau einer Konfiguration (z. B. durch Eintrag in eine entsprechende Liste) zugeordnet ist. Die Konfigurationen der oberen Ebene stützen sich auf unterliegende Konfigurationen ab. Konfigurationen sowie Versionen können selbst Teil in mehreren Konfigurationen sein.

Der Begriff "Konfiguration" wird oft mit dem Begriff "Rechnerkonfiguration" gleichgesetzt. Bei der Rechnerkonfiguration ist der Schwerpunkt die Ablauffähigkeit von Software beim Rechnereinsatz. Darüber hinaus sind aus SWPÄ-Gesichtspunkten für eine Konfiguration auch diejenigen Informationen relevant, die eine Rolle in der Entwicklung gespielt haben (z. B. die beteiligten Werkzeuge, Compiler, usw.). Dadurch wird sichergestellt, daß jederzeit auf einem konsistenten Stand der Entwicklung aufgesetzt werden kann.


Konfigurationseinheit (KE)

Eine Konfigurationseinheit ist Gegenstand der Aktivitäten des Konfigurationsmanagements (KM) mit abgrenzbaren und zu einem bestimmten Zeitpunkt definierten Eigenschaften (Beschaffenheit und Funktionalität), welche auf möglichst niedriger Ebene unter Berücksichtigung bestimmter Faktoren ausgewählt wird, um den Managementerfordernissen während der Entwicklung und/oder Nutzung zu genügen.

Anmerkung:

Beispiele solcher Faktoren sind Sicherheitsanforderungen, Kostenintensität, Änderungshäufigkeit, Fehlerrate, kommerzielle Verfügbarkeit.


Kritikalität

Die Kritikalität einer Einheit drückt aus, welche Bedeutung ihrem Fehlverhalten beigemessen wird.

Die Kritikalität wird in Stufen angegeben, wobei die Einstufung umso höher ist, je gravierendere Auswirkungen bei Fehlverhalten zu erwarten sind.

Anmerkung 1:

Den Kritikalitätsstufen kann ein zu vereinbarender Aufwand gegenübergestellt werden, der in die Realisierung und Prüfung der Einheit investiert werden muß.

Anmerkung 2:

Es ist zweckmäßig, die Kritikalitätsstufen individuell für die verschiedenen Arten von IT-Systemen zu definieren. Darüber hinaus kann es sinnvoll sein, diese Definitionen projektspezifisch (z. B. bzgl. Terminologie) anzupassen.


Lademodul

Softwarebaustein, der in den Speicher geladen werden kann und ablauffähig ist. Üblicherweise enthält das Lademodul hinzugebundene Bibliotheksroutinen.


Meilenstein

Bedeutungsvolles Ereignis (Fertigstellung vorbestimmter Produkte) im Vorhabenablauf, das sich terminlich planen und überwachen sowie zur Bewertung des Vorhabenfortschrittes einsetzen läßt.


Meilensteinplan

Grafische oder tabellarische Darstellung von Meilensteinen im Vorhabenablauf auf der Basis der Terminplanung.


Nachweis

(Quelle: DIN EN ISO 8402)

Information, deren Richtigkeit bewiesen werden kann und die auf Tatsachen beruht, welche durch Beobachtung, Messung, Untersuchung oder durch andere Ermittlungsverfahren gewonnen wird.


Nachweis-Software

Software zur Nachweisführung von Leistungen der operativen Software, der Hardware, des Segments mit IT-Anteil oder des Systems während der Integrationsaktivitäten.


Nutzer

(Quelle: in Anlehnung an den Entwurf DIN 66285 "Anwendungssoftware")

Ein Mensch, der unmittelbar mit einer Sache arbeitet und der Verfügungsgewalt von deren Anwender unterliegt.


Operationelles System

IT-System, das einen Systemauftrag erfüllt. Auf dem operationellen System läuft die operative Software.


Operative Aktivität

Aktivität aus dem Submodell SE oder aus einem operativen Modul.


Operative Software

Software, die zur Erfüllung eines Systemauftrages erforderlich (zur Nutzung des IT-Systems) und im operationellen System installiert ist.


Operatives Modul

Eine Menge von zusammengehörigen, abgrenzbaren Aktivitäten- und Produktklassen, die einen Ausschnitt aus den Regelungen des Submodells SE ersetzen können (Beispiel: Hardwareerstellung). Im Extremfall kann das Submodell SE vollständig ersetzt werden (Beispiel: Reverse Engineering).


Platzhalter

Programm oder Programmteil, das/der während der Integration dazu dient, gewisse Funktions- oder Leistungsmerkmale eines SW-Moduls, einer Datenbank, einer SW-Komponente oder einer SW-Einheit bereitzustellen. Im Sinne des V-Modells kann ein Platzhalter ein Stub oder ein Driver sein:

−	Ein Stub ist ein Platzhalter für ein SW-Modul oder eine oder mehrere SW-Komponenten in einer SW-Teilstruktur. Mit dem Platzhalter wird erreicht, daß die SW-Teilstruktur in gegebenenfalls eingeschränkter Weise übersetzbar oder ausführbar wird. Damit können informelle Prüfungen unter bestimmten Kriterien durchgeführt werden, ohne daß ein SW-Modul, eine SW-Komponente oder eine SW-Einheit komplett vorliegt.

−	Ein Driver (Treiber) ist ein Ablaufsteuerungsprogramm. Es ermöglicht die Ausführung und damit die informelle Prüfung von SW- Teilstrukturen, deren bestimmungsgemäße Ablaufumgebung noch nicht zur Verfügung steht.


Portabilität

Grad der Fähigkeit einer Software, auf andere Computer übertragen zu werden.


Produkt

Bearbeitungsgegenstand bzw. Ergebnis einer Aktivität des V-Modells (Dokument oder Software oder Hardware).


Produktklasse

Eine Reihe von Produkten im V-Modell wird im Rahmen eines konkreten Projekts mehrfach erstellt (z. B. für jede einzelne Komponente, Modul, usw.). Diese Produkte werden im V-Modell als sogenannte "Produktklassen" oder "generische Produkte" nur einmal beschrieben. Ein tatsächlich erstelltes Produkt wird als "Instanz" (auch "Ausprägung") des (generischen) Produkts bezeichnet.

Anmerkung:

Alle Produkte des V-Modells sind in der Regel generische Produkte (d. h. Elemente einer Produktklasse). Siehe auch "Instanz".


Produktprüfung

Prüfung, bei der für ein bestimmtes Produkt (z. B. Dokument, Quellcode, HW) gezeigt werden soll, daß die vorher festgelegten Forderungen erfüllt werden.


Produktschema

Beschreibungsschema, dem ein Produkt genügen muß. Insbesondere sind die Gliederung und der Inhalt des Produkts geregelt.


Produktzustand

Eigenschaft eines Produkts, die dessen Bearbeitungsstadium kennzeichnet. Der Wechsel des Produktzustands wird grundsätzlich durch eine Aktivität ausgelöst. Ein Produkt kann den Zustand "geplant", "in Bearb.", "vorgelegt" und "akzeptiert" annehmen.


Projekt

(Quelle: DIN 69901)

Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.

−	Zielvorgabe,

−	zeitliche, finanzielle, personelle oder andere Begrenzungen,

−	Abgrenzung gegenüber anderen Vorhaben,

−	projektspezifische Organisation.


Projektplanung

Verfahren zur Planung von Organisation, Abläufen, Terminen und Einsatzmitteln.


Prototyp

Eine ausführbare und evaluierbare Version eines Systems oder Systemteils (evolutionärer Prototyp) oder eines Werkzeugs, um ausgewählte Merkmale des späteren, operationellen Systems (explorativer oder experimenteller Prototyp) zu evaluieren.

Hinweis:

Für die Erstellung eines Prototypen wird nicht die Erfüllung der Regelungen des V-Modells gefordert. Bei der Integration des Prototypen in das operationelle System muß geklärt werden, welche Nacharbeiten zur Erfüllung der relevanten Anwenderforderungen (insbesondere der Qualitätsanforderungen) notwendig sind.


Prototyping

Vorgehensweise, deren Arbeitsschritte die Entwicklung, Evaluierung und Weiterentwicklung von Prototypen zum Gegenstand haben.


Prozeßprüfung

Synonym: Ablaufprüfung

(Quelle: DIN 55350)

Qualitätsprüfung an einem Prozeß bzw. an einer Tätigkeit anhand der Merkmale des Prozesses bzw. der Tätigkeit selbst.

Anmerkung 1:

Prozeßprüfungen dienen unter anderem der Verfahrensüberwachung.

Anmerkung 2:

Der Prozeß in dem hier verwendeten Sinne unterscheidet sich von dem "Software-Prozeß" innerhalb der operativen Software.


Prüfbarkeit eines HW-Bausteins

Die Prüfbarkeit eines HW-Bausteins gibt die Eignung oder den Grad der Eignung an, daß/inwieweit durch interne und/oder externe Prüfvorkehrungen festgestellt werden kann, ob der Baustein funktionstüchtig ist.


Prüfkriterien

Prüfkriterien sind Fragestellungen, die durch eine Prüfung geklärt werden sollen.

Bei der Prüfung von Papierprodukten sollten als Prüfkriterien Checklisten verwendet werden (Beispiele hierfür in Abschnitt 8 beim Produktmuster Prüfspezifikation).

Wichtig bei der Formulierung der Prüfkriterien ist, daß die Erfüllung des Kriteriums in der Prüfung entscheidbar ist.


Prüfung

(Quelle: DIN EN ISO 8402)

Eine Tätigkeit wie Messen, Untersuchen, Ausmessen von einem oder mehreren Merkmalen einer Einheit sowie Vergleichen mit festgelegten Forderungen um festzustellen, ob Konformität für jedes Merkmal erzielt ist.

Anmerkung:

Prüfung ist ein Oberbegriff für alle analytischen Maßnahmen, die Nachweischarakter haben, unabhängig von Methode oder Prüfgegenstand.


Pseudocode

Sprachliches Ausdrucksmittel für den Programmentwurf. Enthält üblicherweise Konstrukte der Strukturierten Programmierung und natürlichsprachliche Beschreibungen.


Qualifikation

(Quelle: DIN EN ISO 8402)

Prozeß um nachzuweisen, daß eine Einheit fähig ist, die spezifizierten Anforderungen zu erfüllen.


Qualität

(Quelle: DIN EN ISO 8402)

Die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.

Anmerkung 1:

Einheit kann sein: Tätigkeit, Prozeß, Produkt, System, Organisation, Person.

Anmerkung 2:

Das V-Modell beschränkt sich auf das jeweilige Vorhaben und die dafür festgelegten Anforderungen. Sollten im Verlauf des Vorhabens vorausgesetzte Anforderungen neu erkannt werden, sind diese wie Änderungen zu behandeln.


Qualitätsforderung

(Quelle: DIN EN ISO 8402)

Eine Formulierung der Erfordernisse oder deren Umsetzung in eine Serie von quantitativ oder qualitativ festgelegten Forderungen an die Merkmale einer Einheit zur Ermöglichung ihrer Realisierung und Prüfung.


Qualitätsmanagement

(Quelle: DIN EN ISO 8402)

Alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen.

Anmerkung:

Das V-Modell beschränkt sich auf einzelne Vorhaben. Deshalb ist im Einzelfall der Bezug zum QM-System zwar gegeben, aber im V-Modell nicht festgelegt.


Qualitätssicherung

(Quelle: DIN EN ISO 8402)

Alle geplanten und systematischen Tätigkeiten, die innerhalb des Qualitätsmanagementsystems verwirklicht sind, und die wie erforderlich dargelegt werden, um angemessenes Vertrauen zu schaffen, daß eine Einheit die Qualitätsforderung erfüllen wird.

Anmerkung: siehe Qualitätsmanagement


Qualitätsmaße

Meßbare Größen, die Rückschlüsse auf die Ausprägung bestimmter Qualitätsmerkmale gestatten.

(Beispiele: Antwortzeit für Funktion ... ist kleiner als ... Sekunden, Länge des Moduls ... ist kleiner als ... Seiten.)


Qualitätsmerkmale

(Quelle: in Anlehnung an DIN ISO 9126)

Eigenschaften einer Funktionseinheit, anhand derer ihre Qualität beschrieben und beurteilt wird, die jedoch nichts über den Grad der Ausprägung aussagen. Ein Qualitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden.

Qualitätsmerkmale sind Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.


Randbedingungen

Technische und organisatorische Vorgaben, die im Rahmen der Systemerstellung zu berücksichtigen sind. Randbedingungen können Entwurfsentscheidungen vorwegnehmen oder eingrenzen.


Risikoanalyse

In der Risikoanalyse wird untersucht, wie wahrscheinlich es ist, daß eine der ermittelten Bedrohungen wirksam wird und wie hoch der Schaden ist, der dabei entsteht. Das Risiko wird aus der Eintrittswahrscheinlichkeit und der zu erwartenden Schadenshöhe ermittelt.


Rolle

Eine Funktion, in der ein Bearbeiter eine bestimmte Aktivität ausführt.

Hinweis:

Durch die Festlegung von Rollen wird die Unabhängigkeit des V-Modells von organisatorischen und projektspezifischen Randbedingungen erreicht. Die Zuordnung von Organisationseinheiten und Personen zu den Rollen erfolgt zu Beginn eines Projekts.


Schnittstelle

Gedachter oder tatsächlicher Übergang an der Grenze zwischen zwei Funktionseinheiten mit den vereinbarten Regeln für die Übergabe von Daten oder Signalen.


Segment

Unterstruktur eines Systems. Es gibt Segmente mit IT-Anteil (auch: IT-Segment) und solche ohne IT-Anteil.


Selbstprüfung

(Quelle: DIN EN ISO 8402)

Prüfung des Arbeitsergebnisses durch den Ausführenden selbst gemäß festgelegter Regeln.

Anmerkung:

Selbstprüfungen finden im Rahmen des Submodells SE statt.


Software

Programme für Datenverarbeitungssysteme, die zusammen mit deren Eigenschaften zusätzliche Betriebsarten oder Anwendungsarten ermöglichen. Software umfaßt die Computerprogramme mit den zugehörigen Daten und der Dokumentation.


Softwarebaustein

Ein nach Aufbau oder Zusammensetzung abgrenzbares programmtechnisches Gebilde. Ein Softwarebaustein kann ein SW-Modul, eine Datenbank, eine SW-Komponente oder eine Software-Konfigurationseinheit sein.


Software-Einheit (SW-Einheit)

Element der Erzeugnisstruktur, das ausschließlich aus Software besteht.


Software-Komponente (SW-Komponente)

Softwarebaustein einer SW-Einheit. SW-Komponenten können ihrerseits andere SW-Komponenten, SW-Module und/oder Datenbanken enthalten.


Software-Modul (SW-Modul)

SW-Module sind die kleinsten zu programmierenden Softwarebausteine einer SW-Einheit, deren Behandlung noch durch das V-Modell geregelt wird.

Hinweise:

Das V-Modell geht nicht auf den technischen Inhalt eines SW-Moduls ein. Es wird angenommen, daß ein SW-Modul anhand folgender Kriterien gebildet wird: Abgeschlossenheit, Geheimnisprinzip, Datenabstraktion, Kapselung, Schnittstellenspezifikation, Schnittstellenminimalität, Überschaubarkeit, Testbarkeit, usw.

Die Programmiersprache Ada bietet zur Implementierung von SW-Modulen das Paketkonzept an (natürlich können auch Unterprogramme oder Tasks benutzt werden).


Software-Pflege und -Änderung

Alle Maßnahmen, die ergriffen werden,

−	um eine zur Benutzung freigegebene Programmausstattung funktionsfähig zu erhalten, ohne daß Spezifikationen geändert oder erweitert werden (Software-Pflege),

−	um eine Änderung oder Erweiterung der Spezifikationen in einer zur Benutzung freigegebenen Programmausstattung zu berücksichtigen (Software-Änderung).


Submodell

Ein aus einer bestimmten Sicht abgeschlossenes Teilmodell des V-Modells. Das V-Modell besteht aus den Submodellen

−	Systemerstellung (SE)

Submodell, in dem die Erstellung eines IT-Systems geregelt wird. Die Erstellung der Software erfolgt unter Berücksichtigung der Schnittstelle zur Hardware.

−	Qualitätssicherung (QS)

Submodell, in dem die präventiven Maßnahmen zur Erreichung der Qualitätsziele und zur Vermeidung von Qualitätsrisiken sowie die analytischen Maßnahmen zum Nachweis der geforderten Qualität beschrieben werden.

Anmerkung:

Das Submodell QS umfaßt

−	Planung von präventiven, konstruktiven und analytischen Maßnahmen;

−	Vorbereitung, Sicherstellung, Durchführung und Berichtswesen für die analytischen Maßnahmen,

und bezieht sich auf

−	Organisation,

−	Prozesse und

−	Produkte.

−	Konfigurationsmanagement (KM)

Submodell, in dem die Verwaltung der während der Systementwicklung anfallenden Produkte aller vier Submodelle geregelt wird. Ihre verschiedenen Versionen und Beziehungen zueinander werden konsistent gehalten, Änderungen überwacht und Zugriffe kontrolliert.

−	Projektmanagement (PM)

Submodell, in dem alle technischen Aspekte der Projektabwicklung geregelt werden. Dazu gehören Planung, Steuerung und Kontrolle aller projektinternen Tätigkeiten sowie projektinterne und projektexterne (z. B. mit Auftraggeber, Anwender) Kommunikation. Nicht abgedeckt sind jedoch System-Management und Finanzplanung.


SW-Teilstruktur

Teil einer (zu erstellenden) SW-Einheit, der einen beliebigen Ausschnitt aus der zukünftigen Software-Architektur darstellt. Dies kann eine SW-Komponente, ein SW-Modul, eine Datenbank oder ein Aggregat von bereits (teil-) integrierten SW- Teilstrukturen sein.


SWPÄ-Software

Software zur Fehlerdiagnose und -lokalisierung in der operativen Software (u. U. auch der HW).


System

(Quelle: ISO/IEC 12207)

Einheitliches Ganzes, das aus einem oder mehreren Prozessen, Hardware, Software, Einrichtungen und Personen besteht, das die Fähigkeit besitzt, vorgegebene Forderungen oder Ziele zu befriedigen.

Für das V-Modell werden nur Systeme betrachtet, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Für derartige Systeme wird abkürzend der Begriff "IT-System" verwendet.


Systemarchitektur

Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur, mit den Elementen der generischen Erzeugnisstruktur. Betrachtet werden dabei die Elemente der Erzeugnisstruktur bis einschließlich der SW-Einheiten/HW-Einheiten. Die Architekturen der SW-Einheiten und HW-Einheiten finden sich in den zugehörigen Architekturdokumenten.


Systemsicherheit

Fähigkeit einer Funktionseinheit, innerhalb vorgegebener Grenzen für eine gegebene Zeitdauer kein Fehlverhalten zu bewirken oder eintreten zu lassen.

(Die Systemsicherheit ist von der Datensicherheit zu unterscheiden.)


Szenario

Beispielhafte Darstellung und Erläuterung einer Entwicklungsstrategie als Ausprägung des V-Modells.


Technische Anforderungen

Ergänzende und interpretierende Forderungen, die aus der technischen Sicht an die Elemente der technischen Architektur gestellt werden.

Anmerkung:

Die Gesamtheit der Forderungen an ein IT-System ergibt sich aus den Anwenderforderungen und den daraus abgeleiteten Technischen Anforderungen.


Testabdeckung

Ausmaß der Testfälle, mit denen ein Programm oder Programmteil getestet wird. Man unterscheidet zwischen den Abdeckungen C0 bis C7, wobei die gebräuchlichsten Testabdeckungen C0, C1 und C2 sind.

C0:	Jede Anweisung wird mindestens einmal durchlaufen.

C1:	Jeder Programmzweig wird mindestens einmal durchlaufen (z. B. erfordert die bedingte Anweisung if ... then ... endif zwei Testfälle).

C2:	Bei zusammengesetzten Bedingungen in bedingten Anweisungen wird jede Bedingung (wahr, falsch) getestet.


Übertragbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf die Eignung der Funktionseinheit, von einer Umgebung (organisatorische Umgebung, Hardware- oder Softwareumgebung) in eine andere übertragen zu werden.


Unterbrechung

In einem Prozessor das Anhalten eines Prozesses durch ein Signal derart, daß ein anderer vorrangiger Prozeß abläuft und der angehaltene Prozeß zu einem späteren Zeitpunkt fortgesetzt werden kann.


Unterstützungs-Software

Software zur Entwicklung und Pflege/Änderung der operativen Software (Synonym: Werkzeug).


Validierung

(Quelle: DIN EN ISO 8402)

Bestätigen aufgrund einer Untersuchung und durch Führung eines Nachweises, daß die besonderen Forderungen für einen speziellen vorgesehenen Gebrauch (Erwartungshaltung des Anwenders) erfüllt worden sind.

Anmerkung:

Eine Validierung kann durchgeführt werden

−	in Form einer Prüfung des Endproduktes gegen die Erwartung des Anwenders,

−	in Form einer Simulation auf der Basis von Zwischenergebnissen, bei der der Anwender einbezogen wird und

−	als Prüfschritt im Rahmen einer Durchführungsentscheidung am Ende einer Entwicklungsstufe bei inkrementeller Systementwicklung.


Variante

Varianten sind zeitgleich nebeneinander liegende Ausprägungen von Produkten.


Verfügbarkeit

Wahrscheinlichkeit, ein System zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen.


Verifizierung

(Quelle: DIN EN ISO 8402)

Bestätigen aufgrund einer Untersuchung und durch Führung eines Nachweises, daß die festgelegten Forderungen erfüllt worden sind.

Anmerkung:

Die Verifizierung kann als Prozeß- oder Produktprüfung durchgeführt werden.


Version

Alle Produkte einer Konfiguration (Software, Dokumente) besitzen eine individuelle Versionsangabe (Beispiele: a, b, c; 1.2, 1.3, 1.4). Jede formale oder inhaltliche Änderung an einem Konfigurationsprodukt bewirkt eine Erhöhung der Versionsangabe. Unter "Versionen" werden zeitlich nacheinander liegende Ausprägungen eines Produkts verstanden.


V-Modell

Regelungen, die die Gesamtheit aller Aktivitäten, Produkte und deren logische Abhängigkeiten bei der Entwicklung und Pflege/Änderung von Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird, im Bereich der Bundesverwaltung festlegen.


Vor Ort austauschbare Einheit

Engl. "Field Replaceable Unit" (FRU)

Eine vor Ort austauschbare Einheit ist eine austauschbare Einheit, die im zur Benutzung freigegebenen System ausgetauscht werden kann.


Zertifikation

Verwaltungsmaßnahmen zur Erlangung der Zulassung einer Funktionseinheit durch eine unabhängige Organisation zu einem bestimmten Einsatzzweck.


Zugesicherte Eigenschaften

Vertraglich vereinbarte, zu validierende Anwenderforderungen.


Zuverlässigkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auf die Fähigkeit der Funktionseinheit auswirken, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.

Hinweise:

Die Anwendung der Zuverlässigkeitstheorie auf Software ist besonders schwierig. Im zur Zeit vorherrschenden Erfahrungsbereich der Hardware werden Zuverlässigkeitsbetrachtungen mit Ausfällen infolge Alterung oder Verschleiß verbunden. Bei Software finden Verschleiß oder Alterung im engen Sinne nicht statt. Bei ihr werden Einschränkungen der Zuverlässigkeit auf von vornherein vorhandene Konstruktionsfehler zurückgeführt, die sich z. B. wegen der Unvollständigkeit von ins Programm eingebauten Prüfungen in einem Restfehlergehalt niederschlagen, dessen Auswirkungen in einer vorgegebenen Anwendungsdauer ebenso wie Alterungs- und Verschleißausfälle nicht vorhersehbar sind.

Zuverlässigkeit kann in diesem Bereich allerdings auch durch Manipulationen (z. B. Einschleusen von Viren) während der Einsatzdauer reduziert werden.


Bw-IT-Standards

Bw-IT-Standards sind für den Geschäftsbereich des BMVg festgelegte IT-Standards.


De-facto-Standards

De-facto-Standards sind IT-Standards, denen aufgrund ihrer weiten Verbreitung und Akzeptanz am Markt der Status von Standards zukommt. De-facto-Standards können von einzelnen Herstellern durchgesetzt oder von industriellen Gremien (z. B. OSF, OMG) ausdrücklich im Sinne einer marktorientierten Standardisierung entwickelt sein. Beispiele für De-facto-Standards eines Herstellers sind Windows, Lotus-Notes, für De-facto-Standards industrieller Gremien TCP/IP, CORBA.


Geschäftsbereich des BMVg

Der Geschäftsbereich des BMVg umfaßt das Ministerium und die Bundeswehr (Streitkräfte und Wehrverwaltung).


IT-Ausstattungsvorgaben

IT-Ausstattungsvorgaben spezifizieren IT-Ausstattungen auf der Basis von IT-Planungsvorgaben (funktionale Vorgaben) und Bw-IT-Standards.


IT-Planungsvorgaben

Unter IT-Planungsvorgaben werden eindeutig und systematisiert formulierte Funktionalitäten verstanden, die in einem definierten Umfeld (z. B. Organisationseinheit) in bestimmten Arbeitsabläufen für häufig und gleichermaßen zu vollziehende Tätigkeitskomplexe, Einzel- und elementare Tätigkeiten bei der Lösung bestimmter Aufgaben/Aufgabenklassen benötigt werden.


IT-Normen

Nationale oder internationale Vereinbarungen, die von nationalen oder internationalen Institutionen (zivielen oder militärischen) ausdrücklich als Normen erarbeitet werden. Zivile Normen werden z. B. von ISO, EN, DIN und sonstigen Institutionen, militärische Normen von der NATO oder nationalen militärischen Gremien festgelegt.


IT-Standards

IT-Standards beziehen sich auf Vorgehensweisen, Schnittstellen, Architekturen, Abläufe, Terminologie, Produkte des IT-Gebiets. Bei den IT-Standards wird unterschieden zwischen IT-Normen und De-facto-Standards.


Zielsetzung
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.1	Zielsetzung

Das Vorgehensmodell (V-Modell) regelt im Bereich der Bundesverwaltung die Entwicklung sowie die Pflege und Änderung von Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Dies geschieht durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der IT-Systemerstellung und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen.

Dieser Standard trägt damit zur Erreichung folgender Ziele bei:

−	Verbesserung und Gewährleistung der Qualität:

•	Durch standardisiertes Vorgehen wird die Vollständigkeit der zu liefernden Ergebnisse am ehesten gewährleistet.

•	Definierte Zwischenergebnisse ermöglichen frühzeitige Prüfmaßnahmen.

•	Einheitliche Produktinhalte erleichtern die Lesbarkeit der Produkte und die Durchführung von Prüfmaßnahmen.

−	Eindämmung der Kosten über den Lebenszyklus:

•	Die Erstellung entsprechender projektspezifischer Entwicklungsstandards und deren Prüfung wird vereinfacht.

•	Das standardisierte Vorgehen macht die Kalkulation des Aufwandes transparenter. Kostenrisiken werden besser erkennbar.

•	Einheitliche Standards reduzieren Reibungsverluste zwischen Auftraggeber und Auftragnehmer wie auch zwischen Hauptauftragnehmer und Unterauftragnehmer.

•	Standardisiertes Vorgehen ermöglicht die Reduzierung des Ressourcen-Einsatzes.

•	Bei standardisiertem Vorgehen werden universelle Lösungsansätze erkennbar und damit mehrfach verwendbar.

•	Fehlentwicklungen werden früher erkannt.

•	Die Schulungskosten werden verringert.

−	Verbesserung der Kommunikation zwischen allen Beteiligten sowie Verringerung der Abhängigkeit des Auftraggebers vom Auftragnehmer:

•	Die Verwendung definierter Begriffe reduziert Mißverständnisse zwischen den beteiligten Stellen.

•	Der Anwender, der Aufgabensteller und der Entwickler werden bei der Formulierung ihrer Forderungen/bei Beschreibung ihrer Anteile oder Ergebnisse unterstützt.

•	Die Zwischenergebnisse/Ergebnisse sind soweit standardisiert, daß andere Beteiligte bzw. das Personal anderer Firmen sich − falls erforderlich − mit vertretbarem Aufwand einarbeiten können.


Anwendung des V-Modells
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.2	Anwendung des V-Modells

Das V-Modell wird bei Angebotsaufforderung und Vertragsgestaltung berücksichtigt und findet Anwendung bei der Projektbegleitung, Erstellung, Pflege und Änderung von IT-Systemen. Anwender sind sowohl die Behörden als auch die Industrie.

Bei einer Anwendung des V-Modells für Entwicklungen innerhalb der Behörden sind folgende Begriffe, die im V-Modell durchgängig verwendet werden, sinngemäß zu übertragen:

Auftrag/Vertrag	Anordnung/Beauftragung/Weisung

Auftraggeber	Aufgabensteller

Auftragnehmer	Entwickler/Programmiereinrichtung

Das V-Modell berücksichtigt keine organisationsspezifischen Festlegungen; es ist organisationsneutral. Daher ist es in den unterschiedlichen Behörden auf die dort vorhandene Ablauforganisation abzubilden. Zur Unterstützung dieser Aufgabe erfolgt im V-Modell eine Zuordnung von Aktivitäten zu "Rollen".

Die für die Softwarebearbeitung zuständigen Stellen haben je SEU-Implementierung eine Zuordnung der aus den Werkzeugen entstehenden Dokumentation zu den Dokumenten des V-Modells sicherzustellen.

Ferner haben sie zu prüfen, ob Vorschriften bzw. Regelungen ihres Bereiches aufgrund der neuen Regelungen anzupassen bzw. ob bereichsspezifische Durchführungsbestimmungen zu erlassen sind.


Systembegriff im V-Modell
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.3	Systembegriff im V-Modell

In seiner Anwendung bezieht sich das V-Modell prinzipiell auf den Systembegriff, wie er in der ISO 12207 festgelegt ist: Ein System ist dort definiert als ein einheitliches Ganzes, das aus einem oder mehreren Prozessen, Hardware, Software, Einrichtungen und Personen besteht, das die Fähigkeit besitzt, vorgegebene Forderungen oder Ziele zu befriedigen.

Für das V-Modell werden nur die Systeme betrachtet, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Dazu zählen neben den IT-Systemen auch IT-Anteile in anderen Systemen.

Im V-Modell wird dafür abkürzend der Begriff "IT-System" verwendet. Ein IT-System in diesem Sinne kann Teil eines übergeordneten Systems sein.


Anpassung an die konkrete Projektsituation
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.4	Anpassung an die konkrete Projektsituation

Das V-Modell zeichnet sich durch Allgemeingültigkeit aus. Die enthaltenen technischen Regelungen müssen an die konkrete Projektsituation angepaßt werden. Diese Anpassung für ein Projekt ("Tailoring" genannt) kann durch Streichung oder Zusammenfassung von Aktivitäten oder Produkten durchgeführt werden. Ergänzungen müssen kenntlich gemacht werden. Im Anschluß daran müssen die organisatorischen Zuordnungen der so gefundenen Aktivitäten erfolgen.

Teil 3 "Handbuchsammlung" enthält Anpassungsvorschläge für verschiedene Projekt-/Vorhabentypen im Rahmen des "Standardisierten Vortailoring".


Erfüllung von QS-Vorschriften
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.5	Erfüllung von QS-Vorschriften

Das V-Modell enthält detaillierte Regelungen für den gesamten Prozeß der IT-Systemerstellung einschließlich der Tätigkeitsbereiche Projektmanagement, Qualitätssicherung und Konfigurationsmanagement. Mit einer ordnungsgemäßen Anwendung des V-Modells sind zugleich die "Mindestanforderungen der Rechnungshöfe des Bundes und der Länder zum Einsatz der Informationstechnik" sowie die entsprechenden technischen Anforderungen nach ISO 900x und AQAP-110 oder AQAP-150 erfüllt.

Eine Zuordnungstabelle zwischen den Anforderungen nach ISO 9000-3 und ihrer Erfüllung durch das V-Modell ist in Teil 3 "Handbuchsammlung" im Handbuch "Das V-Modell in einer ISO- und AQAP-Umgebung" dargestellt.


Erfüllung von Sicherheitskriterien
Teil 1	Vorgehensmodell / Regelungsteil

1	Zielsetzung und Anwendung des Vorgehensmodells

1.6	Erfüllung von Sicherheitskriterien

Systeme und Software, die durch unabhängige und neutrale Organisationen evaluiert und zertifiziert werden sollen, müssen die Anforderungen der zugrundeliegenden Sicherheitskriterien erfüllen.

Die Regelungen des V-Modells erfüllen die Anforderungen des zugrundeliegenden Kriterienkatalogs zur Sicherheit 1) hinsichtlich des Entwicklungsvorgehens und der zu erstellenden Produkte, und alle dort enthaltenen Anforderungen können im Rahmen der Vorgehensweise nach dem V-Modell festgelegt und kontrolliert realisiert werden.

1)	Die Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (/ITSEC/) bilden die derzeit gültige Grundlage.

Unter "IT-Sicherheit" wird im folgenden sowohl Sicherheit im Sinne von Security ("klassische" IT-Sicherheit) als auch im Sinne von Safety (Verfahrens- oder Betriebssicherheit) verstanden.


Einführung in das V-Modell
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

Das V-Modell regelt die Gesamtheit aller

−	Aktivitäten und Produkte

sowie

−	Produktzustände und logischen Abhängigkeiten zwischen Aktivitäten und Produkten

während der Entwicklung und der Pflege und Änderung von IT-Systemen.

Das V-Modell ist in vier Submodelle gegliedert.

Das V-Modell beschreibt den Entwicklungsprozeß aus funktionaler Sicht. Es geht nicht auf spezielle Organisationsformen ein, da es in unterschiedlichsten Einrichtungen/Firmen zum Einsatz kommen soll. Für die Durchführung eines Projekts müssen daher für die im V-Modell dargestellten Aufgaben ("Aktivitäten") Bearbeiter bzw. Organisationseinheiten festgelegt werden.

Diese Einführung in das V-Modell stellt dar, welche Grundkonzepte und Beschreibungsmittel für das V-Modell verwendet werden.


Erzeugnisstruktur und Einbettung in das organisatorische Umfeld
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.1	Erzeugnisstruktur und Einbettung in das organisatorische Umfeld

Das V-Modell beschreibt die Entwicklung von IT-Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Das "System" ist in diesem Sinne eine Funktionseinheit der obersten Ebene aus der Sicht des V-Modells.

Die Erzeugnisstruktur  des V-Modells definiert, aus welchen generischen Bausteinen ein zu entwickelndes System grundsätzlich besteht.

Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur mit den Elementen der generischen Erzeugnisstruktur. Dynamische Aspekte des Systems werden über die Beschreibung der Funktionsweise und dem Zusammenwirken der Elemente der Erzeugnisstruktur über deren Schnittstellen dargestellt.

Im folgenden wird beschrieben, aus welchen Bestandteilen sich ein "System" im Sinne des V-Modells zusammensetzt (siehe Abbildung 2.1).

Ein System gliedert sich in Segmente, die unterschieden werden in solche mit IT-Anteilen (Segmente mit IT-Anteil) und solche ohne IT-Anteile (Segmente ohne IT-Anteil). Segmente können ihrerseits wieder aus mehreren Segmenten zusammengesetzt sein.

Segmente werden weiter in SW-Einheiten und HW-Einheiten gegliedert.

Systeme können sich auch direkt in SW-Einheiten und HW-Einheiten gliedern. Es ist auch der Fall möglich, daß sich ein System sowohl in Segmente als auch direkt in SW-Einheiten/HW-Einheiten gliedert.

SW-Einheiten (z. B. Lademodule) und HW-Einheiten (z. B. Baugruppen oder kleinere Geräte) stellen aus der Sicht der Systemarchitektur elementare Objekte dar. Die Entwicklung von SW-Einheiten wird durch den Regelungsteil des V-Modells abgedeckt; die Entwicklung der HW-Einheiten wird in Teil 3 "Handbuchsammlung" behandelt.

SW-Einheiten bestehen aus SW-Komponenten, wobei SW-Komponenten entweder selbst wieder aus SW-Komponenten niedrigerer Ordnung, SW-Modulen und/oder Datenbanken zusammengesetzt sein können. SW-Komponenten sind abgeschlossene Softwareeinheiten einer höheren Ebene. SW-Module sind die kleinsten zu programmierenden Softwarebausteine einer SW-Einheit. Datenbanken dienen der Beschreibung, Speicherung und Wiedergewinnung von Daten.

HW-Einheiten bestehen aus HW-Komponenten, wobei HW-Komponenten entweder selbst wieder aus HW-Komponenten und/oder HW-Modulen zusammengesetzt sein können. HW-Module sind die kleinsten Bausteine einer HW-Einheit.

Abbildung 2.1 zeigt die hierarchisch gegliederte Erzeugnisstruktur des Systems. Außerdem ist gekennzeichnet, welche Entwicklungstätigkeiten durch das V-Modell geregelt sind.

Abbildung 2.1: Erzeugnisstruktur und Anwendungsbereich des V-Modells


Randbedingungen zur IT-Systemerstellung
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.2	Randbedingungen zur IT-Systemerstellung

Abbildung 2.2 zeigt schematisch die (Haupt-) Aktivitäten bei einer IT-Systemerstellung.

Falls die Entwicklung von Hardware-Anteilen berücksichtigt werden muß, muß die Softwareentwicklung in enger Verzahnung mit der Hardwareentwicklung vorgenommen werden 2), bzw. die Software muß unter ständiger Berücksichtigung der ausgewählten Hardware und ihrer Eigenschaften realisiert werden. Nur unter dieser Voraussetzung kann die Erfüllbarkeit der Anwenderforderungen über den gesamten Entwicklungsprozeß hinweg kontrolliert und gewährleistet werden. Abbildung 2.2 deutet die Bezüge zu den Nicht-IT-Anteilen des Systems während des IT-Systemerstellungsprozesses an.

2)	Siehe Abschnitt 3.4 und Teil 3 "Handbuchsammlung", Handbuch "Hardwareerstellung".

Aber auch wenn die Entwicklung spezifischer Hardware nicht Gegenstand des Projektes ist, so müssen doch in jedem Fall Hardware und Software den vorgegebenen technischen Rahmenbedingungen entsprechen und in das organisatorische Umfeld eingepaßt werden. Das V-Modell hat somit alle Anteile eines zu entwickelnden Systems, soweit sie einen Einfluß auf den IT-Systemerstellungsprozeß haben, zu berücksichtigen. Es kann unter allen in der Bundesverwaltung vorhandenen technischen Rahmenbedingungen und in jedem organisatorischen Umfeld angewendet werden. 3)

3)	Anleitungen zur Berücksichtigung des organisatorischen Umfeldes bei der Planung von IT-Systemen in der Bundesverwaltung finden sich in der /IT-Org/ und /IT-RaKonz/. Eine gesonderte Betrachtung dieser Gesichtspunkte findet daher im folgenden nicht mehr statt.

Die Reihenfolge der Aktivitäten in Abbildung 2.2 erscheint sequentiell. Dies entspricht der Vorstellung vom IT-Systemerstellungsprozeß als einem strengen Top-down-Vorgehen. In der Regel sind jedoch Iterationen im Erstellungsprozeß üblich (siehe Abschnitt 3). Abbildung 2.2 zeigt eine schematisierte linearisierte Darstellung des logischen Ablaufs der IT-Systemerstellung und deren Einbettung in das organisatorische Umfeld.

Abbildung 2.2: Randbedingungen zur IT-Systemerstellung


Inhalt und Darstellungsmittel
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

Die Grundelemente des V-Modells sind die Aktivitäten und Produkte, die während des IT-Systementwicklungsprozesses durchgeführt bzw. bearbeitet werden.


Aktivitäten und Produkte
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.1	Aktivitäten und Produkte

Als Aktivität  wird eine Tätigkeit im Rahmen des IT-Systementwicklungsprozesses bezeichnet, die hinsichtlich ihres Ergebnisses und ihrer Durchführung genau beschrieben werden kann. Aktivitäten können aus einer Reihe festgelegter "Teilaktivitäten" bestehen, wenn jede dieser Teilaktivitäten ihrerseits definierte "Zwischenergebnisse" aufweist. Die Aktivitäten der obersten Detaillierungsebene werden "Hauptaktivitäten" genannt.

Als Produkt  wird der Bearbeitungsgegenstand bzw. das Ergebnis einer Aktivität bezeichnet. Analog der Zerlegung von Aktivitäten in Teilaktivitäten kann sich die Zerlegung von Produkten in "Teilprodukte" (z. B. einzelne Kapitel eines Dokuments) ergeben.

Eine Aktivität kann

−	die Erstellung eines Produkts,

−	eine Zustandsänderung eines Produkts oder

−	die inhaltliche Änderung eines Produkts

zum Gegenstand haben.

Diese Grundelemente "Aktivität" und "Produkt" werden durch spezielle Symbole repräsentiert (siehe Abbildung 2.3).

Abbildung 2.3: Symbole für Aktivitäten und Produkte

Zu jeder Aktivität existiert eine Aktivitätenbeschreibung als Arbeitsanleitung, der bei der Ausführung der Aktivität zu folgen ist. Die Aktivitätenbeschreibung erfolgt nach einem festen Muster, dem Aktivitätenschema (siehe Abschnitt 2.3.3 Aktivitätenschema). Falls eine Aktivität in Teilaktivitäten zerlegt wird und logische Abhängigkeiten zwischen Teilaktivitäten und Produkten herausgestellt werden müssen, enthält das Aktivitätenschema zusätzlich eine grafische Darstellung der Teilaktivitäten.

Zu jedem Produkt existiert eine Produktbeschreibung, welche die Inhalte des Produkts definiert. Die Produktbeschreibung erfolgt nach einem festen Muster, dem Produktmuster (siehe Abschnitt 2.3.4 Produktmuster).


Produktzustände
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.2	Produktzustände

Bei der Behandlung von (Teil-) Produkten im V-Modell ist zu berücksichtigen, daß gewisse Produkte im Entwicklungsprozeß verschiedene Zustände durchlaufen.

Der Wechsel von einem Zustand in einen anderen wird grundsätzlich durch eine Aktivität ausgelöst. Alle Zustandsübergänge werden bei den entsprechenden Aktivitäten selbst angegeben (siehe Abschnitt 2.3.3 Aktivitätenschema).

Produkte können folgende Zustände einnehmen:

"geplant"

Das Produkt ist in der Planung vorgesehen. Dies ist der Eingangszustand für alle Produkte.

"in Bearb."

Das Produkt wird bearbeitet. Es befindet sich entweder im "privaten" Entwicklungsbereich des Entwicklers oder unter Kontrolle des Entwicklers innerhalb der Produktbibliothek.

"vorgelegt"

Das Produkt ist aus der Sicht des Erstellers fertig und wird unter Konfigurationsverwaltung genommen. Es wird einer QS-Prüfung unterzogen. Wird das Produkt in QS abgelehnt, so geht es wieder in den Zustand "in Bearb." zurück, andernfalls rückt es in den Zustand "akzeptiert" vor. Vom Zustand "vorgelegt" ab kann der Ersteller nur unter Fortschreibung der Versionsangabe Modifikationen durchführen.

"akzeptiert"

Das Produkt wurde in QS überprüft und freigegeben und darf nur mehr innerhalb einer neuen Version geändert werden.

Die mindestens geforderten Zustandsübergänge sind in Abbildung 2.4 dargestellt.

Abbildung 2.4: Zulässige Zustandsübergänge von Produkten


Aktivitätenschema
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.3	Aktivitätenschema

Eine Aktivität wird nach folgendem Muster beschrieben:

Name der Aktivität

Produktfluß

Abwicklung


Abschnitt "Produktfluß"
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.3	Aktivitätenschema

2.3.3.1	Abschnitt "Produktfluß"

Hier werden alle Produkte oder Teilprodukte, die in die (Teil-) Aktivität eingehen oder von ihr modifiziert oder neu erstellt werden, aufgelistet und ihre Behandlung beschrieben. Das geschieht in Form einer Tabelle (siehe Abbildung 2.5), die entsprechend ausgefüllt wird.

Teilprodukte werden in Punktnotation dargestellt. So bedeutet z. B. "Systemarchitektur.Anforderungszuordnung", daß "Anforderungszuordnung" ein Teilprodukt des Produkts "Systemarchitektur" ist.

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.1	in Bearb.		Systemarchitektur		—	—
—	—		Systemarchitektur. Anforderungszuordnung		SE 1, SE 2.5, SE 2.6, SE 3, SE 4-SW, PM 4, PM 5	vorgelegt
Abbildung 2.5:	Muster eines Produktflusses (Aktivität SE 2.4 "Anwenderforderungen zuordnen")

Zu jedem (Teil-) Produkt (Spalte 3), das durch die zu beschreibende Aktivität betroffen ist, wird der Zustand zu Beginn der Aktivität (Spalte 2) und der Zustand nach Beendigung der Aktivität (Spalte 5) angegeben. Hat die Aktivität keinen Einfluß auf den Produktzustand oder existiert kein Produktzustand, so ist dies in der Tabelle durch einen Strich angegeben. Eingangsprodukte einer Aktivität sind dadurch kenntlich gemacht, daß die Spalten "von Aktivität" und "von Zustand" ausgefüllt sind, die "nach Aktivität" und der "nach Zustand" sind mit Strich versehen. Bei Ausgangsprodukten entfallen die "von"-Einträge. Es sind nur die "nach Aktivität" und der "nach Zustand" vermerkt. Hat ein Produkt sowohl "von"- als auch "nach"-Einträge, so bedeutet das, daß es in der betreffenden Aktivität modifiziert wird.

Alle in der Aktivität neu erstellten Ausgangsprodukte, deren Ausgangszustand "in Bearb." ist, müßten modellgemäß den Eingangszustand "geplant" haben. Um jedoch Ein- und Ausgangsprodukte optisch besser unterscheiden zu können, ist der Eingangszustand durch "—" ersetzt. Dies ist in diesen Fällen als Zustand "geplant" zu interpretieren. 4)

4)	In einigen Fällen wird im Submodell KM von dieser Regel abgewichen, wenn das betroffene Produkt inhaltlich nicht bearbeitet wird.

Weiter wird zu jedem (Teil-) Produkt vermerkt, von welcher Aktivität das Produkt kommt (Spalte 1) und an welche Aktivität das Produkt weitergegeben wird (Spalte 4). Gibt es zu einem (Teil-) Produkt keine "von"- oder "nach"-Aktivität, so ist dies in der Tabelle durch einen Strich angegeben.

Entstehen Teilprodukte eines Produkts in unterschiedlichen (Teil-) Aktivitäten (siehe z. B. Aktivität QS 2.2 "Prüfumgebung definieren"), ergibt sich die Notwendigkeit, das Produkt durch Integration der Teilprodukte zusammenzustellen. Dies erfolgt in der Aktivität, in der das zuletzt entstehende Teilprodukt eines Produkts erstellt wird. Im Produktfluß wird dies dadurch zum Ausdruck gebracht, daß in der Spalte "nach Aktivität" auf nachfolgende Hauptaktivitäten verwiesen wird. Bei Produkten, die nicht weiter fortgeschrieben werden, wird in der Spalte "nach Zustand" der Zustand "vorgelegt" zugeordnet.

Das Beispiel in Abbildung 2.5 ist so zu verstehen, daß die Anwenderforderungen und die Systemarchitektur von den Aktivitäten SE 1 bzw. SE 2.1 kommen und Eingangsprodukte darstellen. Die Anwenderforderungen liegen im Zustand "akzeptiert" und die Systemarchitektur im Zustand "in Bearb." vor. Neu erstellt wird das Teilprodukt "Anforderungszuordnung" des Produkts "Systemarchitektur". Das Produkt verläßt die Aktivität im Zustand "vorgelegt" und ist Eingangsprodukt für die Aktivitäten SE 1, SE 2.5, SE 2.6, SE 3, SE 4-SW, PM 4 und PM 5.

Maßnahmen zur Qualitätssicherung und zum Konfigurationsmanagement werden indirekt durch die Zustandsänderungen angedeutet.


Abschnitt "Abwicklung"
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.3	Aktivitätenschema

2.3.3.2	Abschnitt "Abwicklung"

Hier ist verbindlich festgelegt, wie bei der Durchführung der Aktivität vorzugehen ist.

Bei einer Hauptaktivität sind zu Beginn des Abwicklungstextes ihre Teilaktivitäten, deren Abhängigkeiten untereinander sowie deren Ergebnisse grafisch dargestellt.

Dabei gilt folgende Festlegung: Ist zu Teilaktivitäten kein Ergebnisprodukt angegeben, so bedeutet dies, daß in mehreren in der Abbildung aufeinanderfolgenden Teilaktivitäten an Teilen eines gemeinsamen Produktes gearbeitet wird.


Empfehlungen und Erläuterungen
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.3	Aktivitätenschema

2.3.3.3	Empfehlungen und Erläuterungen

In Ergänzung zu den Abwicklungstexten können Unterabschnitte "Empfehlung" und "Erläuterung" gegeben werden. Im Gegensatz zur oben angeführten verbindlichen Festlegung sind die ausgesprochenen Empfehlungen nicht bindend. Die Erläuterungen sollen die Aufgabenstellung und die Abwicklung der Aktivität verdeutlichen.


Produktmuster
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.4	Produktmuster

Im Rahmen des Produktmusters wird für jedes Produkt eine kurze Zusammenfassung des Produktinhaltes und im allgemeinen eine Auflistung der inhaltlichen Gliederungspunkte des Produktes angegeben. Anforderungen an das Layout werden im Rahmen des V-Modells nicht gestellt.

Eine genaue Beachtung der Feingliederung läßt sich bei Verwendung von Werkzeugen zur Produktgenerierung nicht immer garantieren. In diesem Fall muß die Feinstrukturierung der betroffenen Dokumente von Fall zu Fall ausdrücklich vereinbart werden. Dabei ist die Abdeckung der erforderlichen Inhalte nachzuweisen.


Submodelle
Teil 1	Vorgehensmodell / Regelungsteil

2	Einführung in das V-Modell

2.3	Inhalt und Darstellungsmittel

2.3.5	Submodelle

Innerhalb des V-Modells werden gewisse Aktivitäten zusammengefaßt, weil sie jeweils aus einer bestimmten Sicht ein in sich abgeschlossenes Modell repräsentieren. Ein derartiges "Modell" wird als Submodell  bezeichnet.

Folgende vier Submodelle bilden das V-Modell:

−	Systemerstellung (SE)

−	Qualitätssicherung (QS)

−	Konfigurationsmanagement (KM)

−	Projektmanagement (PM)

Abbildung 2.6 zeigt das Zusammenspiel der Submodelle. Abbildung 2.7 zeigt, wie die Produkte der vier Submodelle SE, QS, KM und PM in die hierarchische Erzeugnisstruktur einzuordnen sind.

Eine zusammenfassende Auflistung aller Aktivitäten eines Submodells findet sich jeweils am Beginn des Abschnitts, in dem das Submodell beschrieben wird (Abschnitte 4.1, 5.1, 6.1 und 7.1).

Abbildung 2.6: Zusammenspiel der Submodelle

Abbildung 2.7: Produkte des V-Modells (Produktbaum)


Projektspezifisches V-Modell und Tailoring
Teil 1	Vorgehensmodell / Regelungsteil

3	Allgemeine Regelungen

3.1	Projektspezifisches V-Modell und Tailoring

Die in den Submodellen beschriebenen Aktivitäten und Produkte sind für die Verwendung sowohl in kleinen als auch großen IT-Systementwicklungsprojekten bzw. Pflege- und Änderungsprojekten vorgesehen. Entsprechend dem Entwicklungsgegenstand, dessen Anforderungen an Funktionalität, an Komplexität der Funktionen und Daten und an die Qualitätsmerkmale, wie z. B. Wartbarkeit, sind im konkreten Projekt das Vorhandensein eines (Teil-) Produkts und die Durchführung einer (Teil-) Aktivität festzulegen. Produkte und Aktivitäten können in einem bestimmten Projekt gegenüber dem generischen V-Modell wegfallen. Das Ergebnis dieses Planungsschritts wird "projektspezifisches V-Modell" genannt.

Die Festlegung des projektspezifischen V-Modells wird durch zwei Anpassungsschritte unterstützt:

−	das Ausschreibungsrelevante Tailoring und

−	das Technische Tailoring.

Die Funktionsweise des Ausschreibungsrelevanten und Technischen Tailoring ist näher in Teil 3 "Handbuchsammlung" (Handbuch "Tailoring und projektspezifisches V-Modell") beschrieben. Weiterhin sind dort Beispiele für mögliche Streichbedingungen sowie verschiedene zugeschnittene Vorhabentypen angegeben.


Projektorganisation und Rollen
Teil 1	Vorgehensmodell / Regelungsteil

3	Allgemeine Regelungen

3.2	Projektorganisation und Rollen

Die Einsatzplanung von Projektmitarbeitern, d. h. die Zuordnung von Aufgaben zu den einzelnen Mitarbeitern des Projekts, erfolgt über Rollen. Das V-Modell nennt für jedes Submodell eine Menge von Rollen, deren Rolleninhaber entsprechend fest definierter Rollen/Aktivitäten-Zuordnungen Aktivitäten bearbeiten. Es werden verschiedene Bearbeitungstypen unterschieden: "verantwortlich (im Sinne der Ausführung)", "mitwirkend" und "beratend". Zu jeder Rolle sind Kenntnisse und Fähigkeiten genannt, die für die Bearbeitung der zugeordneten Aktivitäten gefordert werden.

Bei der Einsatzplanung erfolgt nun die Festlegung der Mitarbeiter oder anderer Organisationseinheiten zu den Aktivitäten über die Rollendefinitionen. Eine Rolle kann von einem oder mehreren Mitarbeitern eingenommen werden. Der Mitarbeiter hat die Kenntnisse und Fähigkeiten der Rolle zu besitzen und kann dann für die Bearbeitung der Aktivitäten, die der Rolle zugeordnet sind, entsprechend den Beteiligungstypen eingeplant werden. Eine Person kann z. B. bei kleineren Projekten mehrere Rollen innehaben, wobei jedoch gewisse Regeln einzuhalten sind. So darf kein Entwickler seine Ergebnisse im Rahmen der QS selbst prüfen.

Durch dieses Rollenkonzept bleibt das V-Modell organisationsneutral. Eine generelle Zuordnung der in einer Organisation existierenden Stellen zu Rollen erleichtert zwar die Organisation in jedem Einzelprojekt und wird daher empfohlen. Sie wird jedoch durch das V-Modell nicht vorgeschrieben.

Eine erfolgreiche Entwicklung verlangt, daß die nachstehenden Abstimmprozesse geregelt ablaufen:

−	Zwischen Anwender, Aufgabensteller und Realisierer
Dies gewährleistet, daß die realisierte Lösung tatsächlich die Bedürfnisse des Anwenders erfüllt.

−	Zwischen SW- und HW-Entwicklung sowie zwischen der Entwicklung von IT-Anteilen und Nicht-IT-Anteilen
Dies dient in erster Linie der Klärung von Schnittstellen, der Untersuchung der Realisierbarkeit von Anforderungen und Konzepten sowie gemeinsamen Prüfaktivitäten.

−	Zwischen der Systementwicklung und dem organisatorischen Umfeld
Dies gewährleistet die Ablauffähigkeit und Wirksamkeit der realisierten Lösung im gegebenen Umfeld.

−	Die Aufgabe des Projektverantwortlichen ist es, eine geeignete Rollenbelegung sicherzustellen.

Die V-Modell-Rollen sowie ihre Beteiligungen an Aktivitäten sind in Teil 3 "Handbuchsammlung" (Handbuch "Rollenkonzept im V-Modell") beschrieben.


Anwendung der Szenarien
Teil 1	Vorgehensmodell / Regelungsteil

3	Allgemeine Regelungen

3.3	Anwendung der Szenarien

Das V-Modell beschreibt die Systementwicklung im Regelungsteil (Abschnitt 4 ff.) als logisch verknüpftes Netz von Aktivitäten und Produkten. Die Abhängigkeiten sind dabei dadurch gegeben, daß für die Ausführung einer bestimmten Aktivität genau definierte Eingangsprodukte in einem ebenfalls definierten Zustand vorliegen müssen. In der konkreten Projektabwicklung müssen nun alle Entwicklungsaktivitäten auf ein Lebenszyklusmodell abgebildet und damit in einen zeitlichen Ablauf eingebunden werden. Basis der Ablaufplanung sind dabei die gewählte Entwicklungsstrategie und die sich daraus ergebenden statischen Abhängigkeiten, d. h. die Abhängigkeit jeder Aktivität von der Verfügbarkeit der erforderlichen Eingangsprodukte.

In der Praxis erfolgt eine Systementwicklung in Ausbaustufen. Dabei wird ein System in seiner Gesamtheit geplant, aber in Teilen realisiert. Die Funktionalität wächst ständig. Im Regelfall soll an den Nutzer frühzeitig eine erste Systemversion ausgeliefert werden, die die Basisfunktionalität unter Einhaltung der grundlegenden Qualitätsanforderungen besitzt. Spätere Systemteile erweitern im wesentlichen diese Funktionalität.

Diese stufenweise Vorgehensweise wird als "inkrementelle Entwicklung" bezeichnet. Sie stellt den Regelfall der Anwendung des V-Modells dar.

Für die Anwendung des V-Modells bedarf es der Planung der Ausbaustufen. Für jede Ausbaustufe ist die zu realisierende Funktionalität samt ihrer Qualitätsforderungen festzulegen. Die Aktivitäten und Produkte einer Ausbaustufe sind entsprechend den in den Produktflüssen definierten logischen Bedingungen zeitlich zu planen. Bereits existierende Produkte werden den Entwicklungsstufen entsprechend fortgeschrieben. Für die Produkte, die infolge der stufenweisen Entwicklung einem dynamischen Bearbeitungsprozeß unterliegen (z. B. Anwenderforderungen), ist insbesondere der geplante Bearbeitungsstand der entsprechenden Produkte für jede Ausbaustufe festzuschreiben.

In Teil 3 "Handbuchsammlung" (Handbuch "Szenarien") ist die Anwendung des V-Modells für verschiedene Vorgehensweisen bei der Systementwicklung anhand der folgenden Szenarien beispielhaft dargestellt:

−	Inkrementelle Entwicklung,

−	Grand Design (Traditionelles Vorgehen),

−	Einsatz von Fertigprodukten,

−	Objektorientierte Entwicklung,

−	Entwicklung wissensbasierter Systeme,

−	SW-Pflege und Änderung,

−	Reverse Engineering.

Die Szenarien "Einsatz von Fertigprodukten", "Objektorientierte Entwicklung" und "Entwicklung wissensbasierter Systeme" basieren auf der inkrementellen Entwicklungsstrategie. Die traditionelle Vorgehensweise der linearen, phasenorientierten Systementwicklung (Grand Design) ist ein Spezialfall der inkrementellen Entwicklung (Realisierung in einer Ausbaustufe).

Abbildung 3.1: Planung einer Systementwicklung

Abbildung 3.1 skizziert die Planung einer IT-Systementwicklung. Die Planung der Aktivitäten und ihrer Produkte erfolgt anhand der im Projekthandbuch festgelegten Entwicklungsstrategie und dem projektspezifischen V-Modell. Die Szenarien der Handbuchsammlung bieten Hilfestellung bei der Festlegung der Entwicklungsstrategie durch die Vorgabe von Auswahlkriterien.

Für unterschiedliche Systemanteile können unterschiedliche Strategien ausgewählt werden, was zur Folge haben kann, daß auch unterschiedliche Ausprägungen des projektspezifischen V-Modells notwendig werden.


Operative Module
Teil 1	Vorgehensmodell / Regelungsteil

3	Allgemeine Regelungen

3.4	Operative Module

Neben den im Regelungsteil des V-Modells (Teil 1, Abschnitt 4 ff.) genannten Submodellen enthält Teil 3 "Handbuchsammlung" verschiedene Ergänzungen bzw. Ersetzungen der Submodelle, die als "operative Module" bezeichnet werden. Ihr Einsatz hängt vom Entwicklungsgegenstand ab.

Fordert die Entwicklung des geplanten IT-Systems neben der Entwicklung von SW-Einheiten auch die Entwicklung von HW-Einheiten, so wird die Ergänzung des Submodells SE um die Hardwareerstellung notwendig. Das operative Modul "Hardwareerstellung" behandelt die Entwicklung von HW-Einheiten (Aktivitäten SE 4-HW bis SE 7-HW).

Handelt es sich um ein Reverse-Engineering-Projekt, so kann das gesamte Submodell SE durch das operative Modul "Reverse-Engineering" ausgetauscht werden.


Behandlung fortzuschreibender Produkte
Teil 1	Vorgehensmodell / Regelungsteil

3	Allgemeine Regelungen

3.5	Behandlung fortzuschreibender Produkte

Das V-Modell behandelt die Bearbeitung von Produkten im Regelfall in folgender Art und Weise:

−	Erstellung eines Produkts (Zustand "in Bearb.") in einer Teilaktivität oder mehreren Teilaktivitäten einer Hauptaktivität und

−	Übergabe des Produkts an QS (Zustand "vorgelegt"), nachdem alle Teilprodukte erstellt wurden.

Dieses Vorgehen trifft für die meisten der im V-Modell geregelten Produkte, insbesondere für SE- und QS-Produkte zu.

Dennoch erfordern die Besonderheiten einer IT-Systementwicklung für einige Produkte ein hiervon abweichendes Vorgehen: Versionen können (u. a. im Rahmen einer inkrementellen Vorgehensweise) in den Zustand "vorgelegt" gehen, obwohl sie nur vollständig in bezug auf die geplante Version sind.

Zu den Produkten, für die diese modifizierte Vorgehensweise zur Fortschreibung erforderlich sein kann, gehören:

−	Anwenderforderungen,

−	Systemarchitektur,

−	Technische Anforderungen,

−	Betriebsinformationen,

−	Schnittstellenübersicht und Schnittstellenbeschreibung,

−	Datenkatalog,

−	Konfigurations-Identifikationsdokument,

−	Änderungsstatusliste und Projekthistorie,

−	Projektplan und

−	Integrationsplan.

a)	"Anwenderforderungen"

Die Fortschreibung des Produkts "Anwenderforderungen" erfährt unter dem Gesichtspunkt einer inkrementellen Vorgehensweise eine besondere Behandlung.

Die grobe Systembeschreibung enthält den Kern und den Gesamthorizont für die Funktionalität des Systems. Aufgrund einer Priorisierung werden Bereiche identifiziert, die zeitlich versetzt realisiert werden. Dazu muß klar sein, in welchen (bereichsspezifischen) Ausbaustufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden. Dies fordert weiterhin, daß alle relevanten fachlichen Bereiche benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt sein müssen. Mit der vollständigen Beschreibung mindestens eines Bereichs kann die erste Version der Anwenderforderungen abgeschlossen werden. Diese unterliegt der QS.

Die weitere Fortschreibung der Anwenderforderungen basiert auf der Detaillierung der identifizierten Bereiche. Bevor ein neuer Bereich weiter entwickelt wird, sind die Anwenderforderungen für diesen Bereich festzuschreiben und qualitätszusichern. Die QS hat besonders darauf zu achten, daß die Fortschreibung keinen bestehenden Anwenderforderungen widerspricht. Änderungen des vereinbarten Gesamthorizonts für die Funktionalität während der Entwicklung sind über Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)" abzuwicklen. Teilentwicklungen sind gegebenfalls davon betroffen, was aus vertragsrechtlichen Gründen zu Problemen führen kann.

b)	"Systemarchitektur"

Die Systemarchitektur beschreibt die Zerlegung des Systems bis zur Ebene der SW-Einheiten und HW-Einheiten. Sie befindet sich daher während ihrer Erstellung in Aktivität SE 2 im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen.

c)	"Technische Anforderungen"

Das Produkt "Technische Anforderungen" enthält technische Anforderungen an das Gesamtsystem, an Segmente und an SW-Einheiten/HW-Einheiten. Das Produkt befindet sich daher während seiner Erstellung in den Aktivitäten SE 2 und SE 3 im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jeder Ergänzung technischer Anforderungen bezüglich einzelner Elemente der Systemarchitektur die neu hinzugekommenen Teile von QS prüfen zu lassen.

Aufgrund des Umfangs dieses Produkts (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheiten oder Segmenten vorzunehmen.

d)	"Betriebsinformationen"

Bei den hierunter zusammengefaßten Produkten "Informationen zum Anwendungshandbuch", "Informationen zum Diagnosehandbuch",  "Informationen zum Betriebshandbuch" und "Sonstige Einsatzinformationen" handelt es sich um Informationen zur Anwenderdokumentation, die im Laufe der Systemerstellung aus den SE-Produkten abgeleitet und erarbeitet, sukzessive gesammelt und in Aktivität SE 8 "System-Integration" vervollständigt werden. Eine QS-Prüfung findet daher erst beim Abschluß der Entwicklungsarbeiten, d. h. nach Aktivität SE 8, statt. Aufgrund des Umfangs dieser Produkte (Bezugsobjekt: System) ist gegebenenfalls eine physikalische Aufteilung in mehrere Produktkomponenten z. B. nach SW-Einheit oder Segmenten vorzunehmen, die dann auch einzeln und gegebenenfalls auch früher einer QS-Prüfung unterzogen werden können.

e)	"Schnittstellenübersicht" und "Schnittstellenbeschreibung"

Bei der Schnittstellenübersicht handelt es sich um ein Produkt, welches aus den Überlegungen und Entscheidungen bzgl. der Systemarchitektur und SW-Architektur resultiert. Es befindet sich daher während seiner Erstellung in den Aktivitäten SE 2 und SE 4-SW im Zustand "in Bearb.", daran anschließend wird es an QS übergeben. Ungeachtet dessen kann es bei Systemen mit einer hohen Schnittstellenkomplexität sinnvoll sein, nach jedem Entwurfsschritt die neu hinzugekommenen Teile von QS prüfen zu lassen. Prinzipiell liegt bei der Schnittstellenbeschreibung der gleiche Sachverhalt vor. Da es sich hier jedoch um ein Produkt handelt, das nachfolgende Entwurfsschritte in entscheidendem Maß beeinflußt, wird für die Schnittstellenbeschreibung eine QS-Prüfung nach jeder Bearbeitungsaktivität (Aktivitäten SE 2 "System-Entwurf", SE 4-SW "SW-Grobentwurf") empfohlen. Die neu hinzugekommenen bzw. veränderten Teile sind dabei zu prüfen.

f)	"Datenkatalog"

Der projektspezifische Datenkatalog wird über die projektübergreifende Datenadministration des KM (falls vorhanden) auf der Basis eines projektübergreifenden Datenkatalogs (falls vorhanden) initialisiert. Als projektumfassendes Dokument wird der Datenkatalog mit Aktivität SE 5.1-SW "SW-Komponente/-Modul/Datenbank beschreiben" sukzessive um Inhalte erweitert, welche von der projektübergreifenden Datenadministration zu genehmigen sind. Die an Aktivität SE 5-SW "SW-Feinentwurf" anschließende QS-Prüfung behandelt diese Ergänzungen.

g)	"Konfigurations-Identifikationsdokument" (KID)

Das KID ist ein über die Aktivität KM 2 "Produkt- und Konfigurationsverwaltung" geführtes Produkt. Aktivität KM 2 ist eine projektbegleitende Aktivität, d. h. sie ist parallel zu den SE-Aktivitäten permanent "aktiv". Auslöser der Aktivität sind die im Projekt erstellten Produkte. Ein KID bezieht sich auf ein System, eine SW-Einheit bzw. eine HW-Einheit. In Abhängigkeit von dem jeweiligen Bezugsobjekt muß das KID solange im Zustand "in Bearb." bleiben, solange sich auch das Bezugsobjekt in diesem Zustand befindet.

h)	"Änderungsstatusliste" und "Projekthistorie"

Hier handelt es sich um Produkte, die über die gesamte Projektlaufzeit und gegebenenfalls über Folgeprojekte hinweg fortgeschrieben werden müssen. Da sie in erster Linie der projektinternen Dokumentation dienen, wird für sie keine QS-Prüfung vorgeschrieben.

i)	"Projektplan"

Der Projektplan befindet sich während des gesamten Projektes "in Bearb.". Eine zu bestimmten Zeitpunkten im Projektfortschritt verbindlich vorgeschriebene QS-Prüfung würde die Planung und Steuerung des Projektmanagements behindern. Dennoch ist auch der Projektplan zu prüfen, was beispielsweise im Rahmen von Durchführungsentscheidungen erfolgen kann. (Siehe dazu auch den Produktfluß von Aktivität PM 4 "Feinplanung".)

j)	"Integrationsplan"

Der Integrationsplan beschreibt die Integration des Systems ausgehend von SW-Modulen, SW-Komponenten, SW-Einheiten/HW-Einheiten und Segmenten. Er befindet sich während der Erstellung in Aktivität SE 2 und Aktivität SE 4-SW im Zustand "in Bearb.". Ungeachtet dessen ist es sinnvoll, nach jedem Verfeinerungsschritt die Ergänzungen von QS prüfen zu lassen.

Der Vollständigkeit halber seien hier noch weitere Sonderfälle von Produkten aufgeführt:

−	"QS-Plan"

Dieses Produkt wird von QS erstellt. Eine Prüfung mit Vergabe des Zustands "akzeptiert" sollte durch die Projektleitung bzw. durch Institutionen außerhalb des Projekts (z. B. QS-Beauftragter) erfolgen. (Siehe dazu auch die Abwicklungsregelung von Aktivität QS 1.1 "QS-Plan erstellen".)

−	"Änderungsvorschlag", "Änderungsauftrag", "Änderungsmitteilung"

Diese Produkte werden ohne Zustand geführt. Entscheidend für deren Behandlung ist der Status der betreffenden Änderung.

−	"Arbeitsauftrag" und "Berichtsdokumente"

Diese Produkte unterliegen keiner QS-Prüfung und werden im V-Modell ohne Zustände geführt.

Empfehlung:

Zur Absicherung der Ergebnisse der Entwicklungsarbeiten sollten Produkte gegebenenfalls schon vor der im V-Modell vorgeschriebenen abschließenden Produktprüfung einer (Teil-) Prüfung durch QS unterzogen werden. Dieser Weg sollte mindestens dann eingeschlagen werden, wenn

−	die Komplexität des Systems und damit der Umfang eines Produktes eine effektive Gesamtprüfung unverhältnismäßig erschwert oder

−	Teilprojekte definiert wurden, die einen gesicherten Produktstand voraussetzen.

Um eine solche Zwischenprüfung oder Teilproduktprüfung bzgl. QS und KM verwaltungstechnisch zu handhaben, muß das betreffende Produkt physikalisch in Teilprodukte aufgespalten werden, die jedoch aus Sicht von QS und KM wie eigenständige Produkte zu behandeln sind, d. h. mit separaten Produktprüfungen, damit verbundenen getrennten Produktzuständen und -attributen und eigenen Verweisen im KID.

Diese Maßnahme bietet sich beispielsweise an für eine Schnittstellenbeschreibung je Schnittstelle oder für Handbücher je Segment oder SW-Einheit bzw. HW-Einheit.


Überblick
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.1	Überblick

Während die drei Submodelle Qualitätssicherung (QS), Projektmanagement (PM) und Konfigurationsmanagement (KM) die begleitenden Aktivitäten in einem Entwicklungsprojekt beschreiben, wird die Entwicklung selbst im Submodell Systemerstellung (SE) durchgeführt.

Die Gliederung des Submodells SE ist geprägt durch Aktivitäten auf zwei verschiedenen Ebenen, nämlich

−	System- (Segment-) Ebene und

−	Ebene der Software- und Hardwareeinheiten (SW-Einheiten/HW-Einheiten).

Innerhalb dieser beiden Ebenen wird jeweils zwischen dem Schritt der Anforderungsanalyse und dem Schritt des Entwurfs unterschieden.

Diese Ebenen dienen aus Sicht des Systementwicklungsprozesses in den zeitlich frühen Aktivitäten dazu, von abstrakten Beschreibungen zur Software und Hardware zu gelangen, und in den späten Aktivitäten, um von der Software- und Hardwareebene aus zum Gesamtsystem zu kommen.

Folgende Begriffsklärungen und Erläuterungen sind für das Verständnis des nachfolgenden Regelungsteils von zentraler Bedeutung:

−	Auf der Systemebene ist das Zusammenspiel der Aktivitäten SE 1 und SE 2 entscheidend für die erfolgreiche Abstimmung zwischen Anwender und Realisierer und die Ableitung einer tragfähigen technischen Lösung aus den fachlichen Vorgaben.

−	Das Bindeglied zwischen den Aktivitäten SE 1 und SE 2 bildet die Teilaktivität SE 1.7 "Forderungscontrolling durchführen", die eine Abwägung der Anwenderforderungen einerseits und der Systemarchitektur andererseits vor dem Hintergrund der Realisierbarkeit und Wirtschaftlichkeit ermöglicht.

−	Die Erzeugnisstruktur  des V-Modells definiert, aus welchen generischen Bausteinen ein zu entwickelndes System grundsätzlich besteht.

−	Unter der Systemarchitektur (als technischer Architektur) wird die tatsächliche strukturelle Anordnung der Ausprägungen der generischen Bausteine dargestellt. Die technische Architektur beschreibt die Funktionsweise des Systems als netzartige Interaktion zwischen den konkreten Elementen des Systems.

−	Die Bestandteile der Systemarchitektur werden als Elemente  bezeichnet. Dies können Segmente oder SW-Einheiten/HW-Einheiten sein (siehe Abschnitt 2.1).

−	Die Systemarchitektur wird vollständig in der Aktivität SE 2 "System-Entwurf" bis zur Ebene der SW-Einheiten/HW-Einheiten verfeinert.

Die Formulierungen des Regelungsteils gehen davon aus, daß standardmäßig inkrementell entwickelt wird. D. h. die Regelungen des Submodells SE sind so zu verstehen, daß ein System in Stufen entwickelt (und evtl. ausgeliefert und betrieben) wird.

Im Vorgriff auf die Inhalte des Abschnitts 4.2 Die Aktivitäten des Submodells SE folgt eine zusammenfassende Übersicht über alle Aktivitäten und Produkte des Submodells SE sowie ein Funktionsüberblick zum Submodell SE (siehe Abbildung 4.1).

SE 1	System-Anforderungsanalyse

SE 1.1	Ist-Aufnahme/-Analyse durchführen

SE 1.2	Anwendungssystem beschreiben

SE 1.3	Kritikalität und Anforderungen an die
Qualität definieren

SE 1.4	Randbedingungen definieren

SE 1.5	System fachlich strukturieren

SE 1.6	Bedrohung und Risiko analysieren	⇒ Anwenderforderungen

SE 1.7	Forderungscontrolling durchführen	⇒ Protokoll

SE 1.8	Software-Pflege- und Änderungs-Konzept
erstellen	⇒ SWPÄ-Konzept

SE 2	System-Entwurf

SE 2.1	System technisch entwerfen

SE 2.2	Wirksamkeitsanalyse durchführen

SE 2.3	Realisierbarkeit untersuchen

SE 2.4	Anwenderforderungen zuordnen	⇒ Systemarchitektur

SE 2.5	Schnittstellen beschreiben

SE 2.6	System-Integration spezifizieren

SE 3	SW-/HW-Anforderungsanalyse

SE 3.1	Allgemeine Anf. aus Sicht der SW-/
HW-Einheit def.

SE 3.2	Anf. an die externen Schnittst. der SW-/
HW-Einheit präz.

SE 3.3	Anf. an die Funktionalität definieren

SE 3.4	Anf. an die Qualität der SW-/
HW-Einheit definieren

SE 3.5	Anf. an Entwicklungs- und SWPÄ-
Umgebung definieren	⇒ Technische Anforderungen

SE 4-SW	SW-Grobentwurf

SE 4.1-SW	SW-Architektur entwerfen	⇒ SW-Architektur,
⇒ Schnittst.-Übersicht

SE 4.2-SW	SW-interne und -externe Schnittstellen
entwerfen	⇒ Schnittstellenbeschreibung

SE 4.3-SW	SW-Integration spezifizieren	⇒ Integrationsplan

SE 5-SW	SW-Feinentwurf

SE 5.1-SW	SW-Komponente/-Modul/Datenbank
beschreiben	⇒ Datenkatalog

SE 5.2-SW	Betriebsmittel- und Zeitbedarf analysieren	⇒ SW-Entwurf

SE 6-SW	SW-Implementierung

SE 6.1-SW	SW-Module codieren

SE 6.2-SW	Datenbank realisieren

SE 6.3-SW	Selbstprüfung des SW-Moduls/
der Datenbank durchführen	⇒ Impl.-Dok. (SW-Modul)/SW-Modul
⇒ Impl.-Dok. (Datenb.)/Datenb.

SE 7-SW	SW-Integration

SE 7.1-SW	Zur SW-Komponente integrieren

SE 7.2-SW	Selbstprüfung der SW-Komponente
durchführen	⇒ Impl.-Dok. (SW-Komp.)/SW-Komp.

SE 7.3-SW	Zur SW-Einheit integrieren

SE 7.4-SW	Selbstprüfung der SW-Einheit durchführen	⇒ Impl.-Dok. (SW-Einh.)/SW-Einh.

SE 8	System-Integration

SE 8.1	Zum System integrieren

SE 8.2	Selbstprüfung des Systems durchführen	⇒ System

SE 8.3	Produkt bereitstellen	⇒ Betriebsinformationen
⇒ System (installierbar)

SE 9	Überleitung in die Nutzung

SE 9.1	Beitrag zur Einführungsunterstützung leisten

SE 9.2	System installieren	⇒ System (installiert)

SE 9.3	In Betrieb nehmen	⇒ System (in Betrieb)

Anmerkung zur Übersicht:

In der obigen Übersicht wird ein Produkt als Ergebnis derjenigen (Teil-) Aktivität aufgeführt, die das betreffende Produkt fertigstellt.

Abbildung 4.1: Funktionsüberblick Submodell SE


SE 1: System-Anforderungsanalyse
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Rahmenbedingungen		—	—
Extern	—		Externe Vorgaben (AG)		—	—
SE 2	akzeptiert		Systemarchitektur *)		—	—
—	—		Anwenderforderungen		SE 2, SE 3, SE 4-SW, SE 5-SW	vorgelegt
—	—		SWPÄ-Konzept		SE 9, PM 5	vorgelegt
—	—		Protokoll		PM 6	—
*)	Die Systemarchitektur ist dann Eingangsinformation, wenn ein Forderungscontrolling auf der Basis eines konkreten Architekturvorschlags durchgeführt werden soll.

Abwicklung

* Anwenderforderungen erarbeiten

Die Anwenderforderungen werden (in bezug auf das betrachtete System) als vollständige, fachliche Forderungen verstanden. Die Erfüllung der externen Vorgaben und der Anwenderforderungen ist am fertigen System durch Validierung nachzuweisen.

Die Aktivität SE 1 "System-Anforderungsanalyse" beinhaltet die Aufnahme und Analyse des Ist-Zustands. Je nach Entwicklungsziel erstreckt sich diese Ist-Aufnahme/-Analyse über mehrere Ebenen des bestehenden technischen Systems und betrachtet auch dessen organisatorische und technische Einbindung. Dabei werden Schwachstellen und deren Ursachen identifiziert.

Nachfolgend ist auf der Basis der externen Vorgaben ein Gesamthorizont für die Funktionalität des Systems zu spezifizieren. Dies geschieht in der Form einer groben Systembeschreibung, die den Rahmen für alle weiteren Verfeinerungen und Ergänzungen der Anwenderforderungen in nachfolgenden Entwicklungszyklen bildet.

In weiteren Schritten sind die technischen, organisatorischen und weiteren Randbedingungen sowie die Anforderungen an die Qualität festzuhalten, soweit sie aus den externen Vorgaben für die Systementwicklung erkennbar sind.

Anschließend ist das System fachlich zu strukturieren. Die Funktionalität des Systems ist in einer der Komplexität des Systems entsprechenden Detaillierung festzulegen, d. h. aus Anwendersicht ist die Kernfunktionalität klar zu beschreiben, und der Funktionsumfang ist im Sinne eines Gesamthorizonts  anzugeben.

Nachfolgend sind die möglichen Bedrohungen und Risiken zu analysieren. Als Ergebnis der Bedrohungs- und Risikoanalyse  werden evtl. weitere Anforderungen an das System definiert.

* Forderungscontrolling durchführen

Auf der Basis erster Architekturüberlegungen werden Betrachtungen zur Realisierbarkeit und zur Wirtschaftlichkeit angestellt, die zur Modifizierung der Anwenderforderungen führen können. Dies findet im Einvernehmen zwischen Anwender und Auftraggeber/Realisierer statt. Die Ergebnisse des Forderungscontrolling werden in einem Protokoll dokumentiert.

* Erarbeitung des SWPÄ-Konzepts

Im SWPÄ-Konzept wird der Rahmen für die SWPÄ im späteren Systembetrieb festgelegt. Organisation und Vorgehensweise in der SWPÄ werden beschrieben.


SE 1.1: Ist-Aufnahme/-Analyse durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.1	Ist-Aufnahme/-Analyse durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
—	—		Anwenderforderungen. Ist-Aufnahme und Ist-Analyse		SE 1.2−SE 1.6	in Bearb.
Abwicklung

Der Schwerpunkt der Ist-Aufnahme/-Analyse liegt auf der fachlichen, anwenderorientierten Seite. Im Rahmen dieser Aktivität sind Informationen über den Ist-Zustand zu beschaffen, zu analysieren und zu dokumentieren.

Erläuterung

Hier kann eine Organisationsanalyse durchgeführt werden. Im Rahmen einer Organisationsanalyse sind folgende Aspekte zu berücksichtigen:

−	Organisationsanalyse vorbereiten (Zielsetzung/Leistungen der fachlichen Aufgaben ermitteln, Analysetiefe festlegen, entsprechend Unterlagen für Workshops oder Fragebögen für Interviews vorbereiten),

−	Geschäftsprozesse  aufnehmen (Haupt- und Teilgeschäftsprozesse abgrenzen, Schnittstellen zwischen Prozessen festlegen, Geschäftsprozesse in einem Ist-Modell abbilden),

−	Geschäftsprozesse analysieren (Ist-Modell durch Einbeziehung der Prozeßbetroffenen und des Prozeßverantwortlichen evaluieren, Schwachstellen z. B. Redundanzen, Liegezeiten und deren Ursachen ermitteln. Bei sehr komplexen Geschäftsprozessen kann eine Simulation des Ist-Modells zur Evaluation sinnvoll sein.),

−	Analyseergebnisse auswerten (Vorschläge für Verbesserungen sammeln und priorisieren, u. a. Möglichkeiten für IT-Unterstützung ermitteln).

Die Analyseergebnisse dienen als Ausgangspunkt für die Definition von Anforderungen an eine künftige Aufbau- und Ablauforganisation beim Nutzer und als Basis für eine nachfolgende Geschäftsprozeßmodellierung sowie deren Umsetzung in die Praxis.

Empfehlung

Eine Organisationsanalyse sollte vor allem dann in Betracht gezogen werden, wenn die Erledigung fachlicher Aufgaben ohne eine wirksame IT-Unterstützung nicht oder nicht mehr gewährleistet werden kann. Dabei sind die möglichen Wechselwirkungen zwischen Organisationsentwicklung und Realisierung der zugehörigen IT-Unterstützung unbedingt zu beachten, da eine optimale Gestaltung der Aufbau- und Ablauforganisation beim Nutzer gleichzeitig einen Haupteinflußfaktor für die IT-Unterstützung darstellt (z. B. notwendige Ausstattung von Arbeitsplätzen mit Rechnerleistung, Peripherie, Software, Vernetzungs- und Kommunikationseinrichtungen) und umgekehrt technologische Neuerungen auf dem Gebiet der IT die Möglichkeiten zur Organisationsgestaltung unmittelbar beeinflussen können (z. B. beim Einsatz von Vorgangssteuerungs- und Archivierungssystemen).


SE 1.2: Anwendungssystem beschreiben
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.2	Anwendungssystem beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
SE 1.1	in Bearb.		Anwenderforderungen		—	—
—	—		Anwenderforderungen. Grobe Systembeschreibung, IT-Sicherheitsziel		SE 1.3−SE 1.6	in Bearb.
Abwicklung

Im Rahmen dieser Aktivität ist ein Gesamthorizont für die Funktionalität des Systems zu spezifizieren. Dies geschieht in Form einer groben Systembeschreibung, die den Rahmen für alle weiteren Verfeinerungen und Ergänzungen der Anwenderforderungen bildet.

Die Beschreibung des Gesamthorizonts hat insbesondere folgenden Kriterien zu genügen:

−	Es muß klar werden, welche fachlichen Aufgaben durch das System unterstützt werden sollen. Daher muß die Einordnung des Systems in die Organisation bzw. sein Integrationsumfeld beschrieben werden.

−	Der Gesamthorizont muß erkennbar machen, welche Gesamtfunktionalität im Endausbau abgedeckt werden soll und welche Prioritäten dabei im weiteren Verlauf erwartet werden.

−	Der Gesamthorizont muß das Einsatzkonzept soweit beeinhalten, daß daraus die technische und organisatorische Einsatzumgebung und die Randbedingungen (im Rahmen von Aktivität SE 1.4 "Randbedingungen definieren") ableitbar sind.

−	Der Gesamthorizont muß quantitative Abschätzungen enthalten, die es ermöglichen, grundsätzliche technische Entscheidungen in der richtigen Größenordnung zu treffen (Netzauslegung, Rechnerkapazitäten, usw.)

−	Die Darstellung des Gesamthorizonts muß so präzise erfolgen, daß im weiteren Verlauf jederzeit entscheidbar ist, wann dieser Gesamthorizont verlassen wird und dementsprechend technische Entscheidungen neu überdacht werden müssen.

−	Die Verwendung vordefinierter fachlicher Bausteine (Standardthemenbereiche) ist zu berücksichtigen. Mögliche Kandidaten zur Wiederverwendung auf der Ebene der Anwenderforderungen im Rahmen der beabsichtigten Entwicklung sind zu benennen.

Zusätzlich zu den operationellen Anforderungen an das System muß vom AG das IT-Sicherheitsziel vorgegeben werden. Das Sicherheitsziel können bestimmte Schutzziele für einige operationelle Funktionen oder verarbeitete Informationen hinsichtlich Verfügbarkeit, Integrität oder Vertraulichkeit (d. h. Verläßlichkeit) sein oder eine bereits vorgegebene Sicherheitspolitik, die im Gesamtsystem durchgesetzt werden soll. In den Anwenderforderungen muß vorgegeben werden, ob und welche Anforderungen an Verfügbarkeit, Integrität oder Vertraulichkeit von bestimmten Funktionen oder Informationen bestehen. Das IT-Sicherheitsziel ist die Grundlage für eine Bedrohungs- und Risikoanalyse, aus der die IT-Sicherheitsanforderungen für die Beseitigung von untolerierbaren Risiken hergeleitet werden. Die IT-Sicherheitsanforderungen müssen nachfolgend durch entsprechende IT-Sicherheitsmaßnahmen realisiert werden.


SE 1.3: Kritikalität und Anforderungen an die Qualität definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.3	Kritikalität und Anforderungen an die Qualität definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
SE 1.1, SE 1.2	in Bearb.		Anwenderforderungen		—	—
—	—		Anwenderforderungen. Kritikalität des Systems, Qualitätsforderungen		SE 1.4−SE 1.6	in Bearb.
Abwicklung

Die Kritikalität des Systems wird festgelegt und begründet.

Anforderungen hinsichtlich der Qualitätsmerkmale  aus der fachlichen Sicht des Anwenders sind zu definieren.

Basis ist die DIN ISO 9126.

Ausgangspunkt der Aktivität sind die externen Vorgaben, wie sie bei Auftragsvergabe festgelegt sind.


SE 1.4: Randbedingungen definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.4	Randbedingungen definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
SE 1.1−SE 1.3	in Bearb.		Anwenderforderungen		—	—
—	—		Anwenderforderungen. Randbedingungen		SE 1.5−SE 1.6	in Bearb.
Abwicklung

Als Randbedingungen sind technische, organisatorische und weitere Anforderungen festzuhalten.

* Technik

Die Definition von Randbedingungen betrifft insbesondere pauschale Anforderungen hinsichtlich der beim technischen Entwurf entstehenden Schnittstellen des Systems, z. B. Schnittstellenstandards.

* Organisation

Organisatorische Randbedingungen werden insbesondere durch Kommunikations-, Kooperations- und Koordinierungsbedarf gesetzt, der bei einer sachgerechten Abwicklung der Geschäftsprozesse zwischen den einzelnen Aufgabenträgern besteht.


SE 1.5: System fachlich strukturieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.5	System fachlich strukturieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
SE 1.1−SE 1.4	in Bearb.		Anwenderforderungen		—	—
—	—		Anwenderforderungen. Organisatorische Einbettung, Nutzung, Externe Schnittstellen, Beschreibung der Funktionalität		SE 1.6	in Bearb.
Abwicklung

Hier wird das System aus fachlicher Sicht strukturiert und beschrieben. Die fachliche Systemstruktur wird nach Gesichtspunkten der Anwenderwelt modelliert und beschrieben. Dazu gehört die Vorgabe der angestrebten Geschäftsprozesse. Für die Darstellung der Funktionsweise des Systems bzw. die Definition der Geschäftsprozesse sind Ablaufbeschreibungen festzulegen, die das Zusammenwirken des Nutzers mit dem System darstellen.

Die erstellten Beschreibungen müssen so detailliert sein, daß alle fachlichen Aspekte bestimmt und gegebenenfalls nötige Klärungen auf Systemebene zwischen Anwender und Realisierer des Systems vollständig und eindeutig herbeigeführt werden können.

Bei dieser Aktivität sind die Funktionsbereiche losgelöst von einer möglichen oder wahrscheinlichen technischen Architektur und Realisierung zu definieren.

Im Rahmen der Beschreibung der Funktionalität werden den Funktionsbereichen und den darunter liegenden Strukturelementen Kritikalitätsstufen zugeordnet.

Bei Funktionen zur Gewährleistung der Systemsicherheit sind auch die systemexternen IT-Sicherheitsmaßnahmen und -regelungen in die Betrachtung mit einzubeziehen, gegebenenfalls auch organisatorische Maßnahmen.

Die Aufbau- und Ablauforganisation beim Anwender ist festzulegen. Erforderliche personelle Maßnahmen sind zu identifizieren, und ihre Umsetzung ist einzuleiten.

Die erforderlichen Ausbildungsmaßnahmen sind zu planen (Festlegung der Zielgruppen, Schulungsinhalte, Trainer). Mit der Durchführung der Maßnahmen ist rechtzeitig zu beginnen. Die Dokumentation der durchzuführenden Maßnahmen wird nicht im V-Modell geregelt.


SE 1.6: Bedrohung und Risiko analysieren  5)
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.6	Bedrohung und Risiko analysieren 5)

5)	Die Bedrohungs- und Risikoanalyse findet unter dem Blickwinkel Security und Safety statt.

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Externe Vorgaben (AG)		—	—
SE 1.1−SE 1.5	in Bearb.		Anwenderforderungen		—	—
—	—		Anwenderforderungen. Bedrohungs- und Risikoanalyse, IT-Sicherheit		SE 1.7, SE 1.8, SE 2, SE 3, SE 4-SW, SE 5-SW	vorgelegt
Abwicklung

Voraussetzungen zur Durchführung dieser Aktivität sind die bisher definierten Anwenderforderungen und Informationen über die Einsatzumgebung des Systems. 6),  7)

6)	Bei Systemen, deren Bedrohungssituation noch nicht feststeht, muß eine fiktive Einsatzumgebung als Grundlage angenommen werden.

7)	Für Informationssysteme wird die Einsatzumgebung besonders von Aufbau- und Ablauforganisation geprägt.

Im Rahmen der Bedrohungs- und Risikoanalyse sind die für das System relevanten Bedrohungen zu ermitteln und die damit verbundenen Risiken unter Berücksichtigung von Eintrittswahrscheinlichkeiten und zu erwartenden Schäden zu bewerten.

Die Ergebnisse der Bedrohungs- und Risikoanalyse bilden die Grundlage für die Formulierung der Anforderungen an die IT-Sicherheit innerhalb der Anwenderforderungen.


SE 1.7: Forderungscontrolling durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.7	Forderungscontrolling durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Rahmenbedingungen		—	—
SE 1.6	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur *)		—	—
—	—		Protokoll		PM 6	—
*)	Die Systemarchitektur ist dann Eingangsinformation, wenn ein Forderungscontrolling auf der Basis eines konkreten Architekturvorschlags durchgeführt werden soll.

Abwicklung

Das Forderungscontrolling dient der Bewertung der aufgestellten Anwenderforderungen hinsichtlich Realisierbarkeit und Wirtschaftlichkeit und basiert auf ersten Architekturüberlegungen oder bereits auf einer konkreten Systemarchitektur. Dabei sind technische und organisatorische Rahmenbedingungen als externe Vorgaben zu beachten. 8)

8)	Diese können z. B. als spezifische Vorgaben des Anwendungsbereichs (IT-Ausrüstungsvorgaben, Hausstandards) im Rahmen einer querschnittlichen Unterstützung vorgegeben sein.

Die Anwenderforderungen werden anhand folgender Kriterien analysiert:

−	Plausibilität der definierten Anforderungen,

−	Plausibilität hoher IT-Sicherheitsanforderungen,

−	Beherrschbare Komplexität der aufgestellten Anforderungen,

−	Möglichkeiten für den Einsatz von Fertigprodukten,

−	Möglichkeiten der Realisierung über die vorhandene IT-Infrastruktur,

−	Reduzierung vorhabenspezifischer Ausprägungen,

−	Kostenschätzung für die einzelnen Anforderungen (soweit isolierbar).

Die Ergebnisse der Analyse führen gegebenenfalls zu Vorschlägen für Modifikation/Reduzierung von Anforderungen. Vorteile, die aus einer Modifikation/Reduzierung der ursprünglichen Anforderungen erwachsen, sind aufzuzeigen. Es ist sicherzustellen, daß die Modifikation/Reduzierung der Anwenderforderungen die Erreichbarkeit der Projektziele nicht gefährdet.

Die Ergebnisse des Forderungscontrolling sind in einem Protokoll zu dokumentieren. Sie sind auf Veranlassung des Projektmanagement in den Anwenderforderungen und in der Folge auch in den Technischen Anforderungen zu berücksichtigen (Aktivität PM 6).

Forderungscontrolling erfordert einen Dialog zwischen Anwendern und Vertretern der Auftraggeber. Stimmen die Ersteller der Anforderungsdokumente den Änderungsvorschlägen nicht zu, ist es Aufgabe des Projektmanagements, eine Entscheidung durch die entsprechenden verantwortlichen Instanzen herbeizuführen.


SE 1.8: Software-Pflege- und Änderungs-Konzept erstellen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 1	System-Anforderungsanalyse

SE 1.8	Software-Pflege- und Änderungs-Konzept erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1.6	akzeptiert		Anwenderforderungen		—	—
—	—		SWPÄ-Konzept		SE 9, PM 5	vorgelegt
Abwicklung

Ziel der Aktivität ist die Festlegung aller organisatorischer und technischer Maßnahmen für die Software-Pflege und -Änderung (SWPÄ) während des Betriebs. Dazu muß als Ausgangsbasis grundsätzlich die Strategie für die SWPÄ entschieden werden, z. B. ob und gegebenenfalls welche Anteile der SWPÄ nach extern vergeben werden sollen.

Gegebenenfalls kann das SWPÄ-Konzept parallel zum weiteren Entwicklungsgang ergänzt werden, wenn technische Entscheidungen Einfluß auf die Inhalte des SWPÄ-Konzepts haben.

Für das SWPÄ-Konzept sind zu berücksichtigen:

−	die erforderliche SWPÄ-Organisation in ihrem Aufbau unter Berücksichtigung der festgelegten Strategie,

−	die notwendigen personellen Ressourcen (z. B. temporär und permanent notwendige Kapazitäten, erforderliche Kenntnisse),

−	die Verteilung von Kompetenzen und Verantwortlichkeiten innerhalb der SWPÄ-Organisation,

−	die Beschreibung des Prozesses zur Durchführung der SWPÄ (z. B. Beantragung, Analyse und Klassifikation von Änderungen, Review und Migration von Änderungen, Konfigurationsverwaltung),

−	die SWPÄ von Fertigprodukten,

−	die technischen Einrichtungen, die für die SWPÄ erforderlich sind (z. B. Entwicklungs- und Prüfumgebungen).

Empfehlung

Die Erstellung des SWPÄ-Konzepts sollte so frühzeitig im Projekt beginnen, daß Anforderungen, die sich daraus für die Entwicklung bzw. Beschaffung ergeben, rechtzeitig berücksichtigt werden können.


SE 2: System-Entwurf
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Produktinformationen		—	—
PM 2	akzeptiert		Angebotsbewertung *)		—	—
PM 5	akzeptiert		Kosten-/Nutzenanalyse		—	—
SE 1	akzeptiert		Anwenderforderungen		—	—
—	—		Systemarchitektur		SE 1 **), SE 3, SE 4-SW, PM 4, PM 5	vorgelegt
—	—		Technische Anforderungen		SE 3	in Bearb.
—	—		Betriebsinformationen		SE 3	in Bearb.
—	—		Schnittstellenübersicht		SE 4-SW, KM 4	in Bearb.
—	—		Schnittstellenbeschreibung		SE 3, SE 4-SW, KM 4	in Bearb.
—	—		Integrationsplan		SE 4-SW, QS 3	in Bearb.
*)	Falls Fertigprodukte verwendet werden sollen.

**)	Falls ein Forderungscontrolling auf der Basis eines konkreten Architekturvorschlags durchgeführt werden soll.

Abwicklung

* Systemarchitektur erarbeiten

Auf der Basis der fachlichen Anforderungen und der Randbedingungen (Anwenderforderungen) wird ein Lösungsvorschlag für eine mögliche technische Struktur des Systems (Systemarchitektur) erarbeitet. 9) Dabei ist besonders auf den geeigneten Einsatz von Fertigprodukten zu achten.

9)	Falls notwendig, können mehrere, konkurrierende Lösungsvorschläge erarbeitet und weiterverfolgt werden.

Anhand von Realisierbarkeitsuntersuchungen basierend auf den Anwenderforderungen und den zur Verfügung stehenden Produktinformationen wird dieser Lösungsvorschlag bewertet. Die dort erzielten Ergebnisse hinsichtlich der Möglichkeiten zum Einsatz von Fertigprodukten sind bei der evtl. nachfolgenden Überarbeitung der Systemarchitektur zu berücksichtigen.

Für den Lösungsvorschlag wird eine Verfeinerung durchgeführt sowie die Zuordnung der Anwenderforderungen auf die Elemente der Systemarchitektur vorgenommen. So weit möglich sind Angaben für die Technischen Anforderungen abzuleiten.

Die Definition der Systemarchitektur endet mit der Identifikation der Schnittstellen (Schnittstellen des Systems zu seiner Umgebung (z. B. zum Nutzer und anderen Systemen) und Schnittstellen zwischen Elementen des Systems).

Jede in der Systemarchitektur identifizierte Schnittstelle ist in der Schnittstellenübersicht aufzuführen und in der Schnittstellenbeschreibung zu beschreiben.

* Integrationsplan erarbeiten

Sobald die Systemarchitektur feststeht, muß die Spezifikation der System-Integration begonnen werden. Im Integrationsplan ist die Integrationsstrategie festzuhalten und aufzuzeigen, welche Elemente, welche Maßnahmen und welche Hilfsmittel für die Integration des Systems erforderlich sind.

* Bereits erkennbare Betriebsinformationen dokumentieren

An dieser Stelle können bereits Informationen vorliegen, die für die Betriebsinformationen relevant sind. Aus den bisher vorliegenden Dokumenten sind deshalb gegebenenfalls all diejenigen Angaben zu übernehmen, die für die Anwenderdokumentation von Interesse sind.


SE 2.1: System technisch entwerfen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.1	System technisch entwerfen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 2	akzeptiert		Angebotsbewertung *)		—	—
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.2, SE 2.3	in Bearb.		Systemarchitektur		—	—
—	—		Systemarchitektur. Lösungsvorschläge, Technischer Aufbau, Identifikation der Schnittstellen, Zusammenarbeit der technischen Elemente, IT-Sicherheitskonzept, IT-Sicherheitsmodell		SE 2.2, SE 2.3, SE 2.4	in Bearb.
—	—		Betriebsinformationen		SE 2.6	in Bearb.
—	—		Technische Anforderungen		SE 2.6, SE 3	in Bearb.
—	—		Schnittstellenübersicht		SE 2.5, SE 4-SW, KM 4.3	in Bearb.
*)	Falls Fertigprodukte verwendet werden sollen.

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 SE 2.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 SE 1.5 "System fachlich strukturieren" definierten bzw. angesprochenen Bereiche formuliert. Dadurch werden fachliche abgrenzbare Problemstellungen betrachtet und in den nachfolgenden Realisierbarkeitsuntersuchungen bewertet.

* Systemarchitektur definieren

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 Technischen 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 Technischen Anforderungen an dieses Element anzugeben.

Sofern technische Anforderungen keinem Element der Systemarchitektur zugeordnet werden können, sind diese als allgemeine Anforderungen festzuhalten.

Bei den Technischen 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.

* Betriebsinformationen dokumentieren

Auf der Basis der Systemarchitektur und der Anwenderforderungen sind die systembezogenen Angaben für die Betriebsinformationen 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 SE 1.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-Sicherheitsanteils (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-Sicherheitsanteils zu den übrigen Elementen der Systemarchitektur und die Notwendigkeit jeder Schnittstelle innerhalb des IT-Sicherheitsanteils 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.


SE 2.2: Wirksamkeitsanalyse durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.2	Wirksamkeitsanalyse durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.1	in Bearb.		Systemarchitektur		—	—
—	—		Systemarchitektur. IT-Sicherheitskonzept		SE 2.1	in Bearb.
Abwicklung

Für die Wirksamkeit der IT-Maßnahmen (Funktionen und Konzepte) muß gezeigt werden, inwieweit diese

−	geeignet sind, den Bedrohungen entgegenzuwirken, - durch die Zuordnung von Bedrohungen zu IT-Maßnahmen,

−	konfliktfrei zusammenwirken und sich gegenseitig unterstützen - durch Aufzeigen und Analyse aller Beziehungen zwischen den IT-Maßnahmen,

−	mittels ausreichend starker Mechanismen realisiert sind - durch Analyse der Algorithmen, Prinzipien und Eigenschaften der verwendeten Mechanismen nach folgenden Aspekten:

•	inhärente Schwächen,

•	Aufwand für die Überwindung (z. B. Überwindung nach heutigem Wissensstand bzw. mit heute verfügbaren technischen Mitteln ausgeschlossen)

−	keine ausnutzbaren Schwachstellen besitzen - durch die Erstellung einer Liste der Konstruktionsschwachstellen mit Erklärung, warum sie in der Einsatzumgebung nicht für Angriffe ausgenutzt werden können.

Zu diesen Nachweisen der Wirksamkeit gehört z. B. auch die Analyse der verdeckten Kanäle, falls Informationsflußkontrolle eine der IT-Sicherheitsanforderungen ist.

Neben Schwachstellenanalysen können auch Penetrationsanalysen zum Nachweis der Wirksamkeit herangezogen werden.

Zur Wirksamkeitsanalyse kann auch die Durchführung von Tests notwendig sein.


SE 2.3: Realisierbarkeit untersuchen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.3	Realisierbarkeit untersuchen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Produktinformationen		—	—
PM 5	akzeptiert		Kosten-/Nutzenanalyse		—	—
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.1	in Bearb.		Systemarchitektur		—	—
—	—		Systemarchitektur. Realisierbarkeitsuntersuchungen		SE 2.1, PM 5	in Bearb.
Abwicklung

* Einsatz von Fertigprodukten prüfen

Unter dem Aspekt einer vorzugsweisen Nutzung von Fertigprodukten, ist es die primäre Aufgabe der Realisierbarkeitsuntersuchung, die Verfügbarkeit geeigneter Fertigprodukte zu bewerten. Hierzu wird auf Basis der Anwenderforderungen eine Marktsichtung auf Eignung von Fertigprodukten durchgeführt. Ziel ist es, Produkte zu identifizieren, die Teile des Systems abdecken können. Die Angemessenheit des Aufwandes für die Marktsichtung ist unter wirtschaftlichen Gesichtspunkten sicherzustellen. Die Ergebnisse der Marktsichtung sind als Grundlage zur Festlegung der Systemarchitektur mit zu verwenden.

* Bewertungskriterien festlegen

Als Basis der Realisierbarkeitsuntersuchung sind Bewertungskriterien für die Lösungsvorschläge festzulegen. Die Kriterien sind zu priorisieren und zu gewichten. In den Kriterien sind Gesichtspunkte wie Schnittstellenkomplexität, Verwendbarkeit von Fertigprodukten, Angemessenheit technischer Konzepte und der Entwicklungsvorgaben zu behandeln.

* Realisierbarkeit bewerten

Die Lösungsvorschläge der technischen Systemarchitektur sind in bezug auf die Erfüllung der fachlichen Anforderungen (Bereiche) zu untersuchen und anhand der festgelegten Kriterien zu bewerten.

Die technischen Entwurfsentscheidungen sind zu überprüfen und Analysen zur Aufdeckung von kritischen (Teil-) Produkten durchzuführen. Anforderungen an Personal, Ausbildung, Organisation, Logistik, Infrastruktur und Umweltschutz sind zu berücksichtigen.

Die Auswirkungen der Lösungsmöglichkeiten auf die Anwenderorganisation sind auf der Basis der Kosten-/Nutzenanalyse zu bewerten. Dies betrifft vor allem die praktische Umsetzbarkeit und Wirtschaftlichkeit (vorhandene bzw. geplante Planstellen, Verfügbarkeit geeigneter personeller Ressourcen, Personalentwicklungskonzepte, Übereinstimmung der Lösungsvorschläge mit Personalgesetzgebung und Tarifverträgen usw.).

* Spezielle Betrachtung zur IT-Sicherheit durchführen

Bei der Realisierbarkeitsuntersuchung sind im Hinblick auf IT-Sicherheit folgende Punkte zu beachten:

−	Die Auswahl der IT- und Nicht-IT-Maßnahmen, die technische Machbarkeit, die Wirtschaftlichkeit und die Tolerierbarkeit des Restrisikos sind zu überprüfen.

−	Die Abgrenzbarkeit des IT-sicherheitsrelevanten Teils vom nicht IT-sicherheitsrelevanten Teil ist zu prüfen.

Beim Entwurf des Systems ist zu prüfen, ob der IT-Sicherheitsanteil ausreichend abgegrenzt werden kann. Der Umfang des gesamten IT-Sicherheitsanteils (IT-sicherheitsspezifische und IT-sicherheitsrelevante Funktionen), der Gegenstand der Evaluation ist, muß so klein wie möglich gehalten werden, besonders dann, wenn eine hohe E-Stufe angestrebt wird.

−	Falls die Kontrolle des Informationsflusses ein IT-Sicherheitsziel ist, muß geprüft werden, ob bei der Strukturierung des Systems eine hinreichende Entflechtung der Elemente der Systemarchitektur, die später im operationellen Betrieb mit verschiedenen Einstufungen (unterschiedliche Security Levels) laufen, möglich ist, oder ob durch starke Abhängigkeiten unter einzelnen Elementen verdeckte Kanäle bereits vorprogrammiert sind.


SE 2.4: Anwenderforderungen zuordnen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.4	Anwenderforderungen zuordnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.1	in Bearb.		Systemarchitektur		—	—
—	—		Systemarchitektur. Anforderungszuordnung		SE 1 *), SE 2.5, SE 2.6, SE 3, SE 4-SW, PM 4, PM 5	vorgelegt
*)	Falls ein Forderungscontrolling auf der Basis eines konkreten Architekturvorschlags durchgeführt werden soll.

Abwicklung

* Anwenderforderungen zuordnen

In dieser Aktivität sind die an das System insgesamt gestellten Anwenderforderungen und Randbedingungen den Elementen der technischen Architektur zuzuordnen.

Diese Anforderungszuordnung stellt die Basis für die auf den tieferen Ebenen stattfindenden Anforderungsanalysen und Entwurfsschritte dar.

Es ist zu beachten, daß die Zuordnung von Forderungen und Randbedingungen zu den Elementen der technischen Architektur folgenden Kriterien genügen muß:

−	Jede Forderung muß auf mindestens ein Element der technischen Architektur, im Idealfall auf genau ein Architekturelement, zugeordnet werden.

−	Jede Forderung wird auf das in der Detaillierungsschichtung niedrigste Element zugeordnet, das die Erfüllung der Forderung vollständig ermöglicht. Im Normalfall muß die Gesamtmenge der Forderungen auf verschiedene Detaillierungsschichten zugeordnet werden.

−	Sofern eine Forderung von Element-übergreifender Bedeutung ist, muß im Rahmen der Zuordnung genau abgewägt werden, welche einzelnen Architekturelemente diese Anforderung letztendlich zu erfüllen haben.

−	Die Zuordnung muß so erfolgen, daß durch die Prüfung des entsprechenden Architekturelements die Erfüllung der Forderung nachgewiesen werden kann.

* IT-Sicherheitsanforderungen den IT-Sicherheitsmaßnahmen zuordnen

Mit der Zuordnung der IT-Sicherheitsanforderungen zu den IT-Sicherheitsmaßnahmen ist nachzuweisen, daß jede IT-Sicherheitsanforderung mit mindestens einer IT-Sicherheitsmaßnahme abgedeckt ist und ob das vorgegebene IT-Sicherheitsziel mit den gewählten IT-Sicherheitsmaßnahmen erreicht werden kann.


SE 2.5: Schnittstellen beschreiben
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.5	Schnittstellen beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2.4	akzeptiert		Systemarchitektur		—	—
SE 2.1	in Bearb.		Schnittstellenübersicht		—	—
—	—		Schnittstellenbeschreibung		SE 2.6, SE 3, SE 4-SW, KM 4.3	in Bearb.
Abwicklung

* Schnittstellen beschreiben

Alle Schnittstellen, die in der Schnittstellenübersicht identifiziert wurden, sind in der Schnittstellenbeschreibung zu spezifizieren. Dabei sind unter Berücksichtigung der Art der jeweiligen Schnittstelle und der beteiligten Architekturelemente die relevanten Angaben zu Verwendung, Syntax und Semantik der Schnittstelle zu dokumentieren.

* Schnittstellen der IT-Sicherheitsmaßnahmen zu den beteiligten Architekturelementen beschreiben

Die Schnittstellen der IT-Sicherheitsmaßnahmen zu den beteiligten Architekturelementen müssen dokumentiert werden.


SE 2.6: System-Integration spezifizieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 2	System-Entwurf

SE 2.6	System-Integration spezifizieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 2.4	akzeptiert		Systemarchitektur		—	—
SE 2.1	in Bearb.		Technische Anforderungen		—	—
SE 2.5	in Bearb.		Schnittstellenbeschreibung		—	—
SE 2.1	in Bearb.		Betriebsinformationen		SE 3	in Bearb.
—	—		Integrationsplan		SE 4-SW, QS 2	in Bearb.
Abwicklung

Im Integrationsplan ist festzulegen, wie die in der Systemarchitektur definierten Elemente zum Gesamtsystem zu integrieren sind. Die anzuwendende Strategie, durchzuführende Maßnahmen, eventuelle Restriktionen und Abhängigkeiten sowie notwendige Betriebs- und Hilfsmittel sind zu definieren.

Die Arbeiten am Integrationsplan liefern gleichzeitig Anhaltspunkte für die Betriebsinformationen. Aus den Angaben zur Integration werden Angaben zu Installation und Betrieb, zur Systemumgebung und den Systemkomponenten abgeleitet. Die Betriebsinformationen sind auf dieser Basis und anhand der vorliegenden Schnittstellenbeschreibung fortzuschreiben.


SE 3: SW-/HW-Anforderungsanalyse
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 2	in Bearb.		Schnittstellenbeschreibung		—	—
SE 2	in Bearb.		Betriebsinformationen		SE 4-SW/SE 4-HW	in Bearb.
SE 2	in Bearb.		Technische Anforderungen		SE 4-SW/SE 4-HW, SE 5-SW	vorgelegt
Abwicklung

Im Rahmen von Aktivität SE 3 "SW-/HW-Anforderungsanalyse" werden die Technischen Anforderungen und die Betriebsinformationen bezogen auf eine SW-Einheit oder eine HW-Einheit erweitert.

Den Ausgangspunkt dieser Aktivität bilden die Anwenderforderungen, die Systemarchitektur und die bereits vorab abgeleiteten Technischen Anforderungen. Auf dieser Basis sind allgemeine Anforderungen, Anforderungen an Schnittstellen, an die Funktionalität, an Qualitätsmerkmale und an SW-Entwicklungsumgebung und SWPÄ-Umgebung zu analysieren und zu definieren.

Die auf Systemebene erstellten Betriebsinformationen sind um SW-/HW-bezogene Angaben zu ergänzen. Auf der Basis der Technische Anforderungen sind all diejenigen Angaben zu erarbeiten, die für die Anwenderdokumentation notwendig sind.


SE 3.1: Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

SE 3.1	Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 2	in Bearb.		Technische Anforderungen		—	—
—	—		Technische Anforderungen. Allgemeine Anforderungen, Identifikation		SE 3.2-SE 3.5	in Bearb.
Abwicklung

Allgemeine Anforderungen, die sich im Rahmen der SW-/HW-Anforderungsanalyse aus Sicht der SW-Einheit/HW-Einheit ergeben, werden festgehalten. Dies können beispielsweise Anforderungen bezüglich der Realisierung der internen Schnittstellen sein   (z. B. durch die pauschale Benennung von Schnittstellenstandards).


SE 3.2: Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 2	in Bearb.		Schnittstellenbeschreibung		—	—
SE 3.1	in Bearb.		Technische Anforderungen		—	—
—	—		Technische Anforderungen. Schnittstellen		SE 3.3-SE 3.5	in Bearb.
Abwicklung

* Anforderungen an die technische Einsatzumgebung beschreiben

In dieser Aktivität sind die Anforderungen an die Einsatzumgebung und an weitere externe Schnittstellen  der SW-Einheit/HW-Einheit im operationellen Betrieb zu präzisieren.

Die Anforderungen an die Einsatzumgebung bestimmen die Einbettung der SW-Einheit/HW-Einheit, d. h. das Zusammenspiel der Software und Hardware mit externen Elementen des operationellen Betriebs. Die komplexen Umgebungsschnittstellen zwischen parallel und asynchron agierenden Objekten im operativen Einsatz sind zu beschreiben. Objekte in diesem Zusammenhang können SW-Einheiten/HW-Einheiten im gleichen System, Nutzer des Systems oder Geräte anderer Systeme sein. Definiert werden muß vor allem auch das geforderte Zeitverhalten.

* Anforderungen an die Nutzerschnittstelle definieren

Eine besondere Form der externen Schnittstelle von SW-Einheiten ist die Mensch-Maschine-Schnittstelle. Hier sind Anforderungen z. B. an bereitzustellende Dienste und auszutauschende Informationen, an Bildschirmaufbau, Syntax und Semantik der einzelnen Masken, Tastenbelegung, Druckformate und Listbilder zu präzisieren. Abzustimmen sind die Anforderungen mit derjenigen Seite, die mit der Entwicklung von Verfahrensbeschreibungen und Handbüchern beauftragt ist. Die wechselseitige Beeinflussung der Entwürfe von Mensch-Maschine-Schnittstellen und manuellen und automatisierten Verfahrensabläufen muß berücksichtigt werden.

* Anforderungen an die HW-Schnittstellen definieren

Für HW-Einheiten sind die Anforderungen an die Schnittstellen bzgl. elektrischer, optischer, mechanischer und gegebenenfalls weiterer Eigenschaften zu präzisieren. Die Schnittstelle zu HW-Einheiten kann auch eine HW-Nutzerschnittstelle (Knöpfe, Schalter, Tastaturen usw.) umfassen. Beachtung ist u. a. dem Zeitverhalten zu widmen (z. B. Datenübertragungsraten, Antwortzeitverhalten, Zykluszeiten, Busbreiten und Datenvolumen).


SE 3.3: Anforderungen an die Funktionalität definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

SE 3.3	Anforderungen an die Funktionalität definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3.1, SE 3.2	in Bearb.		Technische Anforderungen		—	—
—	—		Technische Anforderungen. Gesamtfunktion des Elements		SE 3.4, SE 3.5	in Bearb.
Abwicklung

In dieser Aktivität sind die Anforderungen an die technische Funktionalität der SW-Einheit/HW-Einheit zu definieren.

Die von der SW-Einheit/HW-Einheit zu realisierende Funktionalität ist zu identifizieren und festzuschreiben. Es sind Anforderungen an die Reaktionen der SW-Einheit/HW-Einheit im Normal- und Ausnahmefall zu definieren.

Die Funktionalität von HW-Einheiten umfaßt dabei auch elektrische, mechanische und optische Funktionsteile.


SE 3.4: Anforderungen an die Qualität der SW-/HW-Einheit definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

SE 3.4	Anforderungen an die Qualität der SW-/HW-Einheit definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3.1-SE 3.3	in Bearb.		Technische Anforderungen		—	—
—	—		Technische Anforderungen. Qualitätsforderungen		SE 3.5	in Bearb.
Abwicklung

Es sind Anforderungen bzgl. der nicht-funktionalen Qualitätsmerkmale  festzulegen.

Basis ist die DIN ISO 9126.


SE 3.5: Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 3	SW-/HW-Anforderungsanalyse

SE 3.5	Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3.1-SE 3.4	in Bearb.		Technische Anforderungen		—	—
—	—		Technische Anforderungen. Anforderungen an Entwicklungs- und SWPÄ-Umgebung		SE 4-SW/SE 4-HW, SE 5-SW	vorgelegt
SE 2	in Bearb.		Betriebsinformationen		SE 4-SW/SE 4-HW	in Bearb.
Abwicklung

Anforderungen an die Entwicklungs- und SWPÄ-Umgebung sind dann zu stellen, wenn diese von den entsprechenden Anforderungen an das System abweichen. Zur Entwicklungsumgebung zählen auch Integrations- und Prüfeinrichtungen, die während der Entwicklung und SWPÄ  einer SW-Einheit/HW-Einheit notwendig sind.

Auf der Basis der Technischen Anforderungen sind Angaben für die Betriebsinformationen bzgl. der SW-Einheit/HW-Einheit abzuleiten.


SE 4-SW: SW-Grobentwurf
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 4-SW	SW-Grobentwurf

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 2	in Bearb.		Schnittstellenbeschreibung		SE 5-SW, KM 4	vorgelegt
SE 2	in Bearb.		Schnittstellenübersicht		SE 5-SW, KM 4	vorgelegt
SE 2	in Bearb.		Integrationsplan		SE 7-SW, SE 8, QS 2	vorgelegt
SE 3	in Bearb.		Betriebsinformationen		SE 5-SW	in Bearb.
—	—		SW-Architektur		SE 5-SW	vorgelegt
Abwicklung

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 sind hier um Angaben für die betrachtete SW-Einheit zu ergänzen.


SE 4.1-SW: SW-Architektur entwerfen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 4-SW	SW-Grobentwurf

SE 4.1-SW	SW-Architektur entwerfen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 2	in Bearb.		Schnittstellenübersicht		SE 4.2-SW, SE 5-SW, KM 4.3	vorgelegt
SE 3	in Bearb.		Betriebsinformationen		SE 4.3-SW	in Bearb.
—	—		SW-Architektur		SE 4.2-SW, SE 4.3-SW, SE 5-SW	vorgelegt
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 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 10) in anderen SW-Komponenten/SW-Modulen/Datenbanken bei der Realisierung entstehen.

10)	Unter "IT-sicherheitsspezifischen oder IT-sicherheitsrelevanten Anteilen" werden auch die Funktionen hoher Kritikalität verstanden, die durch entsprechende Maßnahmen realisiert werden.

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äuterung

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.


SE 4.2-SW: SW-interne und -externe Schnittstellen entwerfen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 4-SW	SW-Grobentwurf

SE 4.2-SW	SW-interne und -externe Schnittstellen entwerfen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 4.1-SW	akzeptiert		SW-Architektur		—	—
SE 4.1-SW	akzeptiert		Schnittstellenübersicht		—	—
SE 2	in Bearb.		Schnittstellenbeschreibung		SE 4.3-SW, SE 5-SW, KM 4.3	vorgelegt
Abwicklung

Die beim Entwurf der SW-Architektur in der Schnittstellenübersicht identifizierten Schnittstellen sind in der Schnittstellenbeschreibung im einzelnen detailliert darzustellen. Bereits beschriebene Schnittstellen sind gegebenenfalls weiter zu präzisieren.

IT-Sicherheitsaspekte wie sie bereits bei der Identifikation der Schnittstellen eine Rolle spielten sind hier weiter und mit besonderer Sorgfalt zu verfolgen. Alle Schnittstellen der IT-sicherheitsspezifischen und IT-sicherheitsrelevanten SW-Komponenten/SW-Module müssen mit ihrem Zweck und ihren Parametern beschrieben werden. Die Separierung vom nicht IT-sicherheitsrelevanten Teil muß sichtbar sein.


SE 4.3-SW: SW-Integration spezifizieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 4-SW	SW-Grobentwurf

SE 4.3-SW	SW-Integration spezifizieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 4.2-SW	akzeptiert		Schnittstellenbeschreibung		—	—
SE 4.1-SW	akzeptiert		SW-Architektur		—	—
SE 4.1-SW	in Bearb.		Betriebsinformationen		SE 5-SW	in Bearb.
SE 2	in Bearb.		Integrationsplan		SE 7-SW, SE 8, QS 2	vorgelegt
Abwicklung

Für den Integrationsplan sind Vorschriften und Vorgehensweisen für den Zusammenbau der SW-Einheit aus SW-Komponenten und der SW-Komponenten selbst aus SW-Modulen und Datenbanken aus technischer Sicht zu regeln. Er ist im Hinblick auf Termine, Betriebs- und Hilfsmittel, Werkzeuge, Personal, Fertigprodukte, Schnittstellen und ähnliche Einflüsse in Absprache mit dem Projektmanagement zu erstellen. Im Integrationsplan sind die Konfigurierung der SW-Einheit und alle für die Integrationsaktivität benötigten Informationen festzuschreiben; Informationen für den Integrationstest sind abzuleiten und festzuhalten.

Die Arbeiten am Integrationsplan liefern gleichzeitig weitere Angaben für die Betriebsinformationen. Die Informationen zum Betriebshandbuch und die Informationen zum Diagnosehandbuch sind fortzuschreiben; insbesondere werden hier die Angaben bezüglich der Bereitstellung der Anlage und der Umgebungskomponenten sowie der Aufnahme und Beendigung des Betriebs ergänzt. In Sonstige Einsatzinformationen sind all diejenigen Besonderheiten festzuhalten, die die Installation und Konfiguration betreffen. Die vorliegende Schnittstellenbeschreibung gibt Anhaltspunkte für die Detaillierung der Informationen zum Anwendungshandbuch.


SE 5-SW: SW-Feinentwurf
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 5-SW	SW-Feinentwurf

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 4-SW	akzeptiert		SW-Architektur		—	—
SE 4-SW	akzeptiert		Schnittstellenübersicht		—	—
SE 4-SW	akzeptiert		Schnittstellenbeschreibung		—	—
KM 4.1	in Bearb.		Datenkatalog		KM 4/ SE 6-SW	in Bearb./ vorgelegt
—	—		SW-Entwurf		SE 6-SW	vorgelegt
SE 4-SW	in Bearb.		Betriebsinformationen		SE 8	in Bearb.
Abwicklung

Die Ausgangsbasis für diese Aktivität bilden die SW-Architektur und die Schnittstellenbeschreibung. Dort sind alle Informationen festgehalten, die erforderlich sind, um die Leistung eines SW-Moduls in Anspruch nehmen zu können. Die Vorgaben und Details für die Realisierung jedes SW-Moduls, jeder SW-Komponente und jeder Datenbank müssen festgelegt werden. Auf dieser Grundlage müssen sodann Betriebsmittel- und Zeitbedarf der einzelnen Architekturelemente und der gesamten SW-Einheit ermittelt werden, welche den diesbezüglichen Anforderungen Rechnung zu tragen haben.

Weiter sind die Betriebsinformationen um entwurfsbezogene Details zu ergänzen.


SE 5.1-SW: SW-Komponente/-Modul/Datenbank beschreiben
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 5-SW	SW-Feinentwurf

SE 5.1-SW	SW-Komponente/-Modul/Datenbank beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 4-SW	akzeptiert		SW-Architektur		—	—
SE 4-SW	akzeptiert		Schnittstellenübersicht		—	—
SE 4-SW	akzeptiert		Schnittstellenbeschreibung		—	—
KM 4.1	in Bearb.		Datenkatalog		KM 4.1/ SE 5.2-SW, SE 6-SW	in Bearb./ vorgelegt
—	—		SW-Entwurf. Beschreibung *)		SE 5.2-SW	in Bearb.
SE 4-SW	in Bearb.		Betriebsinformationen		SE 8	in Bearb.
*)	Komponenten-/Modulbeschreibung: bei SW-Feinentwurf einer SW-Komponente/eines SW-Moduls
Datenbankbeschreibung: bei SW-Feinentwurf einer Datenbank

Abwicklung

Gegenstand dieser Aktivität ist die softwaretechnische Realisierung der SW-Komponenten, SW-Module und Datenbanken. Die Konstruktion jedes SW-Moduls und jeder SW-Komponente bis auf die Ebene einer Programmiervorgabe muß beschrieben werden. Jede Datenbank ist bis auf ihre elementaren Bestandteile (Daten und Attribute) festzulegen.

Die Betriebsinformationen sind hier um entwurfsbezogene Details zu ergänzen. Die SW-Architektur und der SW-Entwurf bieten Anhaltspunkte für die weitere Bearbeitung der Betriebsinformationen.

*a) SW-Komponente/SW-Modul beschreiben:

Die SW-Komponenten und SW-Module müssen hinsichtlich ihrer Umgebung, der Realisierung ihrer Funktionalität, der Datenhaltung, Ausnahme- und Fehlerbehandlung, usw. spezifiziert und bis hin zu einer Programmiervorgabe formuliert werden.

*b) Datenbank beschreiben:

Vor dem Hintergrund des DB-Entwurfs in der SW-Architektur und abhängig von Zugriffshäufigkeiten müssen die Datenbanken hinsichtlich ihres Schemas bis hinunter auf Datenelementebene spezifiziert werden. Dabei ist jede Datenhaltung entsprechend ihrer typspezifischen Ausprägung detailliert zu beschreiben. Für Filesysteme werden dementsprechend die Satzaufbauten und die darin enthaltenen Datenelemente festgelegt. Bei hierarchischen Datenbanken werden die DB-Segmente, die darin enthaltenen Datenelemente und die DB-Segmenthierarchien definiert. Bei relationalen Datenbanken werden Tabellen, gegebenenfalls Views und die darin enthaltenen Datenelemente (u. a. auch die Fremdschlüssel) definiert. Ferner sind die Integritätsbedingungen festzulegen.

* Datenkatalog erstellen:

Die in der SW-Einheit benutzten Daten sind im Datenkatalog aufzunehmen. Die Eingangsinformationen für den Datenkatalog liefern die DB-bezogenen Informationen in der SW-Architektur und im SW-Entwurf. Im Datenkatalog sind implementierungsabhängige Informationen, wie Bezeichner, Datentyp, Datenformat, Lebensdauer, Zugriffsart, Zugriffs- und Entstehungszeiten und -frequenzen, Zuordnung zu Datenbanken, Speicherart, Speicherplatzbedarf usw. festzuhalten.

Da der Datenkatalog ein projektumfassendes Produkt ist, wird durch QS lediglich die Qualität der neu hinzugefügten Inhalte geprüft. Der Datenkatalog darf den Zustand "akzeptiert" nur erreichen, wenn die zentrale Datenadministration zustimmt (Aktivität KM 4.1 "Daten administrieren").

* Betriebsinformationen ergänzen:

Die Beschreibungen der SW-Module, SW-Komponenten und Datenbanken liefern die entwurfsbezogenen Angaben zur weiteren Vervollständigung der Betriebsinformationen. Auf dieser Basis sind die genauen Angaben zu Anwendung und Betrieb und zu Fehlerfällen bei Nutzung der Anwenderfunktionen (Informationen zum Anwendungshandbuch), zu den Diagnosemöglichkeiten und -maßnahmen (Informationen zum Diagnosehandbuch), zu Initialisierung, Beendigung und Überwachung des Betriebs (Informationen zum Betriebshandbuch) und zu Installation und Datenübernahme (Sonstige Einsatzinformationen) zu erstellen.


SE 5.2-SW: Betriebsmittel- und Zeitbedarf analysieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 5-SW	SW-Feinentwurf

SE 5.2-SW	Betriebsmittel- und Zeitbedarf analysieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 4-SW	akzeptiert		SW-Architektur		—	—
SE 4-SW	akzeptiert		Schnittstellenübersicht		—	—
SE 4-SW	akzeptiert		Schnittstellenbeschreibung		—	—
SE 5.1-SW	akzeptiert		Datenkatalog		—	—
SE 5.1-SW	in Bearb.		SW-Entwurf		—	—
—	—		SW-Entwurf. Kenngrößen		SE 6-SW	vorgelegt
Abwicklung

Hier erfolgt die Ermittlung und die Überprüfung des errechneten Bedarfs auf seine Realisierbarkeit. Auf der Basis der SW-Architektur und der SW-Komponenten-/SW-Modul- und Datenbankbeschreibung erfolgt die Ermittlung von benötigten Betriebsmitteln und des Zeitbedarfs. Die ermittelten Leistungsmerkmale sollten gegenüber den in den Technischen Anforderungen festgehaltenen Eigenschaften der SW-Einheit noch genügend Spielraum aufweisen, um spätere Pflege- und Änderungsmaßnahmen  ohne Redesign ausführen zu können. Ist dieser Spielraum nicht gegeben, so hat an dieser Stelle eine genaue Überprüfung der Realisierungsentscheidungen zu erfolgen.


SE 6-SW: SW-Implementierung
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 6-SW	SW-Implementierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-SW	akzeptiert		SW-Entwurf		—	—
SE 5-SW	akzeptiert		Datenkatalog		—	—
—	—		Implementierungsdokumente (SW-Modul)/SW-Modul		SE 7-SW	vorgelegt
—	—		Implementierungsdokumente (Datenbank)/Datenbank		SE 7-SW	vorgelegt
Abwicklung

Im Rahmen dieser Aktivität sind die SW-Module und Datenbanken der SW-Einheit zu realisieren und die Prozeduren zur Erzeugung der ausführbaren Dateien zu erstellen (Compile-, Binde-, Generierprozedur usw.). Der Code ist Selbstprüfungen  des Entwicklers zu unterziehen.


SE 6.1-SW: SW-Module codieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 6-SW	SW-Implementierung

SE 6.1-SW	SW-Module codieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-SW	akzeptiert		SW-Entwurf		—	—
SE 5-SW	akzeptiert		Datenkatalog		—	—
—	—		Implementierungsdokumente (SW-Modul)/SW-Modul		SE 6.3-SW	in Bearb.
Abwicklung

In der Aktivität "SW-Module codieren" muß die Programmiervorgabe (Pseudocode, Spezifikationssprache, o. ä.) in Anweisungen der Implementierungssprache (Programmiersprache, Abfragesprache, Scriptsprache usw.) umgesetzt werden. Mit übersetztem und gebundenem Code endet die Aktivität.

Zur Aktivität zählen folgende Arbeitsschritte:

−	Programmierung (unter Einhaltung der diesbezüglich im Projekthandbuch festgelegten Standards und Richtlinien),

−	Erstellung von

•	Compile-Prozeduren,

•	Binde-Prozeduren,

•	Lade-Prozeduren,

•	Installationsprozeduren und

•	Generierprozeduren,

−	Durchführung von Compile- und Bindeläufen,

−	Korrekturen bis zur Fehlerfreiheit des Compilierens und Bindens.


SE 6.2-SW: Datenbank realisieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 6-SW	SW-Implementierung

SE 6.2-SW	Datenbank realisieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-SW	akzeptiert		SW-Entwurf		—	—
SE 5-SW	akzeptiert		Datenkatalog		—	—
—	—		Implementierungsdokumente (Datenbank)/Datenbank		SE 6.3-SW	in Bearb.
Abwicklung

Die Schemadefinition der Datenbank(en) und die Beschreibungen der Indizes müssen in die festgelegte Datendefinitionssprache umgesetzt werden. Gegebenenfalls sind Angaben zur Lokation auf Speichermedien zu ergänzen. Erst mit den entsprechenden Generierungsläufen endet die Realisierung von Datenbanken.

Zur Realisierung von Datenbanken zählen folgende Arbeitsschritte:

−	Formulieren der Datenbankdefinition,

−	Erstellen von Prozeduren für Generierungsläufe,

−	Datenbankgenerierung,

−	Korrekturen bis zur Fehlerfreiheit der Datenbankgenerierung.


SE 6.3-SW: Selbstprüfung des SW-Moduls/der Datenbank durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 6-SW	SW-Implementierung

SE 6.3-SW	Selbstprüfung des SW-Moduls/der Datenbank durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-SW	akzeptiert		SW-Entwurf		—	—
SE 6.1-SW	in Bearb.		Implementierungsdokumente (SW-Modul)/SW-Modul		SE 7-SW	vorgelegt
SE 6.2-SW	in Bearb.		Implementierungsdokumente (Datenbank)/Datenbank		SE 7-SW	vorgelegt
Abwicklung

Vom Entwickler sind Selbstprüfungen  der von ihm realisierten SW-Module und Datenbanken durchzuführen. Bei den Selbstprüfungen sind zunächst Prüfvoraussetzungen wie Installation des Prüfgegenstandes in der Prüfumgebung und Generierung der benötigten Prüffälle herzustellen. Nach der Durchführung der Prüfung erfolgt die Auswertung der Prüfergebnisse, die den weiteren Entwicklungsverlauf bestimmt. Sofern die Prüfung aus Sicht von SE erfolgreich war, erfolgt die Weitergabe des Prüfgegenstandes an QS zum Zweck der formellen Produktprüfung, sonst sind Iterationen von SE-Aktivitäten erforderlich, die mit einer erneuten Selbstprüfung des Produktes abzuschließen sind.

Empfehlung

Bei hoher Kritikalität  sollten bei der Selbstprüfung eines SW-Moduls bzw. einer Datenbank die gleichen Maßstäbe angesetzt werden wie bei der nachfolgenden formellen QS-Prüfung, d. h. die Vorschriften in Prüfplan, Prüfspezifikation und Prüfprozedur sollten eingehalten werden.


SE 7-SW: SW-Integration
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 7-SW	SW-Integration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 6-SW	akzeptiert		Implementierungsdokumente (SW-Modul)/SW-Modul		—	—
SE 6-SW	akzeptiert		Implementierungsdokumente (Datenbank)/Datenbank		—	—
SE 4-SW	akzeptiert		Integrationsplan		—	—
—	—		Implementierungsdokumente (SW-Einheit)/SW-Einheit		SE 8	vorgelegt
Abwicklung

Hier hat die Integration der SW-Module bzw. Datenbanken, gegebenenfalls in mehreren Schritten, zur SW-Einheit zu erfolgen. Als Zwischenstufen sind Teilstrukturen  der SW-Einheit möglich, die sich durch Integration von SW-Modulen, Datenbanken, SW-Komponenten und bereits integrierter Teilstrukturen ergeben.


SE 7.1-SW: Zur SW-Komponente integrieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 7-SW	SW-Integration

SE 7.1-SW	Zur SW-Komponente integrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 6-SW	akzeptiert		Implementierungsdokumente (SW-Modul)/SW-Modul		—	—
SE 6-SW	akzeptiert		Implementierungsdokumente (Datenbank)/Datenbank		—	—
SE 4-SW	akzeptiert		Integrationsplan		—	—
—	—		Implementierungsdokumente (SW-Komponente)/ SW-Komponente		SE 7.2-SW	in Bearb.
Abwicklung

Eine SW-Teilstruktur 11) kann ein oder mehrere SW-Module, Datenbanken oder SW-Komponenten umfassen. Darüber hinaus kann eine SW-Teilstruktur Platzhalter  (Stubs  oder Treiber) enthalten. Diese Platzhalter werden bei wiederholtem Durchlauf durch Aktivität SE 7.1-SW "Zur SW-Komponente integrieren", spätestens jedoch bei der Integration zur SW-Einheit, durch die entsprechenden operationellen SW-Module ersetzt. Bei jeder Durchführung dieser Aktivität wird aus einer oder mehreren vorgegebenen SW-Teilstrukturen eine neue SW-Teilstruktur höheren Integrationsgrades hergestellt. Dies wird z. B. erreicht durch

11)	Eine SW-Teilstruktur ist ein Zwischenprodukt, das nur während Aktivität SE 7.1-SW "Zur SW-Komponente integrieren" in Erscheinung tritt und daher nicht in eine andere Aktivität eingeht.

−	Integration bisher unverbundener Teilstrukturen,

−	Austausch von Platzhaltern gegen operationelle Teilstrukturen,

−	Ersetzen von Teilstrukturen durch verbesserte Versionen,

−	Einbinden von Fremdprodukten,

−	Auflösung von Prototypen,

−	Austausch von Simulatoren oder Emulatoren durch operative Hardware oder Software.

Zu Integrationszwecken kann es erforderlich sein, daß zusätzlich zu den vorhandenen SW-Modulen Code erstellt oder Prozeduren geschrieben werden müssen.

Die SW-Komponenten sind anschließend einzeln der Selbstprüfung (Aktivität SE 7.2-SW "Selbstprüfung der SW-Komponente durchführen") zu unterziehen. Hierbei darf die SW-Komponente noch Platzhalter  enthalten.

Erläuterung

Die Anordnung der SW-Module, Datenbanken und SW-Komponenten in der Erzeugnisstruktur legt eine Bottom-up-Integrationsstrategie  nahe. Dies ist jedoch nur eine unter mehreren möglichen Vorgehensweisen. Weitere Beispiele für Integrationsstrategien sind:

−	Top-down-Integration,

−	Sandwich-Integration,

−	vorgezogene Integration der kritischen  und wichtigen Funktionen,

−	Integrationsfolge in Anlehnung an organisatorische Gegebenheiten und Zuständigkeiten,

−	Integration orientiert an den Funktionen oder Prozessen der SW-Einheit,

−	vorgezogene Integration des Basissystems (alle zentralen, mehrfach genutzten Funktionen),

−	Integration entsprechend der Abhängigkeit der Integrationsobjekte.

Die SW-Teilstruktur tritt nur vorübergehend, während der SW-Integration, in Erscheinung. Sie ist eine Hilfskonstruktion, die die SW-Integration nach beliebigen Strategien ermöglicht. Am Ende der SW-Integration steht die SW-Einheit mit ihrer Untergliederung in SW-Komponenten und SW-Module bzw. Datenbanken.

Die einzelnen Schritte der SW-Integration sind im Integrationsplan festgelegt.


SE 7.2-SW: Selbstprüfung der SW-Komponente durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 7-SW	SW-Integration

SE 7.2-SW	Selbstprüfung der SW-Komponente durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 7.1-SW	in Bearb.		Implementierungsdokumente (SW-Komponente)/ SW-Komponente		SE 7.3-SW	vorgelegt
Abwicklung

Vom Entwickler sind Selbstprüfungen  der SW-Komponenten durchzuführen.

Der Ablauf der Selbstprüfung erfolgt analog Aktivität SE 6.3-SW "Selbstprüfung des SW-Moduls/der Datenbank durchführen".

Empfehlung

Bei hoher Kritikalität  sollten bei der Selbstprüfung einer SW-Komponente die gleichen Maßstäbe angesetzt werden wie bei der nachfolgenden formellen QS-Prüfung, d. h. die Vorschriften in Prüfplan, Prüfspezifikation und Prüfprozedur sollten eingehalten werden.


SE 7.3-SW: Zur SW-Einheit integrieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 7-SW	SW-Integration

SE 7.3-SW	Zur SW-Einheit integrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 6-SW	akzeptiert		Implementierungsdokumente (SW-Modul)/SW-Modul		—	—
SE 6-SW	akzeptiert		Implementierungsdokumente (Datenbank)/Datenbank		—	—
SE 7.2-SW	akzeptiert		Implementierungsdokumente (SW-Komponente)/ SW-Komponente		—	—
SE 4-SW	akzeptiert		Integrationsplan		—	—
—	—		Implementierungsdokumente (SW-Einheit)/SW-Einheit		SE 7.4-SW	in Bearb.
Abwicklung

In dieser Aktivität werden SW-Module, Datenbanken und SW-Komponenten zur SW-Einheit integriert. Dies erfolgt analog zu Aktivität SE 7.1-SW "Zur SW-Komponente integrieren" und kann nach unterschiedlichen Vorgehensweisen (festgelegt im Integrationsplan) geschehen.

Die resultierende SW-Einheit muß frei von Platzhaltern sein.


SE 7.4-SW: Selbstprüfung der SW-Einheit durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 7-SW	SW-Integration

SE 7.4-SW	Selbstprüfung der SW-Einheit durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 7.3-SW	in Bearb.		Implementierungsdokumente (SW-Einheit)/SW-Einheit		SE 8	vorgelegt
Abwicklung

Vom Entwickler sind Selbstprüfungen  der SW-Einheit durchzuführen.

Der Ablauf der Selbstprüfung erfolgt analog Aktivität SE 6.3-SW "Selbstprüfung des SW-Moduls/der Datenbank durchführen".

Empfehlung

Die Selbstprüfung  einer SW-Einheit sollte insbesondere umfassen:

−	Prüfung der Funktionalität der SW-Einheit,

−	Prüfung der Zuverlässigkeit, der Effizienz und des Realzeitverhaltens der SW-Einheit,

−	Prüfung der Benutzbarkeit, Änderbarkeit und Übertragbarkeit,

−	Prüfung der SW-internen Schnittstellen  zwischen SW-Modulen, Datenbanken, SW-Komponenten, Prozessen,

−	Prüfung der SW-externen  Schnittstellen.

Bei hoher Kritikalität  sollten bei der Selbstprüfung einer SW-Einheit die gleichen Maßstäbe angesetzt werden wie bei der nachfolgenden formellen QS-Prüfung, d. h. die Vorschriften in Prüfplan, Prüfspezifikation und Prüfprozedur sollten eingehalten werden.


SE 8: System-Integration
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 8	System-Integration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 7-SW	akzeptiert		Implementierungsdokumente (SW-Einheit)/SW-Einheit		—	—
SE 7-HW	akzeptiert		HW-Einheit		—	—
Extern	—		Nicht-IT-Anteile		—	—
SE 4-SW	akzeptiert		Integrationsplan		—	—
SE 5-SW	in Bearb.		Betriebsinformationen		SE 9	vorgelegt
—	—		System (installierbar)		SE 9	vorgelegt
Abwicklung

Die Integration des Systems aus SW-Einheiten, HW-Einheiten und Nicht-IT-Anteilen hat gemäß Systemarchitektur und unter Einhaltung der im Integrationsplan getroffenen Regelungen zu erfolgen.

Ein System kann vorübergehend Platzhalter für noch nicht vorhandene Elemente enthalten. Ein solches System wird teilintegriert  genannt. Dies bedeutet, daß die Aktivitäten von SE 8 "System-Integration" gegebenenfalls mehrfach durchlaufen werden, solange bis alle Platzhalter  im System ersetzt sind.

Die Betriebsinformationen sind abzuschließen.


SE 8.1: Zum System integrieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 8	System-Integration

SE 8.1	Zum System integrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 7-SW	akzeptiert		Implementierungsdokumente (SW-Einheit)/SW-Einheit		—	—
SE 7-HW	akzeptiert		HW-Einheit		—	—
Extern	—		Nicht-IT-Anteile		—	—
SE 4-SW	akzeptiert		Integrationsplan		—	—
—	—		System		SE 8.2	in Bearb.
Abwicklung

In dieser Aktivität werden SW-Einheiten, HW-Einheiten und gegebenenfalls Nicht-IT-Anteile zum System integriert. Es ist gemäß Integrationsplan vorzugehen, der die durchzuführenden Integrationsmaßnahmen beschreibt.

Unter Umständen werden die spezifizierten Architekturelemente zunächst zu Segmenten integriert. Falls Segmente vorgesehen sind, sind Selbstprüfungen auch für Segmente durchzuführen.

Falls Selbstprüfungen (Aktivität SE 8.2 "Selbstprüfung des Systems durchführen") erforderlich sind, obwohl noch nicht alle Elemente für die Integration bereitstehen, so sind für die fehlenden Elemente Platzhalter  vorzusehen.


SE 8.2: Selbstprüfung des Systems durchführen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 8	System-Integration

SE 8.2	Selbstprüfung des Systems durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 8.1	in Bearb.		System		SE 8.3	vorgelegt
Abwicklung

Es sind Selbstprüfungen  des Systems und gegebenenfalls der Segmente durchzuführen. In dieser Aktivität sind die SW-Einheiten auf der definierten Ziel-Hardware zu überprüfen.

Bei den Selbstprüfungen sind zunächst Prüfvoraussetzungen wie Installation des Systems in der Prüfumgebung und Festlegung der benötigten Prüffälle herzustellen. Nach der Durchführung der Prüfung erfolgt die Auswertung der Prüfergebnisse, die die weitere Vorgehensweise bestimmt.

Sofern die Prüfung aus Sicht von SE erfolgreich war, erfolgt die Weitergabe des Systems an QS zum Zweck der formellen Produktprüfung, sonst sind Iterationen von SE-Aktivitäten erforderlich, die mit einer erneuten Selbstprüfung des Systems abzuschließen sind.

Empfehlung

Die Selbstprüfung  von Segmenten (bzw. des Systems bei Wegfall einer Segmentebene) sollte umfassen:

−	Prüfung gegen die Technischen Anforderungen hinsichtlich der dort definierten Qualitätsmerkmale

−	Prüfung des technischen und funktionalen Zusammenwirkens, insbesondere auch der SW/HW-Schnittstellen

−	Prüfung des Segments auf der Ziel-Hardware unter annähernd realen Bedingungen durch Simulation der Systemumgebung und mit Unterstützung durch SW/HW-Diagnose-Werkzeuge

−	Prüfung im Hinblick auf

•	Unterbrechungs- und E/A-Signal-Verarbeitung

•	Synchronisation und Kommunikation von Prozessoren

•	Fehlererkennung und -toleranz

•	Prüfung der Mensch-Maschine-Schnittstellen auf die Einhaltung ergonomischer und Software-ergonomischer Gestaltungsgrundsätze

Die Selbstprüfung  des Systems sollte umfassen:

−	Prüfung gegen die Anwenderforderungen und die Systemarchitektur

−	Prüfung zunächst in einer speziellen Prüfumgebung (z. B. Prototyp, Test-Rig usw.); die abschließende Systemprüfung hat in der operativen Einsatzumgebung oder kompatiblen Referenzanlage stattzufinden.

−	Prüfung des technischen und funktionalen Zusammenwirkens mit dem Hauptaugenmerk auf

•	Systembelastung hinsichtlich Effizienz und Robustheit

•	Verhalten in "Worst-case"-Bedingungen

•	Demonstration der Systemsicherheit

•	typische Situationen und Bedingungen

•	kritische Situationen  und Funktionen

−	Prüfung des Zusammenwirkens von System/Segment und Nutzer hinsichtlich

•	Nutzerbelastung

•	typischer Situationen und ihrer Bedienung

•	kritischer Situationen und der Auswirkung von Fehlbedienung

Die reale Einsatzumgebung kann simuliert werden.

Bei hoher Kritikalität  sollten bei der Selbstprüfung eines Systems die gleichen Maßstäbe angesetzt werden wie bei der nachfolgenden formellen QS-Prüfung, d. h. die Vorschriften in Prüfplan, Prüfspezifikation und Prüfprozedur sollten eingehalten werden.


SE 8.3: Produkt bereitstellen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 8	System-Integration

SE 8.3	Produkt bereitstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-SW	in Bearb.		Betriebsinformationen		SE 9	vorgelegt
SE 8.2	akzeptiert		System		—	—
—	—		System (installierbar)		SE 9	vorgelegt
Abwicklung

Zur Unterstützung der Einführung des Systems sind folgende Maßnahmen durchzuführen:

* Abschluß der Betriebsinformationen

Die Informationen zum Betriebshandbuch, Informationen zum Anwendungshandbuch, Informationen zum Diagnosehandbuch und Sonstige Einsatzinformationen für das System, die entwicklungsbegleitend erstellt wurden, sind zu vervollständigen und abzuschließen.

* Bereitstellung eines Installierbaren Systems

Das System ist in einer installierbaren Form (z. B. auf geeigneten Datenträgern wie Disketten, CD-ROM etc.) zur Verfügung zu stellen.


SE 9: Überleitung in die Nutzung
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 9	Überleitung in die Nutzung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 8	akzeptiert		Betriebsinformationen		—	—
SE 1	akzeptiert		SWPÄ-Konzept		—	—
SE 8	akzeptiert		System (installierbar)		—	—
—	—		System (installiert und in Betrieb)		Extern (AG)	—
Abwicklung

Diese Aktivität umfaßt Tätigkeiten, die notwendig sind, um ein fertiggestelltes System an der vorgesehenen Einsatzstelle zu installieren und in Betrieb zu nehmen. Falls mehrere Einsatzstellen vorgesehen sind, ist die Aktivität entsprechend mehrfach einzuplanen und an den verschiedenen Einsatzstellen durchzuführen. Voraussetzung für die Durchführung der Installation ist der Abschluß aller erforderlichen Infrastrukturmaßnahmen.


SE 9.1: Beitrag zur Einführungsunterstützung leisten
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 9	Überleitung in die Nutzung

SE 9.1	Beitrag zur Einführungsunterstützung leisten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 8	akzeptiert		Betriebsinformationen		—	—
Abwicklung

Zur Unterstützung der Einführung des Systems sind folgende Maßnahmen durchzuführen.

* Infrastruktur

Die Durchführung aller notwendigen Infrastrukturmaßnahmen ist abzuschließen.

* Ausbildung

Die Durchführung aller notwendigen Ausbildungsmaßnahmen ist abzuschließen.

* Personal

Das für die Nutzung erforderliche Personal (z. B. System- und Nutzerbetreuung, SWPÄ-Personal) ist auszuwählen und bereitzustellen.

* Organisation

Die Festlegung der Aufbau- und Ablauforganisation für die Nutzung ist ebenso abzuschließen wie die Einarbeitung der zukünftigen Arbeitsabläufe in die entsprechenden Regelungen des Anwenders.

* Überleitung

Es sind alle Maßnahmen zu definieren und zu planen, die für die Überleitung des Systems in die Nutzung erforderlich sind. Dazu zählen u. a.:

−	Vorgehen bei der Überleitung (Datenübernahme, Parallellauf, Übergangsregelungen etc.),

−	Zuständigkeiten.

Erläuterung

Die Dokumentation der im Rahmen der Einführungsunterstützung durchgeführten Maßnahmen wird im V-Modell nicht geregelt. Je nach Erfordernis sind zu einzelnen Themen separate Dokumente zu erstellen (z. B. Infrastrukturkonzept, Ausbildungskonzept, Organisationskonzept, Überleitungsplan).


SE 9.2: System installieren
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 9	Überleitung in die Nutzung

SE 9.2	System installieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 8	akzeptiert		Betriebsinformationen		—	—
SE 1	akzeptiert		SWPÄ-Konzept		—	—
SE 8	akzeptiert		System (installierbar)		—	—
—	—		System (installiert)		SE 9.3	vorgelegt
Abwicklung

Die Installation des Systems am vorgesehenen Einsatzort umfaßt das Zusammenfügen und Installieren der einzelnen Bestandteile des Systems (Hardware und Software) sowie die Herstellung eines betriebsbereiten Zustandes.

Für das Betriebs- und SWPÄ-Personal ist eine Einweisung am installierten System durchzuführen. Neben der Einweisung in die Handbücher und technischen Unterlagen sind typische Abläufe des Systems (z. B. Einschalten/Hochfahren des Systems, Ausführen wichtiger Funktionen usw.) zu demonstrieren. Hierbei sind sowohl Normal- als auch Ausnahmesituationen zu berücksichtigen.

Erläuterung

Im Rahmen der Installation können beispielsweise folgende Aktionen notwendig sein:

−	Entpacken des Systems,

−	Prüfen der Liefervollständigkeit,

−	Bereitstellen der Handbücher und der technischen Unterlagen,

−	Aufstellen und Anschließen der Systemteile,

−	Auffüllen der Ersatzteil- und Verbrauchsgüterbestände,

−	Schrittweise Inbetriebnahme/Einschalttests von Einzelkomponenten,

−	vorgesehene Konfiguration einrichten,

−	Verbinden aller Systemteile,

−	Anschließen an Netzwerke, Ferndiagnose usw.,

−	Funktionsprüfung des Gesamtsystems,

−	Installieren vorgesehener Schutzmaßnahmen (z. B. hinsichtlich IT-Sicherheit) und Überprüfen von deren Wirksamkeit.


SE 9.3: In Betrieb nehmen
Teil 1	Vorgehensmodell / Regelungsteil

4	Regelungen Submodell Systemerstellung

4.2	Die Aktivitäten des Submodells SE

SE 9	Überleitung in die Nutzung

SE 9.3	In Betrieb nehmen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 8	akzeptiert		Betriebsinformationen		—	—
SE 9.2	akzeptiert		System (installiert)		—	—
—	—		System (in Betrieb)		Extern (AG)
Abwicklung

Ziel der Aktivität ist es, das installierte IT-System in Betrieb zu nehmen, für die Abnahmeprüfung vorzubereiten und den reibungslosen Übergang zur Arbeit mit dem neuen IT-System sicherzustellen.

Zur Unterstützung der Inbetriebnahme sind folgende Maßnahmen durchzuführen:

−	Auswahl und Bereitstellung von

•	Inbetriebnahme - Dokumentation

•	Repository - Daten (Datenbanksysteme)

•	Startparametern

−	Einlesen der Daten

−	Technische Inbetriebnahme

−	Registrierung aller für die Inbetriebnahme verwendeten Daten (Parameter, Dateien etc.)

−	Personaleinweisung (Einweisung der Nutzer hinsichtlich Inbetriebnahme)

Erläuterung

Sofern ein Altverfahren existiert, sind alle Datenbestände, die im neuen System benötigt werden, aus dem Altverfahren zu übernehmen. Erforderliche Ersterfassungen von Daten sind durchzuführen.

Gegebenenfalls sind zur Sicherstellung eines einwandfreien Betriebs für eine bestimmte Zeitspanne die alten Arbeitsabläufe/das alte System und das neue System im Parallelbetrieb anzuwenden.

Die ordnungsgemäße Ausmusterung des Altsystems (z. B. Beenden von Lizenzen, Löschen der Datenbestände, Entsorgung/Abgabe des Altsystems usw.) ist gemäß den gesetzlichen Bestimmungen durchzuführen.

Die Inbetriebnahme ist eine der Voraussetzungen für die Abnahme.


Überblick
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

Die Regelungen des Submodells Qualitätssicherung (QS) berühren in keiner Weise organisatorische Festlegungen. Wie die Aktivitäten des Submodells QS in einem Projekt von Personen oder Organisationseinheiten auszuführen sind, wird nicht im V-Modell geregelt.

Qualität wird definiert als "die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen" (/DIN ISO 8402/).

Die aufgestellten Anforderungen an das zu entwickelnde System werden im Laufe des Projekts durch detailliertere Anforderungen verfeinert und in den Produkten "Anwenderforderungen" und "Technische Anforderungen" festgehalten. Die im Submodell "Qualitätssicherung" (QS) beschriebenen Maßnahmen dienen dem Nachweis der Erfüllung dieser vorgegebenen Anforderungen, der präventiven Vermeidung von Mängeln und der Sicherstellung einer Prozeßqualität.

Zum einen wird Softwarequalität durch den Einsatz konstruktiver Maßnahmen erreicht (vgl. Abschnitt 5.1.1).

Zum anderen werden konstruktive Maßnahmen durch analytische Maßnahmen ergänzt (vgl. Abschnitt 5.1.2).

Bei Projekten mit Auftragsvergabe an externe (industrielle) Auftragnehmer ist durch geeignete Vertragsvereinbarungen dafür zu sorgen, daß der Auftraggeber in angemessener Form an den Qualitätssicherungsmaßnahmen beteiligt ist. (Diese Beteiligung ist detailliert im QS-Plan festzuhalten.)

Im Vorgriff auf die Inhalte des Abschnitts 5.2 Die Aktivitäten des Submodells QS folgt eine zusammenfassende Übersicht über alle Aktivitäten und Produkte des Submodells QS sowie ein Funktionsüberblick zum Submodell QS (siehe Abbildung 5.4).

QS 1	QS-Initialisierung

QS 1.1	QS-Plan erstellen	⇒ QS-Plan

QS 1.2	Prüfplan erstellen

QS 2	Prüfungsvorbereitung

QS 2.1	Prüfmethoden und -kriterien festlegen

QS 2.2	Prüfumgebung definieren	⇒ Prüfplan

QS 2.3	Prüffälle festlegen	⇒ Prüfspezifikation

QS 2.4	Prüfprozedur erstellen	⇒ Prüfprozedur

QS 3	Prozeßprüfung von Aktivitäten	⇒ Prüfprotokoll

QS 4	Produktprüfung

QS 4.1	Prüfbarkeit feststellen

QS 4.2	Produkt inhaltlich prüfen	⇒ Prüfprotokoll

QS 5	QS-Berichtswesen	⇒ Berichtsdokumente

Anmerkung zur Übersicht:

In der obigen Übersicht wird ein Produkt als Ergebnis derjenigen (Teil-) Aktivität aufgeführt, die das betreffende Produkt fertigstellt.

Abbildung 5.4: Funktionsüberblick Submodell QS

Anmerkung zur Abbildung 5.4:

Welche SE-Produkte die jeweils relevanten Anforderungen enthalten, hängt davon ab, auf welcher Ebene man sich befindet.

−	System- und Segment-Ebene

−	Anwenderforderungen

−	Technische Anforderungen

−	Systemarchitektur

−	Schnittstellenbeschreibung

−	SW-/HW-Einheiten-Ebene

−	Anwenderforderungen

−	Technische Anforderungen

−	SW-Architektur

−	HW-Architektur

−	Schnittstellenbeschreibung

−	Komponenten-Ebene

−	Technische Anforderungen

−	Schnittstellenbeschreibung

−	SW-Entwurf (SW-Komponente)

−	HW-Architektur (HW-Komponente)

−	Modul/Datenbank-Ebene

−	Technische Anforderungen

−	Schnittstellenbeschreibung

−	SW-Entwurf (SW-Modul) bzw. SW-Entwurf (Datenbank) bzw. HW-Architektur (HW-Modul)


Konstruktive Maßnahmen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.1	Konstruktive Maßnahmen

Qualität kann nicht im nachhinein in ein Produkt hineingeprüft werden. Daher ist es unerläßlich, die Erzeugung von Qualität durch konstruktive Maßnahmen zu fördern. Zielsetzung ist außerdem, präventiv qualitätsrelevante Risiken zu vermeiden, Qualitätsmängeln entgegenzuwirken und die den analytischen Maßnahmen zu unterziehenden Prüfgegenstände überhaupt erst prüfbar zu gestalten.

Unter die konstruktiven/präventiven Maßnahmen fällt beispielsweise:

−	die Gliederung des Entwicklungsprozesses durch Anwendung eines SW-Entwicklungsstandards

−	die Unterstützung des Entwicklungsprozesses durch Methoden und Werkzeuge

Konstruktive/präventive Maßnahmen werden im Submodell QS festgelegt, die Anwendung der konstruktiven Maßnahmen erfolgt im Submodell SE. Abbildung 5.1 zeigt den Zusammenhang zwischen den Submodellen SE und QS bzgl. konstruktiver Maßnahmen.


Analytische Maßnahmen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.2	Analytische Maßnahmen

Analytische Maßnahmen haben die Prüfung, Bewertung und den (externen) Nachweis der Qualität der Prüfgegenstände zum Ziel. Sie werden im Submodell QS sowohl festgelegt als auch durchgeführt. Analytische Maßnahmen betreffen die Produkte und die Aktivitäten aller Submodelle. Abbildung 5.1 zeigt den Zusammenhang zwischen den Submodellen SE und QS bzgl. analytischer Maßnahmen.

Abbildung 5.1: Konstruktive und analytische Maßnahmen

Die im V-Modell anzuwendenden analytischen Maßnahmen lassen sich in eine Begriffshierarchie bringen (siehe Abbildung 5.2).

Hinweis:
Auch eine Evaluation (z. B. IT-Sicherheit) ist eine analytische Maßnahme. Diese wird jedoch von einer neutralen, dazu befugten und unabhängigen Organisation durchgeführt und ist nicht Bestandteil der Regelungen des V-Modells. Die Evaluation kann entweder nach Abschluß der Entwicklung oder als begleitende Evaluation durchgeführt werden.

Abbildung 5.2: Begriffshierarchie Prüfung


Rollenverteilung bei der Durchführung von Prüfaktivitäten
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.3	Rollenverteilung bei der Durchführung von Prüfaktivitäten

Bei den verschiedenen Prüfaktivitäten sind unterschiedliche Rollen  beteiligt (siehe Tabelle 5.1):

Prüfaktivität	Produktersteller	QS- Verantwortlicher 12)	Prüfer	AG/Anwender 13)
Selbstprüfung	v
Prozeßprüfung		v	m
Produktprüfung	b	m	v
Validierung		m	v	m
12)	Es ist darauf zu achten, daß hier eventuell eine Beteiligung des AG gemäß Projekthandbuch, Kapitel "Beteiligung des AG", erforderlich ist.

13)	Der AG kann sich über den Vertrag weitere Beteiligungen an QS-Aktivitäten sichern.

Legende:	v	verantwortlich
b	beratend
m	mitwirkend

Tabelle 5.1:	Beteiligung von Rollen bei den Prüfaktivitäten


Klassifizierung der QS-Aktivitäten
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.4	Klassifizierung der QS-Aktivitäten

Die Aktivitäten des Submodells QS lassen sich in

−	Planungsaktivitäten,

−	Prüfaktivitäten und

−	Lenkungsaktivitäten

einteilen.

In den Planungsaktivitäten (QS 1, QS 2) werden einerseits allgemeine, andererseits produktspezifische Qualitätssicherungsmaßnahmen festgelegt. Dadurch werden Nachweise und Lenkungsaktivitäten erst möglich.

Prüfaktivitäten (QS 3, QS 4) haben Nachweischarakter. Sie dienen zur Kontrolle von erstellten Produkten und durchgeführten Aktivitäten. Erst nach erfolgreicher Nachweisführung (Produkt geht in Zustand "akzeptiert" über) dürfen diese Produkte zur Entwicklung weiterer Produkte verwendet werden.

In den Lenkungsaktivitäten (QS 5) wird PM informiert, wenn sich Probleme abzeichnen. Auftauchende Fehler werden gesammelt, klassifiziert und analysiert. Bei massivem Auftauchen gleichartiger Probleme wird im Rahmen von QS der Ursache nachgegangen. Mögliche Korrekturmaßnahmen werden aufgezeigt. Die Ergebnisse der Prüfaktivitäten liefern die für die Lenkung notwendigen zuverlässigen Informationen.


Ausprägungen von Prüfaktivitäten
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.1	Überblick

5.1.5	Ausprägungen von Prüfaktivitäten

Um die möglichen Ausprägungen der Prüfaktivitäten darzustellen, ist eine genaue Abgrenzung zwischen (formellen) Prüfungen erforderlich, die der Nachweisführung nach außen dienen, und solchen, die intern zur Feststellung des Bearbeitungsendes erfolgen.

Die Prüfung am Bearbeitungsende ist eine Selbstprüfung  und wird im Submodell SE durchgeführt.

Welche Verpflichtungen die Entwickler hinsichtlich der Durchführung von Selbstprüfungen haben, ist festzulegen. Folgende Abstufung kommt hierfür beispielsweise in Betracht:

Art der Vorgaben für den Entwickler	Verpflichtungen seitens des Entwicklers
Keine Vorgaben (außer generell Nachvollziehbarkeit)	Dokumentation in freier Form
Statistische Vorgaben (z. B. Mindestabdeckung) zur Durchführung der Prüfung	Dokumentation muß den Vorgaben entsprechen
Genaue Spezifikation der Vorbereitung, Durchführung und Auswertung der Prüfung	Prüfprotokoll gemäß Submodell QS
Abbildung 5.3:	Mögliche Stufen der Abwicklung von Selbstprüfungen

Die Abwicklung der Selbstprüfung gemäß genauer Spezifikation unterscheidet sich von der (formellen) Prüfung allein dadurch, daß die Prüfaktivitäten vom Entwickler durchgeführt werden. (In diesem Fall müssen dem Entwickler von QS alle relevanten Prüfunterlagen, d. h. Prüfspezifikation und Prüfprozedur, zur Verfügung gestellt werden.) Eine Abwicklung der Selbstprüfung gemäß genauer Spezifikation macht die formelle Prüfung jedoch nicht überflüssig.

Die (formelle) Prüfung  wird nach den Regelungen des Submodells QS durchgeführt. Sie stellt eine auch für Außenstehende nachvollziehbare Nachweisführung  dar, daß das Prüfobjekt die gestellten Anforderungen erfüllt. Das Prüfobjekt rückt bei erfolgreicher Nachweisführung in den Zustand "akzeptiert" vor. Die Prüfung wird gemäß Prüfplan, Prüfspezifikation und Prüfprozedur durchgeführt.

Bezüglich der (formellen) Prüfung müssen verschiedene Arten der (organisatorischen) Durchführung unterschieden werden. Welche Art im konkreten Projekt zu wählen ist, hängt einerseits von der Projektsituation ab (z. B. Fachkompetenz und Kapazität des "QS-Verantwortlichen"), andererseits aber auch von den fachlichen Projektgegebenheiten (z. B. Isolierbarkeit der Prüfaktivitäten). Bei der folgenden Beschreibung ist als "QS-Verantwortlicher" stets eine Rolle  (gemäß Rollen-Definition) zu verstehen.

Die Beteiligung des QS-Verantwortlichen bei einer (formellen) Prüfung kann auf drei verschiedene Arten B1 bis B3 (Beteiligungsart) erfolgen:

B1	Der QS-Verantwortliche führt die formelle Prüfung selbst durch und entscheidet über Annahme ("akzeptiert") oder Ablehnung ("in Bearb.").

B2	Der QS-Verantwortliche begleitet die Durchführung der Prüfung und entscheidet über Annahme ("akzeptiert") oder Ablehnung ("in Bearb.") der Prüfung. Die Durchführung der Prüfung selbst erfolgt durch ein Mitglied des Entwicklungsteams.

B3	Der QS-Verantwortliche entscheidet allein aufgrund der Prüfdokumentation über Annahme ("akzeptiert") oder Ablehnung ("in Bearb.") der Prüfung. Die Durchführung der Prüfung selbst erfolgt durch ein Mitglied des Entwicklungsteams ohne sein Beisein.


QS 1: QS-Initialisierung
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 1	QS-Initialisierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1	in Bearb.		Projektplan		—	—
—	—		QS-Plan		QS 2−QS 4	akzeptiert
—	—		Prüfplan. Prüfgegenstände, Aufgaben/Verantwortlichkeiten, Zeitplan		QS 2	in Bearb.
Abwicklung

Die QS-Initialisierung ist die erste eigenständige QS-bezogene Aktivität eines Projektes (vgl. Mitwirkung bei PHB-Erstellung). Ihr Ziel ist die Festlegung des organisatorischen und abwicklungstechnischen Rahmens für QS. Die für das gesamte Projekt generell gültigen Festlegungen bezüglich der Prävention (Mittel zur Erreichung der Qualitätsziele, Vermeidung von Qualitätsrisiken) und der Nachweisführung (tatsächliche Erreichung der Qualitätsforderungen)  werden im QS-Plan niedergeschrieben. Hingegen werden in der Prüfplanung Festlegungen bezüglich der einzelnen Prüfgegenstände, Aufgaben und Verantwortlichkeiten und zum zeitlichen Verlauf der Prüfungen getroffen.


QS 1.1: QS-Plan erstellen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 1	QS-Initialisierung

QS 1.1	QS-Plan erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1	in Bearb.		Projektplan		—	—
—	—		QS-Plan		QS 1.2, QS 2-QS 4	akzeptiert
Abwicklung

Ausgehend von den QS-Regelungen im Projekthandbuch und Projektplan ist im QS-Plan festzulegen, welche Prüfgegenstände der QS unterzogen werden und wie die Ein- und Ausgangskontrolle von Produkten erfolgt. Bezüglich der Maßnahmen zur Einstufung der Kritikalität und Sicherheit ist auf das Projekthandbuch zu verweisen. Aus dem Projekthandbuch werden die vereinbarten Qualitätsziele und die erkannten Qualitätsrisiken übertragen. Die Qualitätsziele und -risiken werden auf der Basis der Projektkriterien und -randbedingungen gewichtet. Dabei werden die vom AG und AN gesetzten Prioritäten in Einklang gebracht und entsprechende Maßnahmen vereinbart.

Eine Abstimmung und Prüfung des QS-Plans zwischen dem "QS-Verantwortlichem" und der Projektleitung bezüglich der Vollständigkeit und Klarheit der Aufgaben sowie der Realisierbarkeit der Maßnahmen unter den gegebenen Projektbedingungen ist durchzuführen.

Bei erfolgreicher Prüfung wird für den QS-Plan der Zustand "akzeptiert" vergeben.

Erläuterung

Bei kleinen Projekten besteht die Möglichkeit, den QS-Plan integriert mit den PM-Planungsdokumenten Projektplan und Projekthandbuch zu führen.


QS 1.2: Prüfplan erstellen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 1	QS-Initialisierung

QS 1.2	Prüfplan erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1	in Bearb.		Projektplan		—	—
QS 1.1	akzeptiert		QS-Plan		—	—
—	—		Prüfplan. Prüfgegenstände, Aufgaben/Verantwortlichkeiten, Zeitplan		QS 2	in Bearb.
Abwicklung

Die Prüfplanung ist in Abstimmung mit der Projektleitung durchzuführen. Dabei sind die Festlegungen im QS-Plan zugrundezulegen.

Ferner sind zu bestimmen:

−	zu prüfende Produkte mit den jeweiligen Qualifikationserfordernissen der Prüfer,

−	zu prüfende Aktivitäten.

Die Prüfplanung ist zeitlich mit dem Projektfortschritt zu synchronisieren:

−	Unmittelbar nach Erarbeitung des QS-Plans erfolgt in der Regel die Festlegung der Prüfgegenstände sowie der Aufgaben und Verantwortlichkeiten für die System-Prüfung.

−	Zum Zeitpunkt der Identifikation eines Segments bzw. einer SW-Einheit/HW-Einheit im Entwicklungsprozeß erfolgt die Festlegung der Prüfgegenstände sowie der Aufgaben und Verantwortlichkeiten für die Prüfung der gerade identifizierten Einheit.

−	Parallel zur Planung der entsprechenden Entwicklungsarbeiten erfolgt die Festlegung des Zeitplans für die Prüfung auf System-, Segment- bzw. SW-/HW-Einheiten-Ebene.


QS 2: Prüfungsvorbereitung
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 2	Prüfungsvorbereitung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 2, SE 4-SW	in Bearb./ akzeptiert		Integrationsplan		—	—
QS 1	akzeptiert		QS-Plan		—	—
SE	akzeptiert		Produkte, die die Qualitätsforderungen enthalten		—	—
QS 1	in Bearb.		Prüfplan		QS 3, QS 4	akzeptiert
—	—		Prüfspezifikation		QS 3, QS 4	akzeptiert
—	—		Prüfprozedur		QS 4	akzeptiert
Abwicklung

Der Prüfplan wird zwischen dem "QS-Verantwortlichem" und der Projektleitung abgestimmt und dann gemeinsam akzeptiert.

Die für die Erstellung der Prüfspezifikation und Prüfprozedur relevanten Rahmenbedingungen sind im QS-Plan und im Prüfplan definiert.

Prüfspezifikation und Prüfprozedur werden im Rahmen dieser Aktivität vorgelegt und vom "QS-Verantwortlichen" nach entsprechender Kontrolle freigegeben. Die personelle Trennung von Ersteller und Freigebendem ist zu beachten.


QS 2.1: Prüfmethoden und -kriterien festlegen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 2	Prüfungsvorbereitung

QS 2.1	Prüfmethoden und -kriterien festlegen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
QS 1	akzeptiert		QS-Plan		—	—
SE	akzeptiert		Produkte, die die Qualitätsforderungen enthalten		—	—
QS 1	in Bearb.		Prüfplan		—	—
—	—		Prüfspezifikation. Anforderungen, Methoden, Prüfkriterien		QS 2.2, QS 2.3	in Bearb.
Abwicklung

* Anforderungen an die Prüfung erstellen

Für jeden im Prüfplan aufgeführten Prüfgegenstand sind die Anforderungen an die Prüfung zu erstellen. Wo relevant, ist der Bezug zwischen den Prüfanforderungen und den Anforderungsdokumenten darzustellen.

* Prüfmethoden festlegen

Für jeden im Prüfplan aufgeführten Prüfgegenstand sind die Prüfmethoden festzulegen. Für System, Segment, SW-Einheit/HW-Einheit, Komponente, SW-Modul und Datenbank ergibt sich die Prüfmethode aufgrund der Kritikalitäten/Methoden-Matrix, die im QS-Plan steht, und der für die jeweilige Funktionseinheit festgelegten Kritikalität.

* Prüfkriterien festlegen

Die Prüfkriterien müssen so festgelegt werden, daß eine Prüfung hinsichtlich ihrer erfolgreichen und ausreichenden Durchführung bewertbar ist.


QS 2.2: Prüfumgebung definieren
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 2	Prüfungsvorbereitung

QS 2.2	Prüfumgebung definieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 2, SE 4-SW	in Bearb./ akzeptiert		Integrationsplan		—	—
QS 2.1	in Bearb.		Prüfspezifikation		—	—
QS 1	in Bearb.		Prüfplan		—	—
—	—		Prüfplan. Ressourcen		QS 2.4, QS 4	akzeptiert
Abwicklung

Auf der Grundlage der Prüfanforderungen, -methoden  und -kriterien  hat die Definition der Prüfumgebung  und die Festlegung aller weiteren benötigten Ressourcen zu erfolgen. Existiert die erforderliche Prüfumgebung bereits, so sind deren SW- und HW-Bausteine mit ihrer jeweiligen Konfigurationskennung  eindeutig zu identifizieren, im anderen Falle sind die Anforderungen an die Prüfumgebung zu definieren.

Falls die Prüfumgebung gleich der Integrationsumgebung ist, sind die SW-Prüfungen mit den HW-Prüfungen abzustimmen.

Der Prüfplan wird zwischen dem "QS-Verantwortlichem" und der Projektleitung abgestimmt und dann gemeinsam akzeptiert.

Empfehlung

Für die Nachweisführung bei SW-Modulen, Datenbanken, Komponenten, SW-Einheiten/HW-Einheiten, Schnittstellen, Segmenten und Systemen sind die Anforderungen hierfür im einzelnen zu bestimmen.


QS 2.3: Prüffälle festlegen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 2	Prüfungsvorbereitung

QS 2.3	Prüffälle festlegen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE	akzeptiert		Produkte, die die Qualitätsforderungen enthalten		—	—
QS 2.1	in Bearb.		Prüfspezifikation		—	—
—	—		Prüfspezifikation. Prüffälle		QS 2.4, QS 4	akzeptiert
Abwicklung

Prüffälle  der einzelnen Prüfgegenstände sind auf der Basis der in der Prüfspezifikation definierten Methoden und der Prüfanforderungen derart auszuwählen, daß durch sie die Erfüllung der Qualitätsforderungen  ausreichend nachgewiesen werden kann.

Die Prüfspezifikation wird im Rahmen dieser Aktivität vorgelegt und vom "QS-Verantwortlichen" nach entsprechender Kontrolle freigegeben. Die personelle Trennung von Ersteller und Freigebendem ist zu beachten.

Empfehlung

Im Rahmen der Selbstprüfung sind in SE bereits Prüffälle ausgewählt worden. Diese können auch für die Nachweisprüfung wertvoll sein und sollten daher berücksichtigt werden. Soweit nötig, sind sie zu ergänzen oder zu modifizieren.


QS 2.4: Prüfprozedur erstellen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 2	Prüfungsvorbereitung

QS 2.4	Prüfprozedur erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
QS 2.2	akzeptiert		Prüfplan		—	—
QS 2.3	akzeptiert		Prüfspezifikation		—	—
SE	akzeptiert		Produkte, die die Qualitätsforderungen enthalten		—	—
—	—		Prüfprozedur		QS 4	akzeptiert
Abwicklung

Basierend auf der Definition der Prüffälle in der Prüfspezifikation sind genaue Arbeitsanleitungen für den Prüfer zu erstellen. In der Prüfprozedur sind Aktionen der Prüfvorbereitung und -nachbereitung sowie die einzelnen Prüfschritte gegebenenfalls mit den Interaktionen von Prüfer und Prüfanlage bei der Durchführung im Sinne eines "Drehbuchs" zu beschreiben.

Die Prüfprozedur wird im Rahmen dieser Aktivität vorgelegt und vom "QS-Verantwortlichen" nach entsprechender Kontrolle freigegeben. Die personelle Trennung von Ersteller und Freigebendem ist zu beachten.

Empfehlung

Soweit Prüffälle aus den Selbstprüfungsaktivitäten in SE übernommen werden, liegen dort auch bereits Prüfprozeduren bzw. wichtige Informationen der Entwickler dazu vor. Diese sollten berücksichtigt werden.


QS 3: Prozeßprüfung von Aktivitäten
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 3	Prozeßprüfung von Aktivitäten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
QS 1	akzeptiert		QS-Plan		—	—
QS 2	akzeptiert		Prüfplan		—	—
QS 2	akzeptiert		Prüfspezifikation		—	—
—	—		Prüfprotokoll		QS 5	—
Abwicklung

Bei der Prozeßprüfung wird festgestellt, ob vorgegebene Vorgehensweisen und Projektstandards bei der Durchführung bestimmter Aktivitäten eingehalten werden. Die Prüfung kann sich auf SE-, QS-, KM- und PM-Aktivitäten beziehen.

Erläuterung

Insbesondere bei den Aktivitäten KM 3 "Änderungsmanagement (Konfigurationssteuerung)" oder KM 4.4 "Ergebnisse sichern" sollten Prozeßprüfungen festgelegt werden, da hier Abweichungen von der definierten Vorgehensweise besonders kritische Folgen haben können.

Falls für QS-Aktivitäten selbst Prozeßprüfungen festgelegt werden, ist durch geeignete Rollenverteilung für ausreichend Unabhängigkeit zwischen Ausführenden der QS-Aktivitäten und den Prüfern zu sorgen.


QS 4: Produktprüfung
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 4	Produktprüfung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE, QS, KM, PM	akzeptiert		Zur Konsistenzprüfung erforderliche Vorgängerprodukte		—	—
SE, QS, KM, PM	vorgelegt		Prüfgegenstand		SE, QS, KM, PM	akzeptiert/ in Bearb.
QS 1	akzeptiert		QS-Plan		—	—
QS 2	akzeptiert		Prüfplan		—	—
QS 2	akzeptiert		Prüfspezifikation		—	—
QS 2	akzeptiert		Prüfprozedur		—	—
—	—		Prüfprotokoll		QS 5	—
Abwicklung

Führt die Aktivität QS 4.1 "Prüfbarkeit feststellen" für einen Prüfgegenstand zu einer negativen Entscheidung (Prüfbarkeit ist nicht gegeben), so geht der Prüfgegenstand nach SE, QS, KM bzw. PM zurück und muß überarbeitet werden.

Ergebnis der inhaltlichen Produktprüfung ist das Prüfprotokoll, aus dem unter anderem zu ersehen ist, ob das Produkt den Zustand "akzeptiert" oder "in Bearb." erhält.

Das Projektmanagement ist über das Prüfergebnis zu informieren.

Es ist darauf zu achten, daß der Prüfgegenstand nicht vom Prüfenden selbst erstellt wurde.


QS 4.1: Prüfbarkeit feststellen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 4	Produktprüfung

QS 4.1	Prüfbarkeit feststellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE, QS, KM, PM	akzeptiert		Zur Konsistenzprüfung erforderliche Vorgängerprodukte		—	—
SE, QS, KM, PM	vorgelegt		Prüfgegenstand		QS 4.2/ SE, QS, KM, PM	vorgelegt/ in Bearb.
QS 1	akzeptiert		QS-Plan		—	—
QS 2	akzeptiert		Prüfplan		—	—
QS 2	akzeptiert		Prüfspezifikation		—	—
—	—		Prüfprotokoll		QS 4.2	—
Abwicklung

Es ist zu untersuchen, ob die formalen Vorgaben eingehalten sind, um das Produkt inhaltlich prüfen zu können.

Das Produkt wird inspiziert und dabei folgende Checkliste (Standard-Prüfspezifikation für Prüfbarkeit) abgearbeitet:

−	Ist das Produkt gut verstehbar und übersichtlich gestaltet?

−	Sind alle Produkte, aus denen das zu prüfende Produkt hervorging, verfügbar?

−	Sind die Anforderungen, gegen die das Produkt geprüft werden soll, alle dokumentiert, klar und verständlich?

−	Wurden die anzuwendenden Richtlinien und Normen eingehalten?

Die Ergebnisse sind im Prüfprotokoll festzuhalten.


QS 4.2: Produkt inhaltlich prüfen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 4	Produktprüfung

QS 4.2	Produkt inhaltlich prüfen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE, QS, KM, PM	akzeptiert		Zur Konsistenzprüfung erforderliche Vorgängerprodukte		—	—
QS 4.1	vorgelegt		Prüfgegenstand		SE, QS, KM, PM	akzeptiert/ in Bearb.
QS 1	akzeptiert		QS-Plan		—	—
QS 2	akzeptiert		Prüfplan		—	—
QS 2	akzeptiert		Prüfspezifikation		—	—
QS 2	akzeptiert		Prüfprozedur		—	—
QS 4.1	—		Prüfprotokoll		QS 5	—
Abwicklung

Der Prüfgegenstand (d. h. das zu prüfende Produkt) ist entsprechend der zutreffenden Prüfspezifikation zu prüfen. Falls das Produkt System, Segment, SW-Einheit/HW-Einheit, SW-Komponente, SW-Modul oder Datenbank ist, ist die zutreffende Prüfprozedur einzuhalten.

Während der inhaltlichen Prüfung ist das Prüfprotokoll zu erstellen. Darin ist für jeden Prüffall das erzielte Ergebnis (insbesondere auch bei Fehlern) nachvollziehbar zu dokumentieren und eine zusammenfassende Beurteilung abzugeben.

Bei erfolgreich bestandener Prüfung wird ein Zustandswechsel für das geprüfte Produkt von "vorgelegt" nach "akzeptiert" veranlaßt, sonst von "vorgelegt" zurück nach "in Bearb.".


QS 5: QS-Berichtswesen
Teil 1	Vorgehensmodell / Regelungsteil

5	Regelungen Submodell Qualitätssicherung

5.2	Die Aktivitäten des Submodells QS

QS 5	QS-Berichtswesen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
QS 3, QS 4	—		Prüfprotokolle		—	—
—	—		Berichtsdokumente		KM 4, PM 9	—
Abwicklung

Im Rahmen des QS-Berichtswesens sind die Prüfprotokolle nach folgenden Kriterien auszuwerten:

−	Anzahl der Probleme,

−	Schwere der Probleme,

−	Klassifikation der Probleme (tauchen gleichartige Probleme öfters auf?),

−	Ursache der Probleme.

Die QS im Projekt ist häufig eingebettet in ein QM-System, das der AN für sein Unternehmen betreibt. Um dem Anspruch der stetigen Verbesserung (DIN ISO 9000 ff.) gerecht zu werden, müssen Erfahrungen über Projektgrenzen hinweg bewahrt und ausgewertet werden. Insbesondere die Erfahrungen mit QS-Maßnahmen sind zusammenzufassen. Dazu eignet sich der Projektabschlußbericht (Aktivität PM 14 "Projektabschluß").

Erläuterung

Mögliche Ursachen von Fehlern können sein:

−	nicht ausreichende Personalkapazität oder Qualifikation,

−	unhandliches Werkzeug,

−	Engpaß beim Zugang zum Entwicklungsrechner.

Im Submodell PM werden Berichtsdokumente für mögliche Korrekturmaßnahmen und für eine Projekthistorie verwendet.


Überblick
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.1	Überblick

Das Ziel des Konfigurationsmanagements (KM) besteht darin sicherzustellen, daß ein Produkt bezüglich seiner funktionellen wie auch äußeren Merkmale − wie z. B. bei Dokumenten − jederzeit eindeutig identifizierbar ist. Diese Identifikation dient der systematischen Kontrolle von Änderungen und zur Sicherstellung der Integrität, auch während der Nutzung.

Das KM überwacht die Konfigurationen, so daß die Zusammenhänge und Unterschiede zwischen früheren Konfigurationen und den aktuellen Konfigurationen jederzeit erkennbar sind. KM stellt sicher, daß jederzeit auf vorausgegangene Versionen  zurückgegriffen werden kann. Dadurch sind Änderungen nachvollziehbar und überprüfbar.

Die Aktivität KM 1 "KM-Planung" legt die für das Projekt geltenden Richtlinien und Verfahren verbindlich fest und schafft die Voraussetzungen für ein zuverlässiges Konfigurationsmanagement. Die Aktivität KM 2 "Produkt- und Konfigurationsverwaltung" stellt sicher, daß Produkte und Konfigurationen eindeutig identifiziert, zugriffsgesichert und rekonstruierbar gespeichert sind. Die Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)" begleitet den gesamten Änderungsprozeß vom Änderungsantrag über alle Entscheidungen bis zum Änderungsabschluß und der Rückmeldung. Die KM-Dienste (Aktivität KM 4) werden in bestimmten Intervallen oder nach Bedarf durchgeführt. Hierzu zählen die Ergebnissicherung und die KM-Dokumentation sowie die KM-Dienstleistungen zur zentralen und projektübergreifenden Datenadministration und Produktwiederverwendung sowie die Schnittstellenkoordination und das Releasemanagement.

Die nachfolgend beschriebenen Aktivitäten gelten sowohl für den Entwicklungsprozeß als auch für die Nutzung des Systems.

Bei der Behandlung von Produkten im V-Modell ist zu berücksichtigen, daß Produkte im Entwicklungsprozeß verschiedene Reifegrade, d. h. Zustände  durchlaufen. Die für ein Produkt mindestens geforderten Zustände sind in Abschnitt 2.3.2 definiert.

Der Wechsel von einem Zustand in einen anderen wird grundsätzlich durch eine Aktivität ausgelöst. Die Zustandsübergänge sind bei den entsprechenden Aktivitäten angegeben. Mit dem Übergang von einem Zustand zum anderen ist in der Regel ein Wechsel an Zugriffsrechten verbunden. Die Verantwortlichkeit für den Zustandswechsel muß eindeutig definiert sein. Abbildung 6.1 zeigt die mindestens geforderten Zustandsübergänge sowie die den Zustandswechsel auslösende Aktivität für zu entwickelnde Produkte. Im Falle von Fertigprodukten geht der Zustand "in Bearb." in den Zustand "geplant" auf.

Abbildung 6.1: Zulässige Zustandsübergänge von zu entwickelnden Produkten

Im Vorgriff auf die Inhalte des Abschnitts 6.2 Die Aktivitäten des Submodells KM folgt eine zusammenfassende Übersicht über alle Aktivitäten und Produkte des Submodells KM sowie ein Funktionsüberblick zum Submodell KM (siehe Abbildung 6.3).

KM 1	KM-Planung

KM 1.1	KM-Plan erstellen	⇒ KM-Plan

KM 1.2	KM einrichten

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.1	Produkt initialisieren

KM 2.2	Konfiguration initialisieren

KM 2.3	Produkt verwalten

KM 2.4	Konfiguration fortschreiben	⇒ KID

KM 2.5	Zugriffsrechte verwalten

KM 3	Änderungsmanagement (Konfigurationssteuerung)

KM 3.1	Änderung bewerten	⇒ Änderungsvorschlag

KM 3.2	Änderungsvorgehen entscheiden und
Änderung einleiten	⇒ Änderungsauftrag

KM 3.3	Änderung abschließen	⇒ Änderungsmitteilung
⇒ Änderungsstatusliste

KM 4	KM-Dienste

KM 4.1	Daten administrieren	⇒ Datenkatalog

KM 4.2	SW-/HW-Produkte katalogisieren

KM 4.3	Schnittstellen koordinieren

KM 4.4	Ergebnisse sichern

KM 4.5	KM-Dokumentation führen

KM 4.6	Release-Management durchführen

KM 4.7	Projekthistorie führen	⇒ Projekthistorie

Anmerkung zur Übersicht:

In der obigen Übersicht wird ein Produkt als Ergebnis derjenigen (Teil-) Aktivität aufgeführt, die das betreffende Produkt fertigstellt.

Abbildung 6.3: Funktionsüberblick Submodell KM


KM 1: KM-Planung
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 1	KM-Planung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1	in Bearb.		Projektplan		—	—
—	—		KM-Plan		KM 2-KM 4	vorgelegt
Weitere Ergebnisse:

•	Produktbibliothek

•	Werkzeuge

Abwicklung

Die KM-Planung ist die erste KM-bezogene Aktivität. Ihr Ziel ist die Festlegung des organisatorischen Rahmens durch den KM-Plan. Des weiteren sind die Einsatzmittel in Form der Produktbibliothek und der zugehörigen Werkzeuge bereitzustellen.

Erläuterung

In der Produktbibliothek  werden alle Produkte − soweit sinnvoll und möglich − zusammengefaßt und geführt. Unter Produkten, welche durch das KM verwaltet werden, werden Dokumente, SW- und HW-Bausteine verstanden.

Die Produktbibliothek ist ein Instrumentarium der SEU für das gesamte Projekt zur Verwaltung von DV-technisch gespeicherten Informationen. Über die im KM-Plan festgeschriebene Kennzeichnungssystematik erfolgt die Identifikation und Referenzierung aller Produkte. Im Gegensatz zur zugehörigen DV-technisch gespeicherten Dokumentation erfolgt die physikalische Aufbewahrung der HW-Bausteine typischerweise außerhalb der Produktbibliothek der SEU. Das V-Modell enthält deshalb keine Regelungen zur physikalischen Verwaltung der HW-Bausteine.


KM 1.1: KM-Plan erstellen
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 1	KM-Planung

KM 1.1	KM-Plan erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1	in Bearb.		Projektplan		—	—
—	—		KM-Plan		KM 1.2, KM 2, KM 3, KM 4.4	vorgelegt
Abwicklung

Im Rahmen der KM-Planung sind die Ausführungen im Projekthandbuch und Projektplan in den Punkten "Einführung des Konfigurationsmanagements", "Änderungsmanagement", "Ergebnissicherung" und "Archivierung" zu ergänzen.

Bei der Einführungsstrategie des KM ist u. a. festzulegen

−	anhand welcher Kriterien die Konfigurationseinheiten ausgewählt werden,

−	welche Produktattribute geführt werden,

−	welche Zustände die Produkte durchlaufen und

−	das für alle Produkte des Projekts geltende Identifikationsschema.

Abweichungen von den Festlegungen des V-Modells bzgl. der Produktzustände  sind nur insoweit gestattet, als eine Abbildung der Zustände und Zustandsübergänge gemäß V-Modell auf die projektspezifischen Regelungen möglich sein muß. Dies hat zur Folge, daß Zustände nur verfeinert, nicht aber zusammengefaßt oder gar gestrichen werden dürfen.

Erläuterung

Bei kleinen Projekten besteht die Möglichkeit, den KM-Plan gemeinsam mit den PM-Planungsdokumenten Projektplan und Projekthandbuch zu führen.


KM 1.2: KM einrichten
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 1	KM-Planung

KM 1.2	KM einrichten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
KM 1.1	akzeptiert		KM-Plan		—	—
Weitere Ergebnisse:

•	Produktbibliothek

•	Installierte Werkzeuge

Abwicklung

Ausgehend von KM-Regelungen im Projekthandbuch und dem KM-Plan ist das KM einzurichten.

Wesentliche Schritte hierbei sind beispielsweise:

−	Initialisierung der Produktbibliothek und der zugehörigen Werkzeuge,

−	Eintragung der Nutzer der Produktbibliothek mit Zugriffsberechtigung,

−	bei Neuentwicklungen: Anfrage über die zentralen KM-Dienste nach wiederverwendbaren Produkten, Übernahme der ausgewählten Kandidaten in die Produktbibliothek und Übernahme verbindlicher Datendefinitionen aus einem zentralen Datenkatalog,

−	bei SWPÄ: Bereitstellung des Ausgangszustandes aller Produkte für die Pflege und Änderung (Baseline).

Beim Einrichten des KM sind die IT-Sicherheitsziele  und -Maßnahmen aus dem Sicherheitskonzept zu berücksichtigen (Zugriffsrechte, Kontrollmechanismen, usw.).

Bei der Aufbewahrung der Dokumente während des Projekts sind die gültigen IT-sicherheitsrelevanten Regelungen zu beachten.


KM 2: Produkt- und Konfigurationsverwaltung
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
SE, QS, KM, PM 4	*)		Produkt		—	—
—	—		Konfigurations-Identifikations- dokument		KM 4	vorgelegt
*)	alle Zustände möglich

Abwicklung

Durch die Produkt- und Konfigurationsverwaltung werden alle Produkte einer Konfiguration  in der Produktbibliothek archiviert und katalogisiert, so daß die Produkte weder absichtlich noch unabsichtlich zerstört werden können.

Alle Produkte sind jederzeit eindeutig identifizierbar. Dadurch wird sowohl während des Entwicklungsprozesses als auch während der Nutzung ein Nachvollziehen des Änderungsgeschehens sichergestellt und somit ein definierter Aufsetzpunkt für weitere Änderungen gegeben.


KM 2.1: Produkt initialisieren
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.1	Produkt initialisieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
PM 4	geplant		Produkt		KM 2.2/KM 2.4	geplant
Weitere Ergebnisse:

•	Initialisierte Produktattribute

Abwicklung

Das Produkt wird dem Namen nach erfaßt, und die durch den KM-Plan festgelegten Produktattribute werden in der Produktbibliothek  eingetragen. Ist das Produkt ein System, eine SW-Einheit oder eine HW-Einheit, so ist nachfolgend in KM 2.2 "Konfiguration initialisieren" das entsprechende KID zu initialisieren. Andernfalls ist in KM 2.4 "Konfiguration fortschreiben" das bereits existierende KID fortzuschreiben.

Handelt es sich bei dem geplanten Produkt um ein Fertigprodukt, welches extern entwickelt bzw. beschafft wird, gelten die Regelungen zur Produktinitialisierung und -verwaltung analog.


KM 2.2: Konfiguration initialisieren
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.2	Konfiguration initialisieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 2.1	geplant		Produkt		—	—
—	—		Konfigurations-Identifikations- dokument		KM 2.4	in Bearb.
Abwicklung

Es wird ein Konfigurations-Identifikationsdokument (KID) angelegt; dies ist abhängig vom geplanten Produkt ein System-KID, ein HW-KID bzw. ein SW-KID. Diese Aktivität wird einmal je KID durchgeführt.

Die Angaben zur Identifikation und Einordnung in das System werden erfaßt (Initialisierung des KID), und alle zu diesem Zeitpunkt bereits bekannten Informationen über Bausteine und Dokumente der Konfiguration sind einzutragen.

Zu den Angaben der Identifikation zählen auch Konfigurationsattribute, Informationen über den Konfigurationsstand der eingesetzten SEU, wie z. B. Version des verwendeten Compilers, und Angaben über eingesetzte Fertigprodukte.

Erläuterung

In Anlehnung an die Architekturdokumente (System-, HW- und SW-Architektur) sind ebenfalls auf diesen beiden Ebenen ("System" und "Software" bzw. "Hardware") getrennte KID vorgeschrieben. Projektspezifische Besonderheiten, wie z. B. Auslieferung von einzelnen oder konfigurierten Software- oder Hardware-Komponenten als eine Liefereinheit, können weitere KID-Stufen erfordern, weil einer Liefereinheit immer auch ein eigenes KID zuzuordnen ist. Nach diesen Projektentscheidungen richtet sich die Definition und Anzahl der KID im Projekt und damit auch die Interpretation einer "Konfigurationseinheit", d. h. es liegt in der Verantwortung des Konfigurationsmanagements, gegebenenfalls weitere KID zu halten und damit weitere Konfigurationseinheiten zu definieren.


KM 2.3: Produkt verwalten
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.3	Produkt verwalten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE, QS, KM, PM	*)		Produkt		KM 2.4	*)
*)	Das Produkt kann im Zustand "in Bearb.", "vorgelegt" oder "akzeptiert" sein oder keinen Zustand besitzen

Abwicklung

KM verwaltet das Produkt abhängig vom Zustand.

−	Ist das Produkt im Zustand "in Bearb.", "vorgelegt" oder "akzeptiert", erfaßt KM das bereits initialisierte Produkt und schreibt die Produktattribute fort.

−	Besitzt das Produkt keinen Zustand (Protokolle, usw.), so ist das Produkt aufzunehmen, und die Produktattribute sind einzutragen.

Über die Produktverwaltung ist sicherzustellen, daß ein Rückverfolgen der Zustandsänderungen und ein Rücksetzen auf frühere Versionen des Produkts möglich ist. Die Produktverwaltung begleitet den gesamten Lebenszyklus eines Produkts, beginnend mit der Planung des betreffenden Produktes über alle Zustände aller existierender Versionen bis zum Projektende.

Wiederverwendbare Produkte (z. B. Prozeduren, Programme, Spezifikationen, usw.) sind gegebenenfalls darüber hinaus an die zentralen KM-Dienste zu übergeben und über KM 4.2 "SW-/HW-Produkte katalogisieren" zu verwalten.

Erläuterung

Ein Produkt "verwalten" bedeutet: ein Produkt wird physikalisch in der Produktbibliothek  in Verwahrung genommen, es steht damit unter dem "Schutz" des KM. Hierzu gehört auch die Archivierung. Im Falle von HW-Produkten erfolgt die Initialisierung und Verwaltung mit denselben Verfahren (Produktidentifikation, -attribute, usw.) wie auch bei SW-Produkten, lediglich die physikalische Aufbewahrung erfolgt außerhalb der Produktbibliothek, wobei von dort aus der Aufbewahrungsort zu referenzieren ist.


KM 2.4: Konfiguration fortschreiben
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.4	Konfiguration fortschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 2.1 oder KM 2.3	*)		Produkt		—	—
KM 2.2	in Bearb.		Konfigurations-Identifikations- dokument		KM 4.3, KM 4.5, KM 4.6	in Bearb.**)/ vorgelegt
*)	alle Zustände möglich.

**)	"vorgelegt", wenn das zugehörige Produkt den Zustand "vorgelegt" erreicht hat.

Abwicklung

Das in Aktivität KM 2.2 "Konfiguration initialisieren" initialisierte KID wird um das neue Produkt fortgeschrieben/ergänzt. Dabei wird innerhalb des betreffenden KID (System-KID, HW-KID oder SW-KID) zwischen den Produkten "Dokumente" (alle Entwicklungsdokumente) und "Bausteine" (alle Einheiten vom SW-Modul/HW-Modul bis zum System) unterschieden.

Über das KID ist sicherzustellen, daß eine Konfigurationseinheit jederzeit aus ihren Bausteinen konfiguriert bzw. rekonfiguriert werden kann. Hierzu sind neben der vollständigen Auflistung aller einer Konfigurationseinheit zugehörigen Bausteine Prozeduren zu halten und zu führen, welche die erforderlichen Konfigurationsschritte automatisieren. Alle zwischen den einzelnen Produkten bestehenden Beziehungen und Abhängigkeiten müssen aus dem KID ersichtlich sein. Ferner ist die Möglichkeit oder Notwendigkeit verschiedener Konfigurationsvarianten entsprechend zu berücksichtigen.

Das KID bleibt so lange im Zustand "in Bearb.", bis die zugehörige Konfigurationseinheit (System, SW-Einheit, HW-Einheit) 14) den Zustand "vorgelegt" erlangt. Erst dann erhält das zugehörige KID ebenfalls den Zustand "vorgelegt".

14)	oder nach Projektdefinition

Ist ein Konfigurations-Identifikationsdokument im Zustand "vorgelegt"/"akzeptiert", so zieht die Änderung eines Produktes dieser Konfiguration  eine Änderung der Versionsbezeichnung  der Konfiguration nach sich.


KM 2.5: Zugriffsrechte verwalten
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 2	Produkt- und Konfigurationsverwaltung

KM 2.5	Zugriffsrechte verwalten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
Weitere Ergebnisse:

•	Zugriffsrechte auf Produktbibliothek

Abwicklung

Die Zugriffsrechte der Projektbeteiligten auf Produkte (in der Produktbibliothek) sind entsprechend den Regelungen im KM-Plan zu vergeben und nach Abschluß der Bearbeitung (falls erforderlich) zurückzunehmen.


KM 3: Änderungsmanagement (Konfigurationssteuerung)
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 3	Änderungsmanagement (Konfigurationssteuerung)

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
Extern *)	—		Änderungsantrag/Problemmeldung		—	—
Extern **)	—		Berichtsdokumente/ Projektabschlußbericht		—	—
—	—		Änderungsstatusliste		KM 4	—
—	—		Änderungsauftrag		An betroffenes Submodell	—
—	—		Änderungsmitteilung		KM 4, extern *)	—
—	—		Protokoll		KM 4, extern *)	—
*)	Projektmitglied, AG, Anwender

**)	Es sind diejenigen Berichtsdokumente/Projektabschlußberichte zu berücksichtigen, die bei der Durchführung der Änderung gemäß V-Modell entstanden sind.

Abwicklung

Im Änderungsmanagement werden folgende Tätigkeiten zusammengefaßt:

−	Erfassung und Verwaltung eingehender Fehlermeldungen, Problemmeldungen und Verbesserungsvorschläge in Form von Änderungsanträgen/Problemmeldungen.

−	Entscheidung über die Bearbeitung von Änderungsanträgen/Problemmeldungen (Ablehnung/Annahme; Auswahl eines Lösungsvorschlags) unter Berücksichtigung der eventuellen technischen und terminlichen Auswirkungen auf den Projektverlauf und Veranlassung der Bearbeitung.

−	Abschluß der Änderung und Information aller Betroffenen.

Eine Änderung hat abhängig vom Entwicklungsfortschritt und von getroffenen Entscheidungen einen bestimmten Status:

Abbildung 6.2: Status einer Änderung

Es handelt sich hierbei um die typischen Änderungsstatus. Aufgrund der projektspezifischen Situation und dem eingeführten Änderungsformalismus können auch abweichende Festlegungen getroffen werden.

Im Änderungsmanagement sind SE-, QS-, KM- und PM-Rollen  beteiligt. Welche der Rollen im Einzelfall zum Tragen kommt, hängt von dem/den zu ändernden Produkt/Produkten ab.

Der Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)"  werden nur Produkte unterzogen, die bereits den Zustand "akzeptiert" hatten. Diese Produkte können auch Bestandteil einer Baseline sein.

Empfehlung

Bei der Festlegung des Änderungsablaufs sollte unterschieden werden, ob ein Produkt bereits an den AG ausgeliefert wurde oder nicht. Vor der Produktauslieferung kann eine verkürzte Änderungsprozedur durchgeführt werden.

Erläuterung

Eine Änderung kann Bearbeitungsergebnisse unterschiedlicher Submodelle betreffen, z. B.

−	Anforderungsdokumente, Entwürfe, Implementierungsdokumente, usw. (Submodell SE)

−	Projekthandbuch, Projektplan, usw. (Submodell PM)

−	Prüfspezifikation, Prüfplan, usw. (Submodell QS)

−	Konfigurations-Identifikationsdokument (Submodell KM)


KM 3.1: Änderung bewerten
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 3	Änderungsmanagement (Konfigurationssteuerung)

KM 3.1	Änderung bewerten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
Extern **)	—		Änderungsantrag/Problemmeldung		—	—
—	—		Änderungsvorschlag		KM 3.2	—
—	—		Protokoll		KM 4.5, extern *)	—
—	—		Änderungsstatusliste		KM 3.2, KM 3.3, KM 4.5	—
*)	Projektmitglied, AG, Anwender

Abwicklung

Ein eingehender Änderungsantrag/Problemmeldung ist zu bewerten, und es ist gegebenenfalls ein Änderungsvorschlag zu erarbeiten.

Bei der Bewertung der Änderung sind folgende Rollen beteiligt:

−	KM-Rollen: Änderungsantrag/Problemmeldung formell prüfen und verwaltungsmäßig in der Änderungsstatusliste erfassen (Status "beantragt")

−	PM-Rollen: entscheiden, ob Änderungsantrag/Problemmeldung weiter verfolgt werden soll, und gegebenenfalls hinsichtlich Dringlichkeit (Prioritätenvergabe) bewerten

−	KM-Rollen: Änderungsstatusliste aktualisieren (Status "abgelehnt" oder "beabsichtigt" je nach PM-Entscheidung)

Die für die Erstellung des Änderungsvorschlags zuständige Rolle hängt davon ab, welche(s) Produkt(e) zu ändern ist (sind):

SE-Produkte 	SE-Rollen

PM-Produkte	PM-Rollen

QS-Produkte	QS-Rollen

KM-Produkte	KM-Rollen

Alle Untersuchungen, die im Rahmen der Erstellung des Änderungsvorschlags durchgeführt werden, liegen außerhalb des Submodells KM.

Empfehlung

Falls der Änderungsantrag/Problemmeldung einen Fehler anzeigt, wird gegebenenfalls eine Analyse in den unterschiedlichen Prüfumgebungen erfolgen. Beginnend in der System-Prüfumgebung  wird in entgegengesetzter Richtung zur Integration vorgegangen, um so die betroffenen Stellen immer weiter eingrenzen zu können. Voraussetzung für eine aussagekräftige Analyse ist ein Änderungsantrag/Problemmeldung mit exakten Angaben.

Erläuterung

Der Änderungsvorschlag stellt die technischen Lösungen aus Sicht des bearbeitenden Submodells dar.


KM 3.2: Änderungsvorgehen entscheiden und Änderung einleiten
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 3	Änderungsmanagement (Konfigurationssteuerung)

KM 3.2	Änderungsvorgehen entscheiden und Änderung einleiten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 1	akzeptiert		KM-Plan		—	—
Extern *)	—		Änderungsantrag/Problemmeldung		—	—
KM 3.1	—		Änderungsvorschlag		—	—
—	—		Änderungsauftrag **)		KM 3.3, an betroffenes Submodell	—
—	—		Protokoll		KM 4.5, extern *)	—
KM 3.1	—		Änderungsstatusliste		KM 3.3, KM 4.5	—
*)	Projektmitglied, AG, Anwender

**)	bei positiver Entscheidung

Abwicklung

Es ist über das Vorgehen bei der Änderung zu entscheiden, und die entsprechenden Maßnahmen sind einzuleiten.

Bei der Entscheidung über das Änderungsvorgehen und bei der Einleitung der Änderung sind folgende Rollen beteiligt:

−	KM-Rollen: Änderungsvorschlag entgegennehmen und formell prüfen

−	PM-Rollen: Lösungen aus dem Änderungsvorschlag hinsichtlich Auswirkung, Durchführbarkeit und Terminauswirkungen bewerten.
Wird keine der vorgeschlagenen Lösungen akzeptiert, so ist dies entsprechend zu protokollieren; andernfalls wird ein Lösungsvorschlag ausgewählt, auf dessen Basis ein Änderungsauftrag erstellt wird. Diese Aktivität ist mit der PM-Aktivität PM 4 "Feinplanung" und PM 7 "Risikomanagement" abzustimmen.

Entsprechend den vertraglichen Regelungen ist gegebenenfalls der AG einzuschalten.

−	KM-Rolle: Änderungsstatusliste aktualisieren (Status "abgelehnt" oder "beauftragt").

−	PM-Rolle: Veranlassen der für die Durchführung der Änderung erforderlichen Arbeiten;
gegebenenfalls Initiierung eines separaten SWPÄ-Projekts; Veranlassen eines Zustandswechsels für das Produkt von "akzeptiert" nach "in Bearb.".

Bei der Durchführung der Änderung ist nach den Regelungen des V-Modells vorzugehen.


KM 3.3: Änderung abschließen
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 3	Änderungsmanagement (Konfigurationssteuerung)

KM 3.3	Änderung abschließen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern **)	—		Berichtsdokumente/ Projektabschlußbericht		—	—
KM 3.2	—		Änderungsauftrag		—	—
—	—		Änderungsmitteilung		KM 4.5, extern *)	—
KM 3.2	—		Änderungsstatusliste		KM 4.5	—
*)	Projektmitglied, AG, Anwender

**)	Es sind diejenigen Berichtsdokumente/Projektabschlußberichte zu berücksichtigen, die bei der Durchführung der Änderung gemäß V-Modell entstanden sind.

Abwicklung

Das Abschließen einer Änderung beinhaltet die folgenden Arbeitsschritte:

−	korrekten Abschluß der Änderungsaktivitäten feststellen,

−	Änderungsstatusliste aktualisieren (Status "erledigt"),

−	Information aller Betroffenen.


KM 4: KM-Dienste
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

Produktfluß

− Entfällt −

(Die einzelnen KM-Dienste stehen in keinem inhaltlichen oder zeitlichen Zusammenhang.)

Abwicklung

Unter den KM-Diensten sind all diejenigen Aktivitäten des KM angesiedelt, die als Projektdienstleistungen in Intervallen, nach Bedarf bzw. auf Veranlassung durchzuführen sind.

Hierzu gehören die Aktivitäten

−	KM 4.1 "Daten administrieren" mit dem Ziel eines zentralen bzw. unternehmensweiten Datenkatalogs und konsistenter, vereinheitlichter Datendefinitionen,

−	KM 4.2 "SW-/HW-Produkte katalogisieren" mit dem Ziel, die Wiederverwendbarkeit der Produkte zu ermöglichen,

−	KM 4.3 "Schnittstellen koordinieren" mit dem Ziel, die Schnittstellen kompatibel zu halten und einseitig geänderte technische Schnittstellen zu verhindern,

−	KM 4.4 "Ergebnisse sichern" mit dem Ziel der Wahrung des erreichten Projektstands,

−	KM 4.5 "KM-Dokumentation führen" zur Erstellung von Detailunterlagen und Übersichten verschiedenster KM-Belange,

−	KM 4.6 "Release-Management durchführen" zur kontrollierten Konfigurationsfreigabe und -verteilung,

−	KM 4.7 "Projekthistorie führen" mit dem Ziel einer umfassenden, nachvollziehbaren Dokumentation über den gesamten Projektverlauf.


KM 4.1: Daten administrieren
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.1	Daten administrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Projektübergreifender Datenkatalog		Extern	—
SE 5.1-SW *)	in Bearb.		Datenkatalog		SE 5.1-SW	in Bearb.
*)	falls der Datenkatalog bereits initialisiert ist

Abwicklung

Eine projektübergreifende Datenadministration (falls vorhanden) führt Datendefinitionen, auch aus früher abgewickelten Projekten, in einem projektübergreifenden Datenkatalog. Jedes relevante Projekt, das Datendefinitionen ändern oder hinzufügen will, muß sich seine eigenen Datendefinitionen von der projektübergreifenden Datenadministration genehmigen lassen. Dabei ist es im allgemeinen die Aufgabe des Projekts, einen genehmigungsfähigen Vorschlag zu erarbeiten.

Zu Beginn eines Projekts wird der (projektspezifische) Datenkatalog initialisiert. Dazu werden aus dem projektübergreifenden Datenkatalog, falls vorhanden, relevante Einträge in den Datenkatalog übernommen. Im Projektablauf wird begleitend zu Aktivität SE 5.1-SW (evtl. auch iterativ) die Integration der in einer SW-Einheit benutzten Daten mit dem projektübergreifenden Datenkatalog durchgeführt. Es ist darauf zu achten, welche Daten in welcher Form bereits erfaßt sind, welche Namen vergeben sind, welche Richtlinien einzuhalten sind, usw.


KM 4.2: SW-/HW-Produkte katalogisieren
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.2	SW-/HW-Produkte katalogisieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Zentraler Produktkatalog		Extern	—
SE, QS, KM, PM	akzeptiert		Produkt *)		—	—
—	—		Produkt(e) **)		SE, QS, KM, PM	in Bearb.
*)	Entweder: es wird ein Produkt in den zentralen Produktkatalog aufgenommen.

**)	Oder: es werden Produkte aus dem zentralen Produktkatalog zur Wiederverwendung im Projekt zur Verfügung gestellt.

Abwicklung

Die Aktivität KM 4.2 "SW-/HW-Produkte katalogisieren" nimmt im Projekt neu entstandene Produkte anhand von Kritierien und Kennzeichen, die eine spätere Wiederverwendung ermöglichen, in einem zentralen Produktkatalog auf. Die Produkte sind so zu katalogisieren, daß der Katalog nach verschiedenen Produktanforderungen ausgewertet werden kann.

Ferner hat die Aktivität auf Anfragen zu reagieren, um einem Projekt mögliche Produktkandidaten zur Wiederverwendung zur Verfügung zu stellen. Die Anfragen können auf die verschiedenen Konstellationen der Produktcharakteristika abzielen, wie z. B Funktionsumfang, Qualitätskriterien, Programmiersprache, Schnittstellenanbindung, Realisierungstechnik.

Erläuterung

Eine Wiederverwendung ist nicht auf SE-Produkte beschränkt, auch andere Produkte oder Auszüge daraus eignen sich (beispielsweise eine Liste von Prüfkriterien, Layoutdefinitionen für ein einheitliches Dokumentenbild, usw.).


KM 4.3: Schnittstellen koordinieren
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.3	Schnittstellen koordinieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 2	in Bearb./ akzeptiert		Konfigurations-Identifikations- dokument		—	—
SE 2, SE 4-SW, extern *)	in Bearb./ vorgelegt		Schnittstellenübersicht		—	—
SE 2, SE 4-SW, extern *)	in Bearb./ vorgelegt		Schnittstellenbeschreibung		—	—
—	—		Berichtsdokumente		Projektbeteiligte	—
*)	sofern Änderung durch externe Stellen (andere AN bzw. UAN) durchgeführt wurde bzw. externe Stellen von der Änderung betroffen sind

Abwicklung

Über die Aktivität KM 4.3 "Schnittstellen koordinieren" ist die Kompatibilität aller technischen Schnittstellen sicherzustellen. Änderungen an der existierenden Schnittstellenstruktur oder an bestehenden Schnittstellenbeschreibungen sind dem KM von der ändernden Stelle zu melden. KM hat die Aufgabe, die Schnittstellenänderung zu kontrollieren und zu koordinieren, d. h. alle betroffenen Produkte sind zu ermitteln, und die verantwortlichen Bearbeiter sind entsprechend zu informieren und mit der geänderten Schnittstellenbeschreibung zu versorgen.

Im Falle von schwerwiegenden oder nicht abgestimmten Änderungen sind Besprechungen mit den beteiligten Entwicklern oder (speziell für größere Projekte) Arbeitsgruppensitzungen zur Klärung des Sachverhalts und zur gegenseitigen Abstimmung einzuberufen.

Die eigentliche Bearbeitung der Schnittstellen erfolgt nicht im Submodell KM, sondern durch SE. Für KM ist die Information und Abstimmung der Betroffenen das Ziel dieser Aktivität.

Erläuterung

Insbesondere, wenn die Systementwicklung nicht innerhalb einer überschaubaren Organisationseinheit erfolgt, sondern mehrere Projektgruppen, mehrere getrennte Organisationseinheiten oder mehrere Auftragnehmer und Unterauftragnehmer beteiligt sind, ist über diese Aktivität die Konsistenz der Schnittstellen mit Nachdruck zu überwachen und gegebenenfalls wiederherzustellen.


KM 4.4: Ergebnisse sichern
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.4	Ergebnisse sichern

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
KM 1	akzeptiert		KM-Plan		—	—
Extern	—		Produktbibliothek		—	—
Weitere Ergebnisse:

•	Relevanter Ausschnitt der Produktbibliothek auf Datenträger gespeichert und sicher verwahrt

•	Gegebenenfalls Muster und Prototypen von HW-Produkten

Abwicklung

Die Aktivität KM 4.4 "Ergebnisse sichern" erfolgt aufgrund der Projekterfordernisse zu unterschiedlichen Terminen/Intervallen und in dem jeweils erforderlichen Umfang:

−	In regelmäßigen Abständen (vom Projekt festgelegt) werden alle dem KM vorliegenden Ergebnisse gesichert (kontinuierliche Sicherung).

−	Zu den im Projektplan festgelegten Terminen wird von KM die Ergebnissicherung aller relevanten Produkte durchgeführt (Meilenstein-Sicherung).

−	Vor Abschluß eines Projekts werden alle projektrelevanten Ergebnisse zuverlässig gesichert, so daß sie jederzeit reproduzierbar sind und eine spätere Wiederverwendbarkeit einzelner Produkte oder des gesamten Projekts möglich ist (Projekt-abschließende Sicherung).


KM 4.5: KM-Dokumentation führen
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.5	KM-Dokumentation führen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 2	in Bearb./ akzeptiert		Konfigurations-Identifikations- dokument		—	—
KM 3	—		Änderungsmitteilung		—	—
KM 3	—		Protokoll		—	—
KM 3	—		Änderungsstatusliste		—	—
—	—		Berichtsdokumente		Projektbeteiligte	—
Weitere Informationsquellen:

•	Produktbibliothek, projektübergreifender Datenkatalog und zentraler Produktkatalog

Abwicklung

Es sind zur Vorbereitung von Entscheidungen oder zur Information des Projektmanagements, usw. verschiedene Berichte auf der Basis vorliegender KM-Unterlagen zu erzeugen, wie etwa

−	Änderungshistorie,

−	Differenzinformationen zwischen Konfigurationen, Versionen  und Dateien.


KM 4.6: Release-Management durchführen
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.6	Release-Management durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 2	in Bearb./ akzeptiert		Konfigurations-Identifikations- dokument		—	—
Weitere Ergebnisse:

•	"Konfigurationseinheit"/"auszulieferndes Produkt"

Abwicklung

Die Aktivität KM 4.6 "Release-Management durchführen" hat die Aufgabe, Konfigurationseinheiten nach bestimmten Kriterien/Optionen zu konfigurieren bzw. zu rekonfigurieren und/oder Produkte für die Auslieferung vorzubereiten. Gegebenenfalls ist zu beschreiben, wie ein Datenträger zu erstellen ist (Releaseprozedur für die Erstellung eines Datenträgers). Entsprechend ist auch eine Installationsprozedur erforderlich. Die Aktivität KM 4.6 "Release-Management durchführen" agiert dabei als die zentrale und einzige Auslieferstelle, die verhindert, daß z. B. nicht abgestimmte Änderungen in ein auszulieferndes Produkt einfließen oder daß Konfigurationsparameter irrtümlich fehlerhaft gesetzt werden.

Erläuterung

Diese Aktivität hält den Überblick über alle Auslieferungen. Typische Fragestellungen sind z. B: welche Konfigurationsvarianten wurden ausgeliefert, wann und an wen, über welches Speicher- bzw. Übertragungsmedium, zu welchem Zweck erfolgte die Auslieferung, usw.


KM 4.7: Projekthistorie führen
Teil 1	Vorgehensmodell / Regelungsteil

6	Regelungen Submodell Konfigurationsmanagement

6.2	Die Aktivitäten des Submodells KM

KM 4	KM-Dienste

KM 4.7	Projekthistorie führen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1, PM 4	in Bearb.		Projektplan		—	—
QS 5, PM 9	—		Berichtsdokumente		—	—
—	—		Projekthistorie		PM 7, PM 9, PM 14	in Bearb./ vorgelegt
Abwicklung

Ziel dieser Aktivität ist das Führen einer Projekthistorie.

Die Projekthistorie ist das "Projekt-Logbuch", in welchem der Entwicklungsverlauf dokumentiert wird. Festzuhalten sind Informationen zum Projektfortschritt und insbesondere aufgetretene Schwierigkeiten und Probleme sowie mögliche und letztlich gewählte Maßnahmen zu deren Behebung und Lösung. Ferner sind statistische Informationen über die durchgeführten Aktivitäten, Planabweichungen und -modifikationen, über beantragte, durchgeführte und abgelehnte Änderungen, über Fehlerhäufigkeit, -arten und -anfälligkeit zu halten. Informationen hierfür werden aus Projektplan und Projekthandbuch im Abgleich mit zuvor bei Kontrollaktivitäten erstellten Internen Mitteilungen und aus den von SE, PM, QS und KM verfaßten Berichtsdokumenten gewonnen.

Erläuterung

Die Projekthistorie stellt eine Dokumentation über Entwicklungsverlauf, Entscheidungen, Probleme und Schwierigkeiten sowie deren Lösung dar. Sie soll helfen, den Ablauf und die Kalkulation künftiger Projekte zu verbessern ("lessons learned").


Überblick
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.1	Überblick

Die Regelungen des Submodells Projektmanagement (PM) berühren in keiner Weise organisatorische Festlegungen. Wie die Aktivitäten des Submodells PM in einem Projekt von Personen auszuführen sind oder welchen Organisationseinheiten sie zuzuordnen sind, ist nicht Gegenstand des V-Modells.

Aktivitäten des Submodells PM beziehen sich auf folgende Bezugsobjekte:

−	Projekt

Die projektbezogenen Aktivitäten sind Tätigkeiten, die in der Regel nur einmal im Projekt durchgeführt werden. Sie umfassen u. a. das Erstellen des Projektauftrags, des Projekthandbuchs, des Projektplans und das Verfassen des Projektabschlußberichts.

−	Vergabe/Beschaffung

Die vergabebezogenen Aktivitäten behandeln die Vorbereitung und Durchführung einer Vergabe/Beschaffung sowie die Überwachung der Vertragserfüllung.

−	Planungsabschnitt

Im Projekt erfolgt eine Feinplanung für einzelne Planungsabschnitte, die projektspezifisch festzulegen sind. Im Rahmen einzelner Planungsabschnitte sind gegebenenfalls Kosten-/Nutzenanalysen durchzuführen bzw. Durchführungsentscheidungen zu treffen.

−	Periodisch durchzuführende Aktivitäten

Periodisch durchzuführende Aktivitäten umfassen u. a. Risikomanagement, Projektkontrolle und -steuerung, Informationsdienst und Berichtswesen.

−	Arbeitsabschnitt

Arbeitsabschnitte sind die kleinsten Bezugspunkte innerhalb des Submodells PM. Die Ebene der Arbeitsabschnitte umfaßt u. a. die Definition von Arbeitsaufträgen, Schulung/Einarbeitung, die Einweisung der Mitarbeiter sowie die Bereitstellung erforderlicher Einsatzmittel.

Im Vorgriff auf die Inhalte des Abschnitts 7.2 Die Aktivitäten des Submodells PM folgt eine zusammenfassende Übersicht über alle Aktivitäten und Produkte des Submodells PM sowie ein Funktionsüberblick zum Submodell PM (siehe Abbildung 7.1).

PM 1	Projektinitialisierung

PM 1.1	Projekt einrichten

PM 1.2	Projektkriterien und Entwicklungsstrategie
festlegen

PM 1.3	Projektspezifisches V-Modell erstellen	⇒ Projekthandbuch

PM 1.4	Toolset-Management durchführen

PM 1.5	Grobplan erstellen	⇒ Projektplan

PM 2	Vergabe/Beschaffung	⇒ Angebotsbewertung

PM 3	Auftragnehmer-Management

PM 4	Feinplanung	⇒ Projektplan

PM 5	Kosten-/Nutzenanalyse	⇒ Kosten-/Nutzenanalyse

PM 6	Durchführungsentscheidung

PM 7	Risikomanagement

PM 8	Projektkontrolle und -steuerung

PM 9	Informationsdienst/Berichtswesen

PM 10	Schulung/Einarbeitung

PM 11	Bereitstellung der Ressourcen

PM 12	Vergabe von Arbeitsaufträgen	⇒ Arbeitsauftrag

PM 13	Einweisung der Mitarbeiter

PM 14	Projektabschluß	⇒ Projektabschlußbericht

Anmerkung zur Übersicht:

In der obigen Übersicht wird ein Produkt als Ergebnis derjenigen (Teil-) Aktivität aufgeführt, die das betreffende Produkt fertigstellt.

Abbildung 7.1: Funktionsüberblick Submodell PM


PM 1: Projektinitialisierung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		V-Modell		—	—
Extern	—		Projektauftrag		—	—
—	—		Projekthandbuch		PM 2, PM 3, PM 4, PM 8, PM 10-PM 12, KM 1, KM 4, QS 1	vorgelegt
PM 7	in Bearb.		Projektplan		PM 3, PM 4, PM 6-PM 8, PM 10-PM 12, KM 1, KM 4, QS 1	in Bearb. *)
*)	Der Zustand "in Bearb." spiegelt lediglich den KM-Aspekt wider. Dessen ungeachtet ist eine Autorisierung des Projektplans durch das zuständige Projektmanagement, gegebenenfalls unter Beteiligung des QS-Verantwortlichen, erforderlich.

Abwicklung

Die Initialisierung ist die erste Aktivität bei der Abwicklung eines Projektes. Ihr Ziel ist die Festlegung des organisatorischen Rahmens im Projekthandbuch. Die Modalitäten der projektinternen Zusammenarbeit sowie der Schnittstelle zu externen Beteiligten sind festzulegen.

Für das Projekthandbuch sind Projektkriterien und -randbedingungen zu ermitteln, auf deren Basis das Tailoring des V-Modells zu erfolgen hat. Ergebnis des Tailoring ist das projektspezifische V-Modell, welches Bestandteil des Projekthandbuchs ist.

Basierend auf dem Projekthandbuch und unter Zuhilfenahme von evtl. vorhandenen Projekthistorien ähnlich gelagerter Projekte ist im Projektplan eine Grobplanung durchzuführen, die die Aufwands-, Termin- und Personalplanung zunächst in einer ersten Näherung bis zum Projektende darlegt.

Das Projektmanagement hat ferner eine speziell auf das Projekt zugeschnittene Entwicklungsumgebung auszuwählen und verfügbar zu machen.


PM 1.1: Projekt einrichten
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

PM 1.1	Projekt einrichten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Projektauftrag		—	—
—	—		Projekthandbuch. Projektorganisation		PM 1.3	in Bearb.
Abwicklung

Ziel dieser Aktivität ist es, einen definierten Startpunkt für das Projekt festzulegen und die Voraussetzungen für den Projektbeginn zu schaffen.

Die Voraussetzung zur Abwicklung dieser Aktivität ist das Vorliegen eines Projektauftrages, der mindestens folgendes enthalten muß:

−	die Darstellung der Ziele des Projekts (einschließlich der Aussage, ob es sich um ein Entwicklungs- oder SWPÄ-Projekt handelt),

−	eine Aussage, daß durch das dem Projekt übergeordnete Management die notwendigen Finanzmittel genehmigt sind (Grundlage für die Genehmigung ist die Ermittlung des Finanzbedarfs),

−	die Ernennung eines Projektleiters und die Festschreibung seiner Kompetenzen und Verantwortung.

Zur Durchführung dieser Aktivität gehören folgende Tätigkeiten:

* Organisationsplanung

Die Organisationsplanung definiert die gesamte Aufbauorganisation des Projekts. Die für das Projekt notwendigen Rollen werden den vorgesehenen Personen zugeordnet. Die organisatorischen Festlegungen sind für die Bereiche SE, QS, KM und PM zu treffen.

Für alle künftigen Entscheidungen (Kauf, Vergabe, usw.) sind, abhängig von der Tragweite der Entscheidung, die jeweiligen Entscheider festzulegen.

Alle Ergebnisse, die einer Genehmigung bedürfen, sind zu identifizieren, und die jeweiligen Genehmigungsinstanzen sind festzulegen.

Entsprechend den (gegebenenfalls vertraglichen) Erfordernissen ist festzulegen, wann welche Berichte für wen zu erstellen sind. Die Erstellung der Berichte erfolgt in Aktivität PM 9 "Informationsdienst/Berichtswesen".

Falls das System begleitend evaluiert werden soll, sind die Beteiligung der Evaluationsstelle und des BSI als Zertifizierungsstelle als organisatorische Randbedingungen zu berücksichtigen.

* Projekt etablieren

Das Projekt wird verwaltungsmäßig eingerichtet, damit mit der Bearbeitung begonnen werden kann. Der Projektleiter beruft eine konstituierende Sitzung (Kick-off-Meeting) mit allen Projektmitarbeitern ein und informiert die Projektmitarbeiter über Aufgabe, Art, Umfang und Terminsituation des geplanten Projekts.


PM 1.2: Projektkriterien und Entwicklungsstrategie festlegen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Projektauftrag		—	—
PM 1.1	in Bearb.		Projekthandbuch		—	—
—	—		Projekthandbuch. Projektbeschreibung, Entwicklungsstrategie		PM 1.3, PM 1.4	in Bearb.
Abwicklung

Ziel dieser Aktivität ist es, Gegenstand und Umfang des Projekts kurz und prägnant zu beschreiben und strategische Rahmenbedingungen für die Systementwicklung vorzunehmen.

* Projektbeschreibung erstellen

Zunächst sind die externen Vorgaben (gefordertes Endprodukt, Phasenabdeckung, usw.) zu klären. Insbesondere sind zu berücksichtigende Eingangsprodukte und Voraussetzungen festzuhalten, gegebenenfalls nach einer angemessenen Präzisierung.

Projektkriterien, insbesondere solche, die das Tailoring beeinflussen, sind im Projekthandbuch festzuhalten. Die Kriterien sind aus den externen Vorgaben, aus Abstimmgesprächen mit allen Beteiligten, und auch durch AN-interne Bedingungen zu ermitteln. Zu ermitteln sind weiter projektspezifische Anforderungen und Merkmale, wie z. B. Grad der geforderten Prüfungsabdeckung, vorläufige Einstufungen des Systems hinsichtlich Verläßlichkeit (Kritikalität und Sicherheit), genutzte Entwicklungs- und SWPÄ-Umgebung oder der Einsatz einer bestimmten Programmiersprache.

Eine wichtige Projektanforderung und ein entscheidendes Kriterium für das Tailoring liegt im SWPÄ-Konzept des Systems. Das Projektmanagement hat schon zu Beginn des Entwicklungsprojektes Entscheidungsgrundlagen zu erarbeiten, die Aussagen über das Produkt-Weiterentwicklungskonzept, die Änderungswahrscheinlichkeit und das SWPÄ-Konzept enthalten.

Hierzu müssen folgende Fragen beantwortet werden:

−	Welche Teile des Systems sind zu warten?

−	Über welchen Zeitraum muß SWPÄ sichergestellt werden?

−	Wer führt SWPÄ am System durch?

−	Ist der Umfang der SWPÄ begrenzt, z. B. auf reine Pflegemaßnahmen?

−	Ist auf Wiederverwendbarkeit zu achten?

Als besondere Projektkriterien sind die kritischen Erfolgsfaktoren  des Projekts zu benennen. Damit kann bei Projektabschluß das Ausmaß des Erfolges bestimmt werden. Neben Termin- und Kostentreue ist die Zufriedenheit des Auftraggebers als kritischer Erfolgsfaktor zu berücksichtigen.

In der Regel sind bereits eine Reihe von technischen Sachverhalten (Randbedingungen) bekannt, die den Projektverlauf beeinflussen. Diese technischen Sachverhalte und ihre Auswirkung auf den Projektverlauf sind in der Projektbeschreibung darzustellen. Die Auswirkungen dieser technischen Sachverhalte bzw. Vorergebnisse sollten in Aktivität PM 1.3 "Projektspezifisches V-Modell erstellen" im Rahmen der Anpassung der Aktivitätenbeschreibungen oder Technischen Streichbedingungen berücksichtigt werden.

Es ist festzulegen, ob das zu erstellende System evaluiert werden soll. Ferner sind gegebenenfalls Vorgaben zur IT-Sicherheit zu beachten.

* Entwicklungsstrategie auswählen

Anhand der Projektbeschreibung ist eine Entwicklungsstrategie auszuwählen. Die Entwicklungsstrategie hat die Rahmenbedingungen der Systementwicklung des Projekts festzulegen. Hierbei ist u. a. zu bestimmen, ob die Entwicklung in einer oder mehreren Ausbaustufen aufwachsen soll (klassische vs. inkrementelle Entwicklung).

Erläuterung

Die vom Projektmanagement hier vorzubereitende Entscheidung beeinflußt weitere Aktivitäten des Projektmanagements:

−	PM 1.3 "Projektspezifisches V-Modell erstellen",
insbesondere die Entscheidung über Relevanz und Umfang der durchzuführenden Aktivitäten und der zu erstellenden Produkte.

−	PM 1.4 "Toolset-Management durchführen",
die Auswahl der SEU muß unter Beachtung des SWPÄ-Konzepts stattfinden.

−	PM 1.5 "Grobplan erstellen",
die Entscheidung über das SWPÄ-Konzept beeinflußt unmittelbar die Aufwands- und Terminplanung des Projekts; ferner müssen auch in der Personalplanung Gesichtspunkte der SWPÄ eine Rolle spielen.

Die kritischen Erfolgsfaktoren  sind Orientierungshilfen, an denen der Projektleiter seine Arbeit ausrichten kann und nach denen das Projekt am Ende bewertet wird. Sie können besonders hilfreich zur Bewältigung von Konfliktsituationen sein. Mangelnde Produktqualität, Unzuverlässigkeit bei den Lieferungen, schlechtes Unternehmensimage, mangelnde Qualifikation der Mitarbeiter, mangelnde Flexibilität und Erfahrungen des Mangements, veraltete Verfahren und Produktionstechniken zählen zu den häufigsten Faktoren, die einen Projekterfolg gefährden.


PM 1.3: Projektspezifisches V-Modell erstellen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

PM 1.3	Projektspezifisches V-Modell erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		V-Modell		—	—
Extern	—		Projektauftrag		—	—
PM 1.1, PM 1.2	in Bearb.		Projekthandbuch		—	—
—	—		Projekthandbuch. Übersicht, Projektspezifisches V-Modell, Beteiligung des AG		PM 1.4	in Bearb.
Abwicklung

Ziel dieser Aktivität ist die Durchführung einer projektspezifischen Anpassung des V-Modells. Das Ergebnis wird im Projekthandbuch niedergelegt. Dieses soll (im Fall einer Vergabe nach außen) die Kommunikationsgrundlage zwischen Auftraggeber und Auftragnehmer sein.

Die Erstellung des Projekthandbuchs (PHb) erfolgt in einer Reihe von Teilschritten. Dabei bilden die Schritte "Festlegung der Form des projektspezifischen V-Modells", "Selektion und Anpassungen von Aktivitäten und Produkten" und "Festlegungen von Streichbedingungen für das Technische Tailoring" zusammen das Ausschreibungsrelevante Tailoring. Nicht zwingend erforderliche Teilschritte sind als "optional" gekennzeichnet.

* Form des projektspezifischen V-Modells festlegen

−	Erzeugung eines projektspezifischen V-Modells als Teilmenge des generischen V-Modells

oder

−	Referenzierung der V-Modell-Aktivitäten und -Produkte

* Aktivitäten und Produkte selektieren und anpassen

−	Selektion von Aktivitäten- und Produktklassen, die für das Projekt prinzipiell sinnvoll sind

Hier ist zu unterscheiden, inwieweit einer von den in Teil 3 "Handbuchsammlung" definierten Vorhabentypen mit dem geplanten Vorhaben übereinstimmt. Läßt sich kein geeigneter Vorhabentyp finden, so können die Streichbedingungen aus dem Teil 3 "Handbuchsammlung" herangezogen werden. Ziel ist es, für die im Projekt nicht-relevanten Aktivitäten- und Produktklassen Streichgründe anzugeben. Die Streichgründe werden in das Kapitel Projekthandbuch.Übersicht übernommen. Aktivitäten- und Produktklassen ohne Streichbedingungen sind in das Kapitel Projekthandbuch.Projektspezifisches V-Modell aufzunehmen.

−	Anpassung von Aktivitätenbeschreibungen (optional)

Die V-Modell-Aktivitätenbeschreibungen enthalten Fallbeschreibungen und -unterscheidungen aller möglichen Projektszenarien und -umstände. In einem konkreten Projekt können diese Fallunterscheidungen entfallen; die Beschreibungen können auf konkrete Projektbedingungen Bezug nehmen. Häufig existieren technische Sachverhalte oder Vorergebnisse. Auf diese und die Konsequenzen hieraus sollte in den Aktivitätenbeschreibungen individuell eingegangen werden.

Dies heißt, daß alle nicht relevanten Teile der Beschreibungstexte der Aktivitäten, Empfehlungen und Erläuterungen gestrichen werden können. Aus solchen Streichungen kann die Notwendigkeit resultieren, daß sprachliche Formulierungen angepaßt werden müssen. Die verbleibenden Textteile können mit konkreten Projektbezügen ergänzt werden, wie z. B. Bezüge auf Voruntersuchungen, bestehende Ergebnisse, Vereinbarungen oder Hinweise, für wen (HAN oder UAN) die Aktivität relevant ist. Letzteres ist besonders dann sinnvoll, wenn für HAN und UAN nur ein gemeinsames Projekthandbuch geschrieben werden soll.

Die Zustimmung des AG zum Projekthandbuch bedeutet damit auch eine Zustimmung zu den vorgenommenen Streichungen und Textmodifikationen.

* Streichbedingungen für das Technische Tailoring festlegen

Bereits zu Projektbeginn ist festzulegen, unter welchen Bedingungen konkrete Ausprägungen (Instanzen) von Aktivitäten- und Produktklassen während des Projekts entfallen können. Technische Bedingungen aus dem Teil 3 "Handbuchsammlung" (Handbuch "Tailoring") können hierzu verwendet werden. Die für das Projekt relevanten Streichbedingungen sind zu den Aktivitäten und Produkten des projektspezifischen V-Modells (Kapitel Projekthandbuch.Übersicht) und während des Projektverlaufs in Aktivität PM 4 "Feinplanung" auf die jeweiligen Aktivitäten anzuwenden.

* Beteiligung des AG

Die Beteiligung des AG am Projekt liegt in seiner eigenen Entscheidungsbefugnis. Entsprechend seinen Mitwirkungswünschen und -möglichkeiten sind die Aktivitäten/Rollen-Matrizen  (siehe Teil 3 "Handbuchsammlung", Handbuch "Rollenkonzept im V-Modell") anzupassen. Diese Information ist für den AN von Bedeutung, damit er weiß, wo er mit einem möglichen Einspruch des AG zu rechnen hat. Darüber hinausgehende Rechte/Pflichten des AG können im Rahmen des Vertrags festgelegt werden.

* Übersicht über vertragsrelevante Festlegungen erstellen

Im Projekthandbuch sind vertragsrelevante Festlegungen (durchzuführende bzw. gestrichene Aktivitäten und Produkte, Liefergegenstände, Beteiligung des AG) übersichtlich zusammenzustellen. Die nicht auszuliefernden Produkte sind als interne Entwicklungsdokumente anzusehen.

Weiter ist eine Abstimmung und Prüfung des Projekthandbuchs zwischen AG (Rolle "Projektmanager" oder "Q-Manager") und dem "QS-Verantwortlichen" im Projekt bezüglich der Vollständigkeit, Klarheit und Realisierbarkeit durchzuführen.

Bei erfolgreicher Prüfung wird das Projekthandbuch in den Zustand "akzeptiert" überführt.

Erläuterung

Im QS-Plan wird aufgeführt, für welche Aktivitäten und Produkte die Prüfaktivitäten (QS 2 "Prüfungsvorbereitung" und QS 4 "Produktprüfung") im Projekt durchgeführt werden müssen.

Das Projekthandbuch ist (im Gegensatz zum Projektplan) ein weitgehend unveränderliches, statisches Dokument.


PM 1.4: Toolset-Management durchführen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

PM 1.4	Toolset-Management durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1.2, PM 1.3	in Bearb.		Projekthandbuch		—	—
—	—		Projekthandbuch. Methoden/Werkzeuge, Standards/Richtlinien		PM 1.5, PM 2-PM 4, PM 8, PM 10-PM 12, KM 1, KM 4.7, QS 1	vorgelegt
Weitere Ergebnisse:

•	Auswahl der Entwicklungsumgebung/Prüfumgebung

Abwicklung

Ziel dieser Aktivität ist die Auswahl von Hilfsmitteln zur Durchführung des Projekts.

Für alle Submodelle sind Methoden und Werkzeuge sowie Standards und Richtlinien festzulegen. Die Methoden und Werkzeuge sind den Aktivitäten und Produkten des projektspezifischen V-Modells verbindlich zuzuordnen.

Die Auswahl von Methoden und Werkzeugen erfolgt auf der Basis von Standards oder empfohlener Hilfsmittel. Sofern die Einhaltung bestimmter Standards, wie beispielsweise AU 251 und AU 252 im Geschäftsbereich des BMVg, vorgeschrieben ist, muß für die getroffenen Festlegungen der Nachweis der Standardkonformität erbracht werden.

Zwischen den Beteiligten (AG, AN, Nutzer) ist bezüglich Methoden- und Werkzeugfestlegung ein Einvernehmen zu erzielen.

Neben der Auswahl von Methoden und Werkzeugen für die Entwicklungsumgebung und der Festlegung von Standards und Richtlinien umfaßt diese Aktivität die Vorabauswahl der Zielrechnerausstattung und der zielrechnerbezogenen Werkzeuge.

Spezifische Anforderungen bezüglich Entwicklungsumgebung und zielrechnerbezogener Werkzeuge (z. B. Cross-Compiler), die sich aus den konkreten Qualitätsanforderungen an die zu entwickelnde Software ergeben, werden im Submodell SE erarbeitet und festgeschrieben. Daraus resultiert gegebenenfalls eine Ergänzung der in Aktivität PM 1.4 "Toolset-Management durchführen" erfolgten Festlegungen.

Falls erforderlich, wird die Eignung der gewählten Hilfsmittel durch spezielle Erprobungen festgestellt.

Die IT-Maßnahmen, die durch Sicherheitsfunktionen oder andere Konzepte realisiert werden, benötigen eine den Verläßlichkeitsanforderungen entsprechende Vertrauenswürdigkeit. Diese wird u. a. durch die Qualität ihrer Realisierung (z. B. E-Stufe) bestimmt. Abhängig davon muß aber eine Entwicklungsumgebung gewählt werden, die die Voraussetzungen erfüllt.

Gegebenenfalls sind Mindestanforderungen an Methoden und Werkzeugen zu beachten.

Aus IT-Sicherheitsgründen können spezifische Forderungen gestellt werden, um innerhalb der Entwicklungsumgebung verschiedene Nutzer und Rollen unterscheiden zu können und deren Accountability sicherzustellen.

Dies kann z. B. dazu dienen,

−	Nutzer für Aktivitäten und Aktionen zu autorisieren oder

−	Rollentrennung zur Durchführung von Aktivitäten zu ermöglichen.

Empfehlung

Im Hinblick auf spätere SWPÄ  ist eine langfristige Technologieplanung erforderlich, die folgende Kriterien erfüllt:

−	Technologie ist verfügbar bis

•	entweder Ende der Nutzung,

•	Ende der SWPÄ oder

•	Ende der Entwicklung.

−	Der Werkzeughersteller leistet Support.

−	Der Werkzeughersteller gibt u. U. eine Zusicherung über eine angemessene Weiterentwicklung des Produktes, was sowohl für die im System verwendete Technologie als auch für die den Entwicklungsprozeß unterstützende Technologie nötig ist.

Erläuterung

Die im Rahmen von Aktivität PM 1.2 "Projektkriterien und Entwicklungsstrategie festlegen" festgelegten Projektkriterien haben gegebenenfalls bereits eine engere Auswahl von Methoden und Werkzeugen vorweggenommen.

Weitere relevante Kriterien sind u. a. Zuverlässigkeit und Robustheit eines Werkzeugs, Verbreitung und Referenzen, Kompatibilität, Anpaßbarkeit, Wartbarkeit und Flexibilität, Netzfähigkeit, Support, Nutzung durch den Nutzungsverantwortlichen, andere AN, den AG und UAN, usw.

Das Projektmanagement hat für adäquate Einsatzunterstützung zu sorgen. Hierfür sind erforderlich:

−	Einbindung der Entwicklungsumgebung in die Organisation,

−	Ressourcen für die Werkzeug-Anwendung,

−	Schulung, Beratung und Unterstützung der Werkzeug-Anwender,

−	Freigabe von neuen Werkzeug-Versionen für das Projekt.


PM 1.5: Grobplan erstellen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 1	Projektinitialisierung

PM 1.5	Grobplan erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern	—		Projektauftrag		—	—
PM 1.4	akzeptiert		Projekthandbuch		—	—
PM 7	in Bearb.		Projektplan		PM 3, PM 4, PM 6-PM 8, PM 10-PM 12, KM 1, KM 4.7, QS 1	in Bearb. *)
*)	Der Zustand "in Bearb." spiegelt lediglich den KM-Aspekt wider. Dessen ungeachtet ist eine Autorisierung des Projektplans durch das zuständige Projektmanagement, gegebenenfalls unter Beteiligung von QS-Verantwortlichen, erforderlich.

Abwicklung

Ziel der Aktivität ist es, eine Grobplanung über das gesamte Projekt durchzuführen.

Hierzu sind die Randbedingungen (aus Aktivität PM 1.2 "Projektkriterien und Entwicklungsstrategie festlegen") und das projektspezifischen V-Modell (relevante Aktivitäten und Produkte) zu berücksichtigen.

Die Planung  ist in mehreren Schritten zu erarbeiten:

Da ab einer gewissen Kritikalität spezielle Anforderungen an den Entwicklungsvorgang und an die Entwicklungsumgebung gestellt werden, müssen gegebenenfalls rechtzeitig Werkzeuge zur Verfügung gestellt werden, die über die geforderte Funktionalität bzw. Qualität verfügen.

Es muß erfahrenes Personal vorhanden sein, das eine Analyse des Zusammenwirkens der gewählten IT-Maßnahmen (Sicherheitsfunktionen und Sicherheitskonzepte) durchführen kann. Ebenso muß dieses Personal imstande sein, Wirksamkeitsanalysen für die Mechanismen und Verfahren durchzuführen, die zur Implementierung der Sicherheitsfunktionen und Sicherheitskonzepte gewählt wurden.

Bei höherer Kritikalität muß Personal verfügbar sein, das entsprechende Erfahrung im Umgang mit semiformalen bzw. formalen Spezifikationen hat.

Soll eine begleitende Evaluation durchgeführt werden, muß die Mitarbeit der Evaluatoren und des BSI bei der Planung ebenfalls berücksichtigt werden.

* Aufwands- und Terminplanung

In diesem Teil der Projektplanung sind Soll-Vorgaben von Terminen, Planungsabschnitten und Aufwänden auf der Basis der Organisationsplanung im Projekthandbuch festzuschreiben, wobei es sich hier um die anfängliche Grobplanung für das Projekt handelt. Vorgaben des Auftraggebers bezüglich Zwischen- und Endterminen sowie Meilensteine sind in den Projektplan zu übernehmen. Zur Vereinfachung können dabei die Aufwände für QS, KM und PM durch prozentuale Erfahrungswerte angesetzt werden.

Die Feinplanung für den jeweils nachfolgenden Planungsabschnitt ist bei dessen Initialisierung durchzuführen.

* Baselines planen

Die im Laufe des Projekts zu erstellenden Produkte sind zu definierten Baselines  zusammenzufassen. Kriterium für die Festlegung von Baselines ist die Bestimmung von Meilensteinen innerhalb eines Projekts.

Für Produkte innerhalb einer Baseline, die einem dynamischen Bearbeitungsprozeß unterliegen (Verfeinerung der Aussagen, Ergänzung zusätzlicher Aussagen), ist insbesondere der geplante Bearbeitungsstand der entsprechenden Produkte festzuschreiben.

* Durchführungsentscheidungen planen

Die im Projekt relevanten Durchführungsentscheidungen sind festzulegen. Bezugspunkte für Durchführungsentscheidungen sind beispielsweise Baselines oder die Entscheidung für die Auswahl eines Auftragnehmers.

* Einsatzmittelplanung

Innerhalb der am Projekt beteiligten Organisationen ist (unter Zuhilfenahme der Aktivitäten/Rollen-Matrizen) festzulegen, welche Personen welche Projektaktivitäten durchzuführen haben und welche Ressourcen für die einzelnen Aufgaben bereitzustellen sind. Ferner ist festzuschreiben, für welche Zeiträume die Personen und Hilfsmittel in welchem Auslastungsgrad benötigt werden.

Empfehlung

Um möglichst realistische Plandaten gewährleisten zu können, sollte folgendes beachtet werden:

−	hohe Kritikalität und Sicherheit beeinflussen Aufwand und Termine, erfordern umfangreiche und ausgereifte Ressourcen sowie erfahrenes Personal,

−	die verantwortlichen Bearbeiter der Projektaktivitäten sollten bei der Aufwandsschätzung und Terminplanung hinzugezogen werden,

−	bei Schätzung und Planung sollten auch Alternativen der Aufgabenlösung berücksichtigt werden,

−	Planung muß nicht vorhersehbare Krisensituationen mit einkalkulieren (Pauschalierung auf der Basis von Erfahrungswerten),

−	der Aufwand für Managementtätigkeiten, projektinterne Kommunikation und Koordination sollte nicht unterschätzt werden.

Ein weiterer Weg zu realistischen Plandaten liegt darin, Projekthistorien ähnlich gelagerter, bereits abgeschlossener oder zumindest weiter vorangeschrittener Projekte zu analysieren. Hierdurch können Rückschlüsse auf das gegenwärtige Projekt gezogen werden. Dies setzt voraus, daß in vorhandenen Historie- und Statistikdokumenten die Ursachen früherer Probleme aufgezeigt wurden.

Wichtiger Punkt der Planung ist die Koordination von SWPÄ-Maßnahmen, Unterauftragnehmern und Teilprojekten. Diese Koordinationsaufgabe beschränkt sich jedoch nicht nur auf projekt- bzw. produktinterne Angelegenheiten, sondern auch auf projektübergreifende Sachverhalte, da es nur so möglich ist, (Teil-) Produkte wiederzuverwenden und Erfahrungen der einzelnen Mitarbeiter optimal auszunutzen.

Erläuterung

Im Rahmen der Projektinitialisierung erfolgt die Grobplanung für die gesamte Projektlaufzeit. Feinplanungen finden projektbegleitend statt, in der Regel zu Beginn eines Planungsabschnitts.


PM 2: Vergabe/Beschaffung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 2	Vergabe/Beschaffung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		Extern *)	—
—	—		Ausschreibungsunterlagen **)		Extern	vorgelegt
PM 6	—		Berichtsdokumente		—	—
Extern	—		Angebot **)		—	—
—	—		Angebotsbewertung		PM 6	vorgelegt
—	—		Vertrag ***)		PM 3, extern	—
*)	Im Falle einer Beschaffung wird das Projekthandbuch nicht nach außen gegeben.

**)	Die Form ist im Regelungsteil des V-Modells nicht geregelt.

***)	Verträge werden in der Bundesverwaltung im allgemeinen auf Grundlage der BVB (zukünftig EVB) geschlossen.

Abwicklung

Ziel der Aktivität ist die Bestimmung des wirtschaftlichsten Angebots für eine extern zu vergebende Leistung durch Abschluß eines Vertrags. Wesentliche Rahmenbedingung bildet das Vergaberecht.

Diese Aktivität ist immer dann durchzuführen, wenn Leistungen extern vergeben werden sollen bzw. wenn Beschaffungen (z. B. von Fertigprodukten) anstehen.

Die Aktivität setzt sich aus den Einzelaspekten

−	Ausschreibung durchführen

−	Angebot auswerten

−	Vertrag schließen

zusammen.


PM 3: Auftragnehmer-Management
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 3	Auftragnehmer-Management

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 2	—		Vertrag		—	—
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
PM 1	akzeptiert		Projekthandbuch		—	—
PM 8	—		Berichtsdokumente		PM 4, PM 8, extern	—
Abwicklung

Ziel dieser Aktivität ist die Überwachung der Vertragserfüllung.

Das Auftragnehmermanagement basiert auf den im Vertrag, dem Projektplan und dem Projekthandbuch getroffenen Festlegungen. Es sind der Arbeitsfortschritt beim AN zu überwachen und die Einhaltung der vereinbarten Termine zu überprüfen. Weiter ist zu überprüfen, ob getroffene Vereinbarungen eingehalten und die zugesicherten Qualitätssicherungsmaßnahmen durchgeführt werden. Die Abnahme der vom AN gelieferten Produkte ist durchzuführen.

Darüber hinaus sind Fragen zu klären, die sich aus einer gegebenenfalls fehlenden Eindeutigkeit von vertraglichen Formulierungen bzw. von technischen Spezifikationen ergeben.

Falls mehrere Auftragnehmer parallel beauftragt sind, so sind deren Arbeiten zu koordinieren.

Bei UAN-Verhältnissen muß die Konsistenz zum Hauptvertrag gewährleistet sein.

Empfehlung

Bei dieser Aktivität soll die vertragsverwaltende Stelle beteiligt werden. Dadurch kann vermieden werden, daß durch bestimmte Handlungen, Duldungen oder Unterlassungen unbeabsichtigt die aktuelle Vertragssituation verändert wird. Beispielsweise führt widerspruchslose Entgegennahme nicht vereinbarter Leistungen u. U. automatisch zur Änderung des Vertrags.

Über alle Besprechungen, in denen Vereinbarungen zwischen Auftragnehmer und Auftraggeber getroffen wurden, sollte ein Protokoll erstellt werden, das von beiden Parteien zu unterzeichnen ist.


PM 4: Feinplanung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 4	Feinplanung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 2	in Bearb./ akzeptiert		Systemarchitektur		—	—
PM 1	akzeptiert		Projekthandbuch		—	—
PM 3, PM 6, PM 8	—		Berichtsdokumente		—	—
—	—		Produkt		KM 2	geplant
PM 1	in Bearb.		Projektplan		PM 3, PM 4, PM 6-PM 8, PM 10-PM 12, PM 14, KM 4	in Bearb. *)
*)	Der Zustand "in Bearb." spiegelt lediglich den KM-Aspekt wider. Dessen ungeachtet ist eine Autorisierung des Projektplans durch das zuständige Projektmanagement, gegebenenfalls unter Beteiligung von QS-Verantwortlichen, erforderlich.

Abwicklung

Ziel dieser Aktivität ist es, für den nächsten Planungsabschnitt (eine oder mehrere Haupt- oder Teilaktivitäten) auf der Basis der bestehenden Grobplanung (Aktivität PM 1.5 "Grobplan erstellen") und unter Berücksichtigung der Festlegungen im Projekthandbuch eine Feinplanung durchzuführen.

Die Feinplanung besteht aus folgenden Teilschritten:

* Technisches Tailoring

Ausgehend von der Grobplanung ist hier zu entscheiden, ob eine im Projekthandbuch vorgesehene Aktivität oder ein Produkt im konkreten Fall sinnvoll ist oder nicht (Aktivitäten- und Produktinstantiierung). Dies führt zu einer Festlegung des Aktivitätenumfangs (z. B. Aktivitäten entfallen oder werden zusammengelegt) und zu einer Aktualisierung der Produktstruktur (falls dadurch z. B. Kapitel entfallen).

Diese Tätigkeit ist jeweils vor der Ausführung einer Aktivität oder vor der Erstellung eines Produkts durchzuführen.

Hierfür werden alle im Kapitel "Übersicht" des Projekthandbuchs befindlichen technischen Streichbedingungen auf die zur Diskussion stehende Aktivität bzw. auf das Produkt angewendet. Ist die zu einer Aktivität oder einem Produkt gehörige Bedingung erfüllt, so kann die/das jeweilige Aktivität/Produkt bzw. Produktkapitel entfallen.

Aktivitäten bzw. Produkte, zu denen keine technische Streichbedingung angegeben ist oder deren Streichbedingung nicht erfüllt ist, sind durchzuführen bzw. zu erstellen.

Bei der Erstellung von Produkten ist zu beachten, daß für Kapitel, deren zugehörige Streichbedingung erfüllt ist und die damit entfallen können, die Kapitelüberschrift und die Kapitelnumerierung erhalten bleiben soll. Anstelle des Kapiteltextes steht dann der Grund der Kapitelstreichung.

* Produktstruktur und Ablauforganisation planen

Es ist zu planen, welche neuen Produkte im nächsten Entwicklungsabschnitt zu erstellen sind. Diese sind − falls noch nicht vorhanden − im Produktstrukturplan zu ergänzen.

Für die Aktivitäten des nächsten Planungsabschnitts ist zu entscheiden, wer, wann, welche Aufgaben übernimmt und welche Abhängigkeiten zwischen diesen bestehen (Ablauforganisation). KM- und PM-Aktivitäten werden nur dann geplant, wenn die pauschalen Angaben im KM-Plan bzw. Projekthandbuch nicht ausreichen. Die Planung von QS-Aktivitäten geschieht im Prüfplan. Sobald neue Produkte geplant sind, sind diese zur Konfigurationsidentifikation weiterzuleiten (das Produkt erhält den Zustand "geplant".)

* Aufwands- und Terminplanung

Basierend auf der bestehenden Grobplanung müssen für alle geplanten Aktivitäten Aufwände und Termine ermittelt werden. Einfluß hierauf hat die Kritikalitäten/Methoden-Matrix, die für Produkte mit hoher Kritikalität einen erhöhten Erstellungs- und Prüfaufwand fordert.

In Abhängigkeit von den Erkenntnissen des Risikomanagements ist gegebenenfalls die Grobplanung zu modifizieren.

* Ressourcenplanung

Für die sich aus dem Technischen Tailoring ergebenden Aktivitäten und Produkte ist eine detaillierte Planung der Ressourcen durchzuführen. Hierzu zählen die zur Erfüllung der Aufgaben erforderliche Infrastruktur, Hardware, Systemsoftware, Werkzeuge und Geräte.

* Baselines planen

Je nach Projektfortschritt sind weitere Baselines festzulegen. Für Produkte innerhalb einer Baseline, die einem dynamischen Bearbeitungsprozeß unterliegen (Verfeinerung der Aussagen, Ergänzung zusätzlicher Aussagen), ist der geplante Bearbeitungsstand der entsprechenden Produkte innerhalb der Baseline festzuschreiben.

* Teilprojekte/Unteraufträge

Sofern vertraglich zulässig, kann es für Entwicklungstätigkeiten erforderlich werden, Unteraufträge zu vergeben. Hierzu sind Teilprojekte mit genau definierten Aufgabenstellungen (zu erstellende Produkte, durchzuführende Aktivitäten) zu bilden. Mit in Frage kommenden Unterauftragnehmern ist zu verhandeln und letztendlich mit dem ausgewählten Partner ein Vertrag zu schließen (Aktivität PM 2 "Vergabe/Beschaffung"). So wird ein Systemkomplex separiert, an externe Auftragnehmer vergeben und parallel entwickelt. Die Überwachung der Vertragserfüllung erfolgt im Rahmen von Aktivität PM 3 "Auftragnehmer-Management". Das gleiche gilt, wenn interne Teilprojekte gebildet werden. Es werden hierfür Teilprojektleiter ernannt, die mit einem eigenen Team einen abgeschlossenen Komplex entwickeln, fachlich selbständig vorgehen, organisatorisch aber dem Projektmanagement des Gesamtprojektes unterstehen.

Empfehlung

Bei der Feinplanung sollte zunächst von den SE- (Haupt-) Aktivitäten ausgegangen werden und darauf basierend die dazu in Beziehung stehenden QS- und KM-Aktivitäten geplant werden.

Erläuterung

Die Einstufung eines Systems und seiner Funktionseinheiten hinsichtlich Kritikalität und Sicherheit hat Rückwirkung auf die Feinplanung. Die mit der jeweiligen Evaluationsstufe geforderten Maßnahmen, Produkte, Methoden und Werkzeuge müssen berücksichtigt werden. Bei Bedarf sind Änderungsanträge/Problemmeldungen zum Projekthandbuch und zum QS-Plan zu formulieren.


PM 5: Kosten-/Nutzenanalyse
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 5	Kosten-/Nutzenanalyse

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 2	in Bearb./ akzeptiert		Systemarchitektur		—	—
SE 1	akzeptiert		SWPÄ-Konzept		—	—
—	—		Kosten-/Nutzenanalyse		PM 6, SE 2	vorgelegt
Abwicklung

Ziel der Aktivität ist die Ermittlung der Rentabilität von geplanten Lösungen (für das System oder für Teile davon). 15)

15)	siehe auch "Empfehlung zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung (Empfehlung IT-WiBe)", Band 26 der Schriftenreihe der KBSt

Hierzu werden für (verschiedene) Lösungsvorschläge die jeweils erforderlichen Kosten abgeschätzt und dem zu erwartenden Nutzen gegenübergestellt.

Bei der Abschätzung von Kosten und Nutzen muß jeweils der gesamte Lebenszyklus (nicht nur die Entwicklung) der möglichen Lösung(en) betrachtet werden, wobei die verschiedenen Abschnitte des Lebenszyklus´ (Entwicklung, Nutzung, Außerbetriebsetzung) separat abzuschätzen sind. Dabei sind die Unsicherheiten der gegebenen Schätzungen, die wesentlich vom Detaillierungsgrad der vorliegenden Lösungsvorschläge mit abhängen, aufzuzeigen. Das SWPÄ-Konzept ist in die Abschätzung mit einzubeziehen.

Empfehlung

Bei der Abschätzung des Nutzens sollte zwischen quantifizierbarem und nicht quantifizierbarem Nutzen unterschieden werden.


PM 6: Durchführungsentscheidung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 6	Durchführungsentscheidung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
SE, QS, KM, PM	akzeptiert		SE-, QS-, KM-, PM-Produkte		—	—
SE 1	—		Protokoll *)		—	—
PM 2	akzeptiert		Angebotsbewertung		—	—
PM 5	akzeptiert		Kosten-/Nutzenanalyse		—	—
—	—		Berichtsdokumente		PM 2, PM 4	—
*)	Das Protokoll enthält die Ergebnisse des Forderungscontrolling (Aktivität SE 1.7).

Abwicklung

Die im Projektverlauf zu treffenden Durchführungsentscheidungen dienen folgenden Zwecken:

−	Bestätigung der im Projektplan definierten Baselines. Ihre Aufgabe ist die Feststellung,

•	ob Produkte überarbeitet und nachgereicht werden müssen, weil sie inkorrekt sind oder gar fehlen,

•	ob die nächsten Aktivitäten ordnungsgemäß geplant sind.

−	Entscheidung über die Notwendigkeit der Durchführung eines Forderungscontrolling, sofern Architekturüberlegungen (z. B. die Auswahl von Fertigprodukten) die Überprüfung der Anwenderforderungen nahe legen.

−	Entscheidung über die nach Abschluß des Forderungscontrolling durchzuführenden Maßnahmen.

−	Vorbereitung der Erstellung und Billigung von Entscheidungspapieren. 16) Ergebnis ist die Planung der nächsten Phasen.

−	Entscheidung über den Abschluß von Verträgen aufgrund der Angebotsbewertung.

−	Prüfung im Falle einer bevorstehenden Auslieferung, ob alle Voraussetzungen hierfür erfüllt sind.

16)	Bundeswehr: AU 220;
Bundesverwaltung: Phasenmodell nach BVB (zukünftig EVB).

Durchführungsentscheidungen sind Managemententscheidungen. Sofern das AG/AN-Verhältnis betroffen ist, ist dies vertraglich zu vereinbaren.

Die Ergebnisse der Durchführungsentscheidung sind in einem Protokoll festzuhalten.


PM 7: Risikomanagement
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 7	Risikomanagement

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1 oder PM 4	in Bearb.		Projektplan		PM 1 oder PM 4	in Bearb.
KM 4	in Bearb.		Projekthistorie		—	—
PM 8	—		Berichtsdokumente		PM 8, extern	—
Abwicklung

Ziel dieser Aktivität ist das rechtzeitige Erkennen möglicher Risiken im Projekt, die präventive Einleitung geeigneter Maßnahmen und die Überwachung der Wirksamkeit der eingeleiteten Maßnahmen.

Risikomanagement  ist präventiv und periodisch in regelmäßigen, möglichst kurzen Zeitabständen durchzuführen und hat in folgenden Schritten in dokumentierter Form zu erfolgen:

−	Maßnahmen, die zur Behebung von früher erkannten Risiken eingeleitet wurden, sind regelmäßig hinsichtlich ihres Erfolgs zu bewerten und gegebenenfalls zu korrigieren.

−	Mögliche neue Risiken sind zu identifizieren, ihre Eintrittswahrscheinlichkeiten sind abzuschätzen und die voraussichtlichen Schäden sind − soweit möglich − quantitativ aufzuzeigen.

−	Gegebenenfalls ist eine Priorisierung der Abwehrmaßnahmen der erkannten Risiken vorzunehmen.

−	Festlegung und Einleitung von Maßnahmen zur Minderung bzw. Vermeidung erkannter Risiken sind durchzuführen.

Vorgeschlagene Maßnahmen sind der Aktivität PM 8 "Projektkontrolle und -steuerung" über Berichtsdokumente mitzuteilen, die ihrerseits gegebenenfalls eine Fortschreibung des Projektplans (in Aktivität PM 4 "Feinplanung") veranlaßt.

Erläuterung

Risiken wirken sich stets negativ auf die geplanten Kosten, Termine und die Produktqualität aus und können verschiedene Ursachen haben.

Dazu einige Beispiele:

−	"planungsbedingte" Risiken, die durch die Projektplanung und -steuerung entstehen, so z. B. durch unrealistische Planungen, organisatorische und personelle Engpässe, unzureichenden Informationsfluß, wechselnde Anwenderforderungen, zu große Komplexität;

−	"technische" Risiken, die z. B. im Rahmen der Integration verschiedener technischer Produkte entstehen;

−	"qualitätsbezogene" Risiken, die durch das entwicklungstechnische Vorgehen entstehen, so z. B. durch Verstöße gegen das reglementierte Entwicklungsvorgehen in der Entwicklung, in der Qualitätssicherung oder dem Konfigurationsmanagement;

−	"vertragliche" Risiken, die durch Probleme auf der Auftragnehmerseite verursacht werden;

−	"finanzielle" Risiken aufgrund einer unsicheren Finanzierung;

−	"projektspezifische" Risiken aufgrund von Besonderheiten des Projektes.

Bei der Auswahl von Maßnahmen zur Behandlung von Risiken sollten die Maßnahmen untereinander koordiniert und dadurch neue Risiken vermieden werden.


PM 8: Projektkontrolle und -steuerung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 8	Projektkontrolle und -steuerung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
PM 12	—		Arbeitsauftrag		—	—
SE, QS, KM	akzeptiert		SE-, QS-, KM-Produkte		—	—
PM 3, PM 7	—		Berichtsdokumente		PM 3, PM 4, PM 7	—
Abwicklung

Ziel dieser Aktivität ist es,

−	den Projektfortschritt zu kontrollieren und

−	bei Abweichungen steuernd auf den Projektverlauf einzuwirken.

Die Kontrolle des Projektfortschritts ist zu festgelegten Terminen, periodisch oder nach Abschluß von einzelnen Aktivitäten erforderlich, um zu fundierten Aussagen über den Projektfortschritt zu gelangen und frühzeitig Planabweichungen zu erkennen und gegebenenfalls darauf reagieren zu können.

* Projektfortschritt kontrollieren

Es sind der Stand der Arbeiten (Erreichen des vorgegebenen Ziels und Erfüllung der Anforderungen) und die dafür verbrauchten Einsatzmittel und der verbrauchte Aufwand (Ist-Daten) zu ermitteln.

Diese Ist-Daten sind dann den Soll-Werten aus dem Projektplan und dem geschätzten, noch zu erbringenden Aufwand gegenüberzustellen. Dabei reicht es nicht aus, alleine den Ist-Stand der operativen SE-Aktivitäten zu ermitteln, es sind z. B. auch die Aufwände von erforderlichen QS-Maßnahmen zu berücksichtigen.

Bei tatsächlicher oder absehbarer Überschreitung der Soll-Vorgaben sind Steuerungsmaßnahmen in die Wege zu leiten.

* Steuerung

Es werden Maßnahmen durchgeführt, die das Erreichen gefährdeter Projektziele ermöglichen sollen. Dazu gehören u. a.

−	Änderung der Prioritäten,

−	Sonderbehandlung kritischer Produkte,

−	veränderte Betriebsmittel- und Personalverteilung,

−	vertragliche Anpassung,

−	Personalaufstockung und

−	externe Beauftragung von ausgegliederten Teilprojekten.


PM 9: Informationsdienst/Berichtswesen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 9	Informationsdienst/Berichtswesen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 4	in Bearb.		Projekthistorie		—	—
QS 5	—		Berichtsdokumente		KM 4, extern *)	—
*)	Verteiler laut Projektplan

Abwicklung

Ziel dieser Aktivität ist die Bereitstellung des für die Durchführung der Arbeiten erforderlichen Informationsstandes. Sie ist periodisch oder entsprechend dem jeweiligen Informationsbedarf und -angebot durchzuführen.

Im Rahmen des Informationsdiensts werden Auftraggeber und Projektmitarbeiter über den Projektverlauf auf dem aktuellen Stand gehalten. Das Projektmanagement stellt damit die Informationsschnittstelle des Projektes dar und führt Besprechungen mit Mitarbeitern, AG, Anwendern und gegebenenfalls UAN durch.

Der Informationsdienst umfaßt:

−	Informationsannahme, -beurteilung, -verteilung und -vermittlung,

−	Kommunikation projektintern und -extern.

Im Rahmen des Berichtswesens sind je nach Entwicklungsverlauf und Vertragsvereinbarungen die im Projektplan festgelegten Berichte zu erstellen.

Empfehlung

Eine Präsentation der erreichten Ergebnisse sollte nicht nur beim Projektabschluß, sondern auch bei Abschluß entscheidender Aktivitäten, also an definierten Meilensteinen erfolgen, um Anwender und AG frühzeitig und kontinuierlich in das Projekt mit einzubeziehen.

Das Projektmanagement kann diese Aktivität selbst ausführen oder auch an Bearbeiter von SE- oder QS-Aktivitäten delegieren.

Erläuterung

Zu den Berichtsdokumenten zählen im einzelnen:

−	Sachstandsbericht,

−	Sachbericht,

−	Protokoll,

−	Interne Mitteilung,

−	Aktennotiz.


PM 10: Schulung/Einarbeitung
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 10	Schulung/Einarbeitung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
Abwicklung

Ziel dieser Aktivität ist die Schulung  von Projektmitarbeitern, um ihnen die erforderlichen Kenntnisse für einzelne Arbeitsabschnitte zu vermitteln. Werden vom Projektleiter Defizite im Ausbildungsstand des geplanten Personals festgestellt, so sind entsprechende Aus- und Fortbildungsmaßnahmen zu veranlassen.

Erläuterung

Schulungen können sich auf anzuwendende Methoden, einzusetzende Werkzeuge, zu verwendende Programmiersprachen oder die Einarbeitung in das zu entwickelnde System beziehen.


PM 11: Bereitstellung der Ressourcen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 11	Bereitstellung der Ressourcen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
Abwicklung

Ziel dieser Aktivität ist die Bereitstellung der für die Durchführung von Arbeitsschritten notwendigen Mittel.

Das Projektmanagement hat die dafür erforderlichen Voraussetzungen (die im "Einsatzmittelplan" des Projektplans festgeschriebenen Werkzeuge, Arbeits- und Betriebsmittel, Rechenanlagen) zu schaffen sowie Ansprechpartner zu definieren.

Produkte, die zur Durchführung der Aktivität benötigt werden, sind gemäß Produktfluß zu identifizieren und ihre Bereitstellung durch KM zu veranlassen. Bei parallel verlaufender HW- und SW-Entwicklung ist die Synchronisation der HW- bzw. SW-Produkte besonders zu betrachten. Sollten die erforderlichen Produkte nicht rechtzeitig vorliegen, sind Maßnahmen im Rahmen der Aktivität PM 4 "Feinplanung" zu bestimmen.

Erläuterung

Diese Aktivität sollte neben der Bereitstellung der Einsatzmittel die Überwachung ihrer Verfügbarkeit, die Gewährleistung von adäquater Einsatzunterstützung und die Steuerung des Austausches von Einsatzmitteln im Projekt beinhalten.

Dazu kommen auch Tätigkeiten zur Verwaltung der Software-Entwicklungsumgebung (SEU), die hier auszuführen sind, wie z. B.:

Nutzerverwaltung 17)

−	Verwaltung von Nutzerberechtigungen

−	Nutzergruppen-Zuordnung/-Verwaltung

−	Vergabe von Nutzerarbeitsbereichen (Work-Directories)

−	Vergabe von Zugriffsrechten auf die SEU

Einsatzmittelverwaltung

−	Sammeln/Auswerten von Abrechnungsinformationen

−	Überwachung der System-/Netzauslastung

−	Modifikation der SEU-Konfiguration

−	allgemeine Datensicherung (über die KM-spezifische hinaus)

−	Zuordnung von SEU-Ressourcen zu Aufgaben

17)	Diese Aktivität ist hauptsächlich für Entscheidungen zuständig. Die eigentliche Durchführung erfolgt außerhalb der Aktivität PM 11 "Bereitstellung der Ressourcen".


PM 12: Vergabe von Arbeitsaufträgen
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 12	Vergabe von Arbeitsaufträgen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 1	akzeptiert		Projekthandbuch		—	—
PM 1 oder PM 4	in Bearb.		Projektplan		—	—
—	—		Arbeitsauftrag		SE, QS, KM, PM 8, PM 13	—
Abwicklung

Ziel dieser Aktivität ist die Veranlassung eines Arbeitsabschnitts  durch einen Arbeitsauftrag.

Für den Arbeitsauftrag sind folgende Angaben zusammenzustellen bzw. zu referenzieren:

−	Arbeitsanleitung (Auszug aus dem Projekthandbuch bzw. Verweis auf das Projekthandbuch über die durchzuführende(n) Aktivität(en) und zu erstellende(n) Produkt(e), anzuwendende Methode(n) und einzuhaltende Richtlinien),

−	Soll-Werte (Aufwand, Termin, Ressourcen) aus dem Projektplan,

−	Erläuterungen zur gestellten Aufgabe,

−	Kenndaten zu Kritikalität, Sicherheit, Produktstruktur und -umgebung,

−	relevante Vorschriften aus Projektplan und QS-Plan,

−	Abstimmnotwendigkeiten,

−	Ansprechpartner.

Empfehlung

Der Arbeitsauftrag sollte (vor allem bei großen Projekten) schriftlich vom Projektmanagement formuliert werden.

Erläuterung

Ein Arbeitsabschnitt  kann sowohl aus einzelnen SE-, QS- und KM-Aktivitäten als auch aus einem Bündel zusammengehöriger Aktivitäten bestehen. Zusammengehörige Aktivitäten sind beispielsweise die Aktivitäten zur Erstellung eines Produktes, wie die Systemarchitektur im Submodell SE, das Erstellen der zugehörigen Prüfdokumente im Submodell QS, das Prüfen der Systemarchitektur im Submodell QS und das Verwalten all dieser Produkte im Submodell KM.


PM 13: Einweisung der Mitarbeiter
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 13	Einweisung der Mitarbeiter

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 12	—		Arbeitsauftrag		—	—
Abwicklung

Ziel dieser Aktivität ist es, die einzelnen Bearbeiter mit ihrem Arbeitsabschnitt  vertraut zu machen, wobei Erläuterungen der Aufgabenstellung, Besprechungen und Abstimmungen notwendig sind. Das Projektmanagement hat in dieser Aktivität den erforderlichen Informationsstand über Interna und Externa des Projektes zu vermitteln.


PM 14: Projektabschluß
Teil 1	Vorgehensmodell / Regelungsteil

7	Regelungen Submodell Projektmanagement

7.2	Die Aktivitäten des Submodells PM

PM 14	Projektabschluß

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PM 4	in Bearb.		Projektplan		—	—
KM 4	akzeptiert		Projekthistorie		—	—
SE, QS, KM, PM	—		Berichtsdokumente		—	—
—	—		Projektabschlußbericht		Extern *)	—
*)	Auftraggeber

Abwicklung

Ziel dieser Aktivität ist es, den Abschluß eines Projekts durchzuführen.

Dazu ist vom Projektmanagement ein Projektabschlußbericht zu verfassen, welcher eine Gesamtschau über den Verlauf des Projektes enthält, die erzielten Ergebnisse erläutert sowie den Ist-Stand abschließend dem Projektplan gegenüberstellt. Als Informationsquellen bieten sich die einzelnen Sachstandsberichte, die Projekthistorie und der Projektplan an.

Erläuterung

Die Auswertung der Projekthistorie dient dazu, Erfahrungswerte zu ermitteln, Problembereiche des Teams und der Entwicklung zu lokalisieren, Auswirkungen von Mängeln zu analysieren, Entscheidungen zu evaluieren und ähnliches. So werden Erfahrungswerte und Erkenntnisse über den Entwicklungsgang gewonnen, die in nachfolgenden Projekten berücksichtigt werden sollten.


Allgemeine Erläuterungen
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.1	Allgemeine Erläuterungen

Das V-Modell regelt die IT-Systementwicklung durch die einheitliche und verbindliche Vorgabe von Aktivitäten und Produkten (Ergebnissen), die bei der Systemerstellung (SE) und den begleitenden Tätigkeiten für Qualitätssicherung (QS), Konfigurationsmanagement (KM) und technisches Projektmanagement (PM) anfallen.

Im vorliegenden Kapitel werden Erläuterungen zu den Produkten des V-Modells gegeben.

Die Produkte sind im V-Modell durch Vorgabe verbindlicher Gliederungen geregelt. Da die Kapitelüberschriften aber nicht in jedem Falle selbsterklärend sind, werden im vorliegenden Kapitel Hinweise gegeben, welche Inhalte jeweils erwartet werden. Diese erläuternden Texte zu den Kapiteln haben jedoch keinen verbindlichen Regelungscharakter.

Die Gliederungen der einzelnen Produkte sind anhand von Strukturierungsschemata vorgegeben. Eine genaue Beachtung der Feingliederung läßt sich bei Verwendung von Werkzeugen zur Produktgenerierung nicht immer garantieren. In diesem Fall muß die Feinstrukturierung der betroffenen Produkte von Fall zu Fall ausdrücklich vereinbart werden. Dabei ist die Abdeckung der erforderlichen Inhalte nachzuweisen.

Zur besseren optischen Kennzeichnung wurden die Produktüberschriften mit einem Rahmen versehen.


Kapitelnumerierung mit Präfix
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.1	Allgemeine Erläuterungen

8.1.1	Kapitelnumerierung mit Präfix

Aus Gründen der Übersichtlichkeit wurde im folgenden eine Kapitelnumerierung verwendet, bei der jeweils ein Produkt-Präfix der Kapitelnummer vorangestellt ist (z. B. SysArc_2.2). Ohne dieses Präfix würde hier eine Kapitelnummer ihre Eindeutigkeit verlieren, weil sie − über alle Produkte gesehen − mehrfach verwendet würde (es gäbe dann viele Kapitel mit der Nummer 2.2).

Die Verwendung eines Präfixes hat nur Erläuterungscharakter und dient nur als Orientierungshilfe in diesem Kapitel!

Für die Projektdokumente ist die Verwendung eines Präfixes nicht geregelt.


Seitenlayout
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.1	Allgemeine Erläuterungen

8.1.2	Seitenlayout

Jede Seite eines Projektdokuments hat an geeigneter Stelle (z. B. am oberen Rand) folgende dokumentbezogene Daten aufzuweisen:

−	Dokumentbezeichnung,

−	Dokumentidentifikation mit Versionsangabe,

−	VS-Einstufung (falls zutreffend).


Gliederungspunkt "1 Allgemeines"
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.1	Allgemeine Erläuterungen

8.1.3	Gliederungspunkt "1 Allgemeines"

Alle Produkte, mit Ausnahme der Berichtsdokumente und der Änderungsformulare, haben als Vorspann einen Gliederungspunkt "1 Allgemeines" 18). Neben den Informationen zu Identifikation, Prüfung und Verteilung des jeweiligen Produkts werden hierunter alle allgemeinen (d. h. vom Zweck und Inhalt des Produkts zunächst unabhängigen) Gliederungspunkte verstanden. Insbesondere bei umfangreichen und einem Änderungsprozeß unterliegenden Entwicklungsdokumenten sind unter "Allgemeines" die unten aufgeführten Angaben, Verzeichnisse und Übersichten aufzunehmen:

18)	Der Gliederungspunkt "1 Allgemeines" wird in den nachfolgenden Erläuterungen zu den Produkten nicht für jedes Produkt wiederholt. Deshalb beginnen die Kapitelnumerierungen mit dem Kapitel 2.

Gliederungspunkt "1 Allgemeines":

−	Deckblatt
Das Deckblatt enthält folgende Informationen:

•	Produktbezeichnung und -identifikation,

•	Version,

•	VS-Einstufung,

•	Projektidentifikation,

•	Ort und Datum der Erstellung und letzten Änderung,

•	Bearbeiter,

•	Datum und verantwortliche Personen der Prüfung und Freigabe.

Falls das Produkt im Rahmen eines Auftragnehmer-Verhältnisses erstellt wurde, sind zusätzlich folgende Angaben erforderlich:

•	Auftraggeber,

•	Auftragsnummer,

•	Vertragsdaten.

Falls Unterauftragnehmer bei der Erstellung beteiligt waren, sind diese ebenfalls aufzuführen.

•	Verteilerliste
Nach Möglichkeit sollten die Gründe der Verteilung angegeben werden (Bearbeitung, Kenntnisnahme, Prüfung, Genehmigung, Weiterleitung, Ablage, usw.).

−	Kurzbeschreibung

−	Verzeichnisse

•	Inhaltsverzeichnis,

•	Abkürzungen,

•	Definitionen,

•	Abbildungen und Tabellen,

•	Referenzierte Dokumente
Dieser Abschnitt führt alle für die Bearbeitung und das Verständnis des Produktes erforderlichen Dokumente an. Über die referenzierten Dokumente sind folgende Informationen zu halten: Bezeichnung, Identifikation mit Versionsangabe und Art der Verwendung (z. B. Quelle, Standard, weiterführende Literatur, usw.).

−	Änderungsübersicht

Die Änderungsübersicht gibt zur vorliegenden Version des Produktes für jede, seit der letzten Ausgabe geänderte Stelle das Änderungsdatum und den Änderungsgrund an. Eventuell sind auch hier mehrere Blätter notwendig (Formblätter). Bei Bedarf sind lokal begrenzte Änderungen im Dokumenttext (z. B. durch einen Änderungsbalken am Rand) zu kennzeichnen.


Anwenderforderungen (AFo_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.1	Anwenderforderungen (AFo_)

Die Anwenderforderungen beschreiben die fachliche Sicht auf das System. Diese Sicht ist in bezug auf die Einsatzumgebung zu formulieren. Die Anwenderforderungen sind Grundlage der Abnahme  des Systems durch den Auftraggeber.

Die Anwenderforderungen enthalten die Dokumentation der Ist-Aufnahme und Ist-Analyse sowie der Bedrohungs- und Risikoanalyse, die Dokumentation von IT-Sicherheitsziel und IT-Sicherheitsmaßnahmen, die Festlegung der fachlichen Anforderungen und der Randbedingungen.

Um Anforderungen zu kennzeichnen, muß ein Formalismus eingeführt werden, der es erlaubt, jede Anforderung eindeutig zu identifizieren, damit eine eindeutige Referenzierung aus den Architektur- und Entwurfsdokumenten heraus möglich ist (Quittierungs-Prinzip).

Bei der Formulierung der Anforderungen ist darauf zu achten, daß nur das "WAS" einer gestellten Aufgabe zu beschreiben ist und nicht das "WIE". Weiterhin ist zu beachten, daß Anforderungen prüfbar, eindeutig, widerspruchsfrei und frei von versteckten Entwurfsentscheidungen sein sollen.

Der Begriff "System" umfaßt im folgenden auch den Begriff "Verfahren".

AFo_2  Ist-Aufnahme und Ist-Analyse

Dieser Punkt wird relevant, wenn

−	bereits ein System dieser Art existiert und durch ein neues ersetzt werden soll (im Ausnahmefall auch für umfangreiche SWPÄ-Maßnahmen) oder

−	das zu entwickelnde System in existierende ablauforganisatorische oder technische Gegebenheiten eingebunden werden soll.

Gegebenenfalls wird auf der Basis des Ist-Zustandes die organisatorische und technische Einsatzumgebung soweit beschrieben, wie es zur Dokumentation der Schwachstellen des jetzigen Systems notwendig ist.

Im einzelnen sind im Rahmen der Ist-Aufnahme und Ist-Analyse beispielsweise folgende Punkte relevant:

−	Erfassen der Anwender-/Nutzerumwelt (Aufbau- und Ablauforganisation, Dienstvorschriften, Erlasse, Gesetze, Richtlinien und ähnliches mehr)

−	Aufnehmen existierender Datenbestände, Programme

−	Erfassen der vorhandenen IT-Ausrüstung

−	Erfassen von Zeit- und Mengengerüst (derzeitige Bearbeitungszeiten, Durchlaufzeiten, Antwortzeiten, Wartezeiten, Datenmengen)

−	Erfassen nicht beeinflußbarer fachlicher und technischer Faktoren

−	Darstellen der Bedrohung und der Ausrüstungslücke,

−	Feststellen von Schwachstellen

−	Ermitteln der Ursachen der festgestellten Schwachstellen

AFo_3  IT-Sicherheitsziel

In diesem Kapitel wird gegebenenfalls vorgegeben, welche Anforderungen an Verfügbarkeit, Integrität oder Vertraulichkeit von bestimmten Funktionen oder Informationen bestehen.

AFo_4  Bedrohungs- und Risikoanalyse

Die für das System relevanten Bedrohungen sind zu ermitteln und die damit verbundenen Risiken unter Berücksichtigung von Eintrittswahrscheinlichkeiten und zu erwartenden Schäden zu bewerten.

AFo_5  IT-Sicherheit

Die IT-Sicherheit eines Systems wird gewährleistet durch Maßnahmen in der Umgebung des Systems (Zutrittsicherung, Sicherung gegen Abstrahlung, sichere Handhabung von Datenträgern, usw.) oder durch Maßnahmen im System selbst (Paßwortschutz, Mitlaufen von Protokollen, usw.).

In den Anforderungen an die IT-Sicherheit wird festgelegt, welche Wirkung von der Gesamtheit solcher Maßnahmen erwartet wird. Die Bedrohungen aus der Bedrohungs- und Risikoanalyse müssen den Anforderungen zugeordnet werden. Es muß klargestellt sein, daß die Maßnahmen zur IT-Sicherheit den Bedrohungen entgegenwirken.

AFo_6  Fachliche Anforderungen

AFo_6.1  Grobe Systembeschreibung

Die grobe Systembeschreibung hat hier in der Form eines Gesamthorizonts insbesondere folgenden Kriterien zu genügen:

−	Es muß klar werden, welche fachlichen Aufgaben durch das System unterstützt werden sollen. Daher muß die Einordnung des Systems in die Organisation bzw. sein Integrationsumfeld beschrieben werden.

−	Sie muß erkennbar machen, welche Gesamtfunktionalität im Endausbau abgedeckt werden soll und welche Prioritäten dabei im weiteren Verlauf erwartet werden.

−	Sie muß das Einsatzkonzept soweit beeinhalten, daß daraus die technische und organisatorische Einsatzumgebung und die Randbedingungen (im Rahmen von SE 1.4 "Randbedingungen definieren") ableitbar sind.

−	Sie muß quantitative Abschätzungen enthalten, die es ermöglichen, grundsätzliche technische Entscheidungen in der richtigen Größenordnung zu treffen (Netzauslegung, Rechnerkapazitäten, usw.)

−	Sie muß so präzise erfolgen, daß im weiteren Verlauf jederzeit entscheidbar ist, wann dieser Gesamthorizont verlassen wird und dementsprechend technische Entscheidungen neu überdacht werden müssen.

−	Die Verwendung vordefinierter fachlicher Bausteine (Standardthemenbereiche) ist zu berücksichtigen. Mögliche Kandidaten zur Wiederverwendung auf der Ebene der Anwenderforderungen im Rahmen der beabsichtigten Entwicklung sind zu benennen.

AFo_6.2  Organisatorische Einbettung

Dieses Kapitel enthält eine Beschreibung des organisatorischen Einsatzbereiches des Systems: die Aufbau- und Ablauforganisation beim Anwender, Nutzerklassen, Verantwortlichkeiten und Zuständigkeiten beim Einsatz sowie die weitere Ausrüstung des Anwenders.

AFo_6.3  Nutzung

Hier sind Anforderungen an die Bedienung und Nutzung des Systems festzuhalten, wie z. B. an mobilen oder stationären Einsatz, Einsatzzeiten, an die Kommunikation von Nutzer und System, an den Umfang der vom System automatisch bereitzustellenden Dienste, usw.

AFo_6.4  Kritikalität des Systems

Die Kritikalität des Systems wird festgelegt (evtl. auch definiert) und auf der Basis der Kritikalitätsdefinition im QS-Plan begründet.

AFo_6.5  Externe Schnittstellen

Anforderungen an die externen Systemschnittstellen zu Nachbarsystemen und im speziellen an die Mensch-Maschine-Schnittstelle sind zu formulieren.

Anforderungen hinsichtlich der Ergonomie sind hier zu berücksichtigen. Die technische Ausgestaltung der Nutzeroberfläche wird im Rahmen der Technischen Anforderungen definiert.

AFo_6.6  Beschreibung der Funktionalität

Dieses Kapitel nimmt die fachliche Strukturierung der Funktionalität des Systems aus Anwendersicht auf:

−	Die Funktionalität des Systems wird unter Berücksichtigung der vom System zu erfüllenden Aufgabe beschrieben.

−	Zur Festlegung der geforderten Systemfunktionalität werden Geschäftsprozesse definiert. Diese sind ganzheitlich, d. h. vollständig zu betrachten, auch wenn das geforderte System nur Ausschnitte davon unterstützt. Die Nutzer werden zum integralen Teil der Beschreibung. Das System wird zusammen mit seiner Umgebung (Mensch, verbundene Systeme) als Ganzes gesehen.

−	Es erfolgt eine fachliche Strukturierung der Funktionalität in Bereiche. Diese Strukturierung dient

•	als Basis für die Entscheidung über eine Verwendung bereits an anderer Stelle vordefinierter Bereiche (Standardthemenbereiche),

•	als Grundlage der Abgrenzung von Systemteilen zur Erarbeitung und Untersuchung von Lösungsvorschlägen,

•	als Anhaltspunkt für die Vergabe von Entwicklungsaufträgen,

•	als Grundlage für eine stufenweise (inkrementelle) Entwicklungsstrategie für die schnelle Verfügbarkeit operationell einsetzbarer Systeme (durch frühe Rückkopplungen aus dem Einsatz kann das Entwicklungsrisiko deutlich vermindert werden),

•	als Planungsgrundlage und Leitfaden für den schrittweisen Ausbau des Systems,

•	als Eingangsinformation für die Gestaltung oder Optimierung der Organisation beim Anwender.

Beispiele für Standardthemenbereiche sind

•	Mailing und Kommunikation,

•	Daten- und Dokumentenhaltung,

•	IT-Sicherheit,

•	Mensch-Maschine-Schnittstelle (wie Lagedarstellung, Meldungserstellung und -verarbeitung),

•	Bürofunktionen.

−	Im Rahmen der Beschreibung der Funktionalität werden Kritikalitätseinstufungen vorgenommen. Die Kritikalitätsstufenzuordnung erfolgt auf die Bereiche und die darunter liegenden Strukturelemente.

−	Der Informationsbedarf des Anwenders ist klar, aber unabhängig von technischen Vorgaben zu definieren. Gegebenenfalls erfolgt hier auch die Beschreibung der Daten, soweit sie auf dieser Ebene schon bekannt sind.

Anmerkungen:

−	Die Ordnung der fachlichen Anforderungen an die Funktionalität wird nicht über die geforderte Bereichseinteilung hinaus als Regelungselement vorgegeben. Die fachliche Ordnung ist jedoch immer unabhängig von der technischen Architektur zu beschreiben.

−	Wesentliches Element der fachlichen Beschreibung ist die Bezugnahme auf gegebenenfalls vordefinierte Bereiche.

−	Werden als Folge der Ist-Aufnahme und Ist-Analyse parallel zur Systementwicklung Aufbau- und Ablauforganisation beim Anwender optimiert, ist für Informationssysteme bei der Vorgabe der angestrebten Geschäftsprozesse und bei der fachlichen Strukturierung des Systems in Bereiche unbedingt auf die Ergebnisse dieser Optimierungen zurückzugreifen.

−	Entwicklungen auf dem Gebiet der Informationstechnik können zu neuen Einsatzfeldern mit entsprechendem Einfluß auf die Organisationsgestaltung führen. Umgekehrt stellen Aufbau- und Ablauforganisation primäre Randbedingungen für eine Unterstützung durch IT-Systeme dar. Organisationsentwicklung und Systemerstellung stehen deshalb in enger Wechselwirkung zueinander. Sie sind folglich eng aufeinander abzustimmen.

AFo_6.7  Qualitätsforderungen

Es werden Anforderungen hinsichtlich der Qualitätsmerkmale

−	Zuverlässigkeit,

−	Nutzerfreundlichkeit,

−	Effizienz,

−	Wartbarkeit,

−	Übertragbarkeit,

−	Wiederverwendbarkeit,

−	statische und dynamische Leistungsdaten, usw.

formuliert. Basis ist die DIN ISO 9126.

AFo_7  Randbedingungen

AFo_7.1  Technische Randbedingungen

Auf der Basis einer Betrachtung der technischen Einsatzumgebung können z. B. Randbedingungen hinsichtlich folgender Punkte fixiert werden:

−	Technische Anforderungen an Schnittstellen,

−	Vorgaben für die technische Realisierung von Schnittstellen,

−	Hinweise und Vorgaben für den technischen Ablauf,

−	Vorgabe von Fertigprodukten,

−	Einhaltung von technischen Standards,

−	Vorgaben aus der technischen Entwicklungs-, SWPÄ- oder Einsatzumgebung.

Zusätzlich können hier auch technische Anforderungen an die Umgebung vermerkt werden (z. B. für Hardware: erforderliche Klimatisierung, Vibrationsdämpfung, usw.).

AFo_7.2  Organisatorische Randbedingungen

Auf der Basis einer Betrachtung der organisatorischen Einsatzumgebung können z. B. Randbedingungen hinsichtlich folgender Punkte fixiert werden:

−	Verteilung fachlicher Aufgaben (Funktionen) innerhalb der Aufbauorganisation,

−	Bedarf an Kommunikation, Kooperation und Koordinierung zwischen Stellen innerhalb der Ablauforganisation beim Anwender,

−	Informationsbedarf bei der Abwicklung von Geschäftsprozessen,

−	Ausführungsrhythmus und Wiederholfrequenz der Geschäftsprozesse,

−	geographische Verteilung der Anwender innerhalb des Einsatzgebietes,

−	Vorgaben aus der Organisationsentwicklung zum Personalstand, Stellenpläne, Arbeitsplatzbeschreibungen,

−	Vorgaben aus Personalgesetzgebung (Beamtengesetz, Betriebsverfassungsgesetz, Mitbestimmung, Tarifverträge),

−	Zusammenarbeit mit externen Dienststellen und Behörden (überbehördliche Kooperation, Amtshilfe),

−	Vergabe von fachlichen Aufgaben (Funktionen) an externe Auftragnehmer u. a. durch "Outsourcing".

AFo_7.3  Sonstige Randbedingungen

Randbedingungen, die weder technischer noch organisatorischer Natur sind, sind zu fixieren (z. B. zeitliche und wirtschaftliche Randbedingungen).


Systemarchitektur (SysArc_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.2	Systemarchitektur (SysArc_)

Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur, mit den Elementen der generischen Erzeugnisstruktur. Betrachtet werden dabei die Elemente der Erzeugnisstruktur bis einschließlich der SW-Einheiten/HW-Einheiten. Die Architekturen der SW-Einheiten und HW-Einheiten finden sich in den zugehörigen Architekturdokumenten.

Das Produkt "Systemarchitektur" enthält mögliche Lösungsvorschläge, Ergebnisse von Realisierbarkeitsuntersuchungen, das IT-Sicherheitskonzept, das IT-Sicherheitsmodell und die Zuordnung zwischen Anwenderforderungen und den Elementen der Systemarchitektur.

SysArc_2  Struktur des Systems

SysArc_2.1  Darstellung der technischen Systemarchitektur

SysArc_2.1.1  Technischer Aufbau des Systems

Das System wird als Netzwerk der Elemente der technischen Architektur dargestellt. Dabei werden die Möglichkeiten der generischen Erzeugnisstruktur möglichst eingesetzt, um SW-Einheiten/HW-Einheiten geeignet zu Segmenten und diese zu Systemen zusammenzufassen. Die Bestandteile der Architektur werden auf der Basis der Angaben aus dem KM-Plan eindeutig gekennzeichnet und verbindlich identifiziert. Die Architektur muß in der Aufzählung ihrer Elemente vollständig und konsistent sein.

Die Teile des Systems, die durch Fertigprodukte realisiert werden sollen, oder in denen Fertigprodukte eingesetzt werden sollen, sind festzulegen.

Beim Entwurf der Systemarchitektur ist zu beachten, daß sich die technische Struktur eines IT-Systems und die Organisation beim Anwender in der Regel gegenseitig beeinflussen. Die Anwenderorganisation ist bei den Überlegungen zur Systemarchitektur einerseits als wichtiger Einflußfaktor für mögliche Lösungsansätze heranzuziehen. Bei IT-Systemen mit Client-Server-Architektur sind andererseits in der Anwenderorganisation gegebenenfalls Kapazitäten für System- und Nutzerbetreuung vor Ort vorzusehen. Bei diesen Überlegungen ist darüberhinaus auch die Verteilung neuer Systemversionen und -varianten während der Nutzung zu bedenken und organisatorisch zu regeln. Dabei sind sowohl technische als auch wirtschaftliche Aspekte zu berücksichtigen.

SysArc_2.1.2  Identifikation der Schnittstellen

Aus der Architektur ergibt sich die Identifikation der Schnittstellen, die hier tabellarisch eindeutig mit der Nennung der jeweiligen Partner geschieht. Die Schnittstellen werden im Rahmen des technischen Entwurfs festgelegt. Hier werden die systeminternen wie die systemexternen Schnittstellen identifiziert. Hier werden technische Schnittstellen identifiziert, die im allgemeinen nicht deckungsgleich mit fachlichen Schnittstellen sind.

SysArc_2.1.3  Anforderungszuordnung

In Tabellenform werden die Bezüge zwischen den Elementen der Systemarchitektur (Segmente und SW-Einheiten/HW-Einheiten) und den im Produkt "Anwenderforderungen" enthaltenen Anforderungen (Schnittstellenanforderungen, funktionale Anforderungen, Qualitätsforderungen, etc.) und Randbedingungen hergestellt. Damit soll der Nachweis erbracht werden, daß alle gestellten Anforderungen und Randbedingungen durch die Elemente der Systemarchitektur adressiert werden.

Die Tabelle enthält

−	die Zuordnung der Anforderungen zu den Elementen der technischen Architektur und

−	Hinweise auf den technischen Ablauf.

Folgende Punkte sind dabei zu beachten:

−	Jede Forderung muß auf mindestens ein Element der technischen Architektur, im Idealfall auf genau ein Architekturelement, zugeordnet werden.

−	Jede Forderung wird auf das in der Detaillierungsschichtung niedrigste Element zugeordnet, das die Erfüllung der Forderung vollständig ermöglicht. Im Normalfall muß die Gesamtmenge der Forderungen auf verschiedene Detaillierungsschichten zugeordnet werden.

−	Sofern eine Forderung von Element-übergreifender Bedeutung ist, muß im Rahmen der Zuordnung genau abgewägt werden, welche einzelnen Architekturelemente diese Anforderung letztendlich zu erfüllen haben.

−	Die Zuordnung muß so erfolgen, daß durch die Prüfung des entsprechenden Architekturelements die Erfüllung der Forderung nachgewiesen werden kann.

Bei der Zuordnung von Anwenderforderungen zu Elementen können Hinweise auf die Vorgaben bzgl. des technischen Ablaufs gegeben werden. Dabei kann auf die technische Architektur Bezug genommen werden.

Bei der objektorientierten Entwicklung ist zu beachten: Die funktionalen Anwenderforderungen werden in Form von Anwendungsfällen, den "Use Cases" beschrieben. Diese Anwenderforderungen werden letztendlich in Klassenhierarchien und deren Zusammenwirken realisiert. Die Zuordnung der Anwenderforderungen kann daher bei der objektorientierten Entwicklung durch eine Zuordnung von "Use Cases" zu Gruppen von Klassen (-hierarchien) erfolgen, durch deren Zusammenwirken diese Anforderungen erfüllt werden können.

SysArc_2.2  Erläuterung der Zusammenarbeit der technischen Elemente

Hier werden die technischen Abläufe dargestellt, wie sie sich als Auswirkung der technischen Architekturentscheidungen ergeben. Dies geschieht ausschließlich auf der Basis der technischen Architektur. (In keinem Fall handelt es sich hier um eine Änderung oder inhaltliche Überschneidung zu den fachlichen Geschäftsprozessen.)

Zusätzlich ist hier gegebenenfalls die Rechner-übergreifende Prozeßkommunikation zu beschreiben, die später im Rahmen der SW-Architektur zu verfeinern ist.

Beispiele: Technischer Ablauf der Kommunikation der Nutzer über ein Client-Server-Netzwerk auf der Basis eines Novell-Netzwerks; technische Lösung für den Zugang ausgewählter Nutzer zum Internet; technische Unterstützung der Mitzeichnungswege über E-Mail usw.

SysArc_3  Realisierung

SysArc_3.1  Lösungsvorschläge

Lösungsvorschläge können frei gewählte Ausschnitte der Architektur betreffen. Sie sind weder auf eine Ebene der generischen Erzeugnisstruktur noch auf einzelne Elemente eines Systems zu beschränken.

Lösungsskizzen für die Struktur des Systems oder von Systemteilen beschreiben die Architekturidee und die Zerlegung des Systems oder Systemteils. Grundlage der Systemskizzen sind in jedem Fall die Anwenderforderungen.

Der mögliche Einsatz von Fertigprodukten ist bei der Erarbeitung der Lösungsvorschläge zu berücksichtigen.

SysArc_3.2  Realisierbarkeitsuntersuchungen

Die Lösungsvorschläge werden so bewertet, daß die Vor- und Nachteile in bezug auf die Realisierbarkeit dargestellt werden.

Die Ergebnisse der Marktsichtung hinsichtlich der Verfügbarkeit geeigneter Fertigprodukte sind zu dokumentieren.

Folgende Aspekte können im Rahmen der Realisierbarkeitsuntersuchung betrachtet werden:

−	Entwicklungsanforderungen (z. B. Einsatz von speziellen Programmiersprachen)

−	Berücksichtigung der besonderen Anforderungen an kritische Systemteile (insbesondere Verflechtung mit anderen Komponenten)

−	Auswirkungen der besonderen Ausstattung des Zielrechners

−	Auswirkungen des Einsatzes von Fertigprodukten (Bezug zum Forderungscontrolling)

−	Fehlerbehandlungskonzept

−	Synchronisations- und Kommunikationsmechanismen

−	notwendige Spezialentwicklungen

−	Ergebnisse von Benchmarks

Für den ausgewählten Lösungsvorschlag muß die Auswahlentscheidung nachvollziehbar dokumentiert werden.

SysArc_4  IT-Sicherheitskonzept

Dieses Kapitel beschreibt die IT-Sicherheitsstrategie und begründet auf dieser Basis die Maßnahmen im System selbst und in der Systemumgebung, die in ihrem Zusammenwirken die Anforderungen an die IT-Sicherheit  abdecken. Die Aufgaben der Maßnahmen und die Verantwortung bei ihrer Durchführung sind zu beschreiben. Die Wirksamkeit der Gesamtheit der Maßnahmen, ihre Verträglichkeit mit Vorschriften und Richtlinien, das Kosten-Nutzen-Verhältnis und das verbleibende Restrisiko sind zu begründen.

SysArc_5  IT-Sicherheitsmodell

Falls ein IT-Sicherheitsmodell gefordert ist, ist hier nachzuweisen, daß die IT-Sicherheitsanforderungen in sich konsistent sind und daß die Zielsetzungen des IT-Sicherheitskonzepts durch die modellierten IT-Sicherheitsfunktionen und deren externe Schnittstellen eingehalten werden.


Technische Anforderungen (TAnf_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.3	Technische Anforderungen (TAnf_)

In diesem Produkt werden technische Anforderungen an das Gesamtsystem, die Segmente sowie die SW-Einheiten/HW-Einheiten definiert. Zu diesen Elementen der Erzeugnisstruktur wird jeweils die Funktionalität dargestellt und es werden technische Anforderungen an die Schnittstellen, Qualitätsforderungen und technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung definiert. Technische Anforderungen, die keinem Element der Erzeugnisstruktur zugeordnet werden können, werden als allgemeine Anforderungen festgehalten.

TAnf_2  Allgemeine Anforderungen

Hier werden technische Anforderungen genannt, die keinem Element der technischen Architektur gesondert zugeordnet werden können.

TAnf_3  Technische Anforderungen an das Gesamtsystem

Gliederung: siehe unten

TAnf_4  Technische Anforderungen an Segmente

Gliederung je Segment: siehe unten

TAnf_5  Technische Anforderungen an SW-Einheiten/HW-Einheiten

Gliederung je SW-Einheit/HW-Einheit: siehe unten

Für jedes Element x (= Segment oder SW-Einheit/HW-Einheit) der Systemarchitektur sind die Technischen Anforderungen wie folgt zu spezifizieren:

TAnf_x.1  Identifikation des Elements

Das betrachtete Architekturelement wird anhand der im KM-Plan festgelegten Konventionen identifiziert, und die zugehörige Langbezeichnung wird angegeben.

TAnf_x.2  Gesamtfunktion des Elements

Die Funktionalität des Elements wird in ihrer Gesamtheit dargestellt; dabei ist auf die Aufgabe des Elements, auf Betriebsarten und Einsatzbereiche einzugehen.

TAnf_x.3  Technische Anforderungen an die Schnittstellen

TAnf_x.3.1  Technische Anforderungen an die Nutzerschnittstelle

Falls das betrachtete Element eine direkte Nutzerschnittstelle besitzt, wird hier deren technische Ausgestaltung beschrieben. Dazu können bei Softwareschnittstellen z. B. die Definition von Masken, Fenstern, Dialogabläufen gehören. Bei Hardwareschnittstellen sind dies z. B. Bedienelemente zur Einstellung, Parametrisierung und zur Werteeingabe. (Im Unterschied zu den Anwenderforderungen, wird hier nicht der Informationsbedarf, sondern die technische Umsetzung definiert.)

TAnf_x.3.2  Technische Anforderungen an andere Schnittstellen

Für die Schnittstellen des betrachteten Elements zu anderen Elementen werden die technischen Anforderungen festgelegt. Die Identifikation der Schnittstellen und die jeweiligen Partner ergeben sich aus der Systemarchitektur.

Der Detailgrad der hier geforderten Beschreibung muß so gewählt werden, daß sie Ausgangspunkt und Entscheidungsgrundlage für die weitere Entwicklung sein kann.

TAnf_x.4  Qualitätsforderungen

TAnf_x.4.1  Kritikalität

Die Kritikalität des gesamten Elements wird genannt und begründet. Die Kritikalitätseinstufung muß mit den Kritikalitätsangaben der zugeordneten Anwenderforderungen verträglich sein.

Tanf_x.4.2  Technische Anforderungen der IT-Sicherheit

Die im Rahmen der Anwenderforderungen definierten Anforderungen zur IT-Sicherheit werden in technische Anforderungen umgesetzt, die hier zu definieren sind. (Hierzu können z. B. gehören: die Forderung nach mechanischer Sicherung von Diskettenlaufwerken oder die Forderung nach softwaretechnischer Verhinderung eines neuen Bootvorgangs durch den Nutzer.)

TAnf_x.4.3  Technische Anforderungen an sonstige Qualitätsmerkmale

Hier werden Anforderungen definiert an

−	Zuverlässigkeit

−	Übertragbarkeit

−	Nutzerfreundlichkeit

−	Effizienz

−	Wartbarkeit

−	Wiederverwendbarkeit

−	statische und dynamische Leistungsdaten

−	Änderbarkeit usw.

Basis ist die DIN ISO 9126.

TAnf_x.5  Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung

Dieses Kapitel ist für das System als Ganzes und für eigenständig und getrennt zu entwickelnde Elemente notwendig.

Hier sind Anforderungen an Entwicklungs-, Integrations- und Prüfeinrichtungen, die während Entwicklung und SWPÄ  mit dem betrachteten Element der technischen Architektur in Verbindung stehen, zu beschreiben.

Zu definieren sind hier insbesondere Anforderungen an

−	Entwicklungsrechner-Ausstattung,

−	Zielrechner-Ausstattung,

−	Zielrechner-bezogene Werkzeuge und

−	Prüfeinrichtungen.

Anmerkungen:

−	Die Angaben der zu einem Segment gehörigen SW-Einheiten/HW-Einheiten können editorisch in einem Kapitel zusammengefaßt werden. Dadurch können Detaillierungsebenen deutlich gemacht werden.

−	Bei der Realisierungsbeauftragung einzelner technischer SW-Komponenten erhält der Realisierer immer die zum entsprechenden Element gehörigen Technischen Anforderungen sowie die relevante Menge der fachlichen Anforderungen.

Relevante fachliche Anforderungen an höhere Strukturebenen sind zu zerteilen, da sie nicht vollständig dem beauftragten Element zugeordnet werden können. Unklare Abgrenzungen zu anderen Teilen der Systemarchitektur müssen vermieden werden. Es darf insbesondere weder zu Überschneidungen (Gefahr der Doppelbeauftragung und unklarer Schnittstellen) oder Lücken in der Anforderungsabdeckung kommen.


Schnittstellenübersicht (SSÜb_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.4	Schnittstellenübersicht (SSÜb_)

Dieses Produkt enthält eine zusammenfassende Übersicht über alle Schnittstellen des Systems: externe Schnittstellen des Systems zu Elementen seiner Umgebung (Nutzer oder andere Systeme) und interne Schnittstellen des Systems zwischen Funktionseinheiten (Segmente, SW-Einheiten/HW-Einheiten, SW-Komponenten, SW-Modulen und Datenbanken).

SSÜb_2  Systemexterne Schnittstellen

Dieses Kapitel faßt alle Schnittstellen des Systems zu seiner Umgebung zusammen. In dieser Übersicht sind anzugeben

−	Identifikation der Schnittstelle,

−	beteiligte Elemente,

−	Verweis auf die Schnittstellenbeschreibung.

Eine übersichtliche Art der Darstellung ist eine Matrizenform.

Systemexterne Schnittstellen sind nicht nur auf der Ebene "System" zu externen Elementen wie Nutzern oder anderen Systemen zu dokumentieren, sondern es muß in dieser Übersicht auch deutlich gemacht werden, wie sich diese Art der Schnittstelle im System weitervererbt: wird sie von einem Segment wahrgenommen oder evtl. nur von einem einzigen SW-Modul?

SSÜb_3  Systeminterne Schnittstellen

Dieses Kapitel faßt alle Schnittstellen innerhalb des Systems zusammen, die nicht bereits in Kapitel 2 behandelt wurden. In dieser Übersicht sind anzugeben

−	Identifikation der Schnittstelle,

−	beteiligte Elemente (hier: Segmente, SW-Einheiten, HW-Einheiten, SW-Komponenten, SW-Module und Datenbanken),

−	Verweis auf die Schnittstellenbeschreibung.

Die Matrizenform ist auch hierfür eine geeignete Darstellungsweise. Um einer hohen Schnittstellenkomplexität in einem System zu begegnen, muß eine solche Matrix gegebenenfalls in Teil-Matrizen (z. B. Segment-, SW- oder HW-bezogen) aufgespalten werden.


Schnittstellenbeschreibung (SSB_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.5	Schnittstellenbeschreibung (SSB_)

Dieses Produkt enthält für jede in der Schnittstellenübersicht identifizierte Schnittstelle eine Beschreibung. Je Schnittstelle sind die Identifikation, die Syntax und die Semantik anzugeben. Welche genauen Inhalte jeweils zu beschreiben sind, hängt von der Art der Schnittstelle und den beteiligten Elementen ab.

Das Produkt nimmt außer den Schnittstellen auf SW-Komponenten-, SW-Modul- und Datenbankebene die Beschreibung aller Schnittstellen des Systems auf, wobei grundsätzlich die Möglichkeit besteht, das Produkt nach gewissen Ordnungskriterien in mehrere Einzelprodukte aufzugliedern.

SSB_2  Beschreibung der Schnittstellen

Bei den einzelnen Unterpunkten ist auf die Spezifika der verschiedenartigen Schnittstellen zwischen den jeweils unterschiedlichen beteiligten Elementen System, Nutzer, Segment, SW-Einheit, HW-Einheit, SW-Komponente, SW-Modul oder Datenbank einzugehen.

SSB_2.s  Schnittstelle (s)

Hinweis: "s" wird verwendet für eine fortlaufende Numerierung der Schnittstellenbeschreibung von 2.1 bis 2.n und als Platzhalter für die Schnittstellenbezeichnung gemäß den im KM-Plan festgelegten Konventionen zur Identifikation.

SSB_2.s.1  Verwendung der Schnittstelle

Die an der Schnittstelle beteiligten Elemente (Funktionseinheiten, Nutzer, externe Elemente) und der Zweck der Schnittstelle sind anzugeben.

SSB_2.s.2  Syntax der Schnittstelle

Hier ist der technische Aufbau der Schnittstelle exakt zu beschreiben. Je nach Art der Schnittstelle sind anzugeben:

−	Funktionsaufruf und Parameterleiste,

−	Übertragungsrichtung,

−	Kommunikationsprotokoll,

−	Synchronisationsmechanismus,

−	Layout einer Nutzerschnittstelle, usw.

SSB_2.s.3  Semantik der Schnittstelle

Hier ist anzugeben, welche Informationen und Operationen über die Schnittstelle ausgetauscht werden, wie die Schnittstelle angesiedelt ist und wie sie sich aus Sicht des Systems darstellt.

SSB_2.s.4  Besonderheiten

Je nach Art der Schnittstelle ist hier auf spezielle Eigenschaften wie Leistungsdaten oder Zeitbedingungen einzugehen, sind Hinweise zur Benutzung und Bedienung anzugeben, usw.


Integrationsplan (IntPl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.6	Integrationsplan (IntPl_)

Der Integrationsplan enthält Vorschriften für den Zusammenbau des Systems, des Segments oder der SW-Einheiten bzw. HW-Einheiten aus technischer Sicht.

Der Plan identifiziert die Integrationsprodukte gleichzeitig als Prüfgegenstände und ist in dieser Hinsicht mit dem Prüfplan konsistent zu halten. Technische Voraussetzungen und Einschränkungen sind ebenso wie die Organisation der Integration zu erläutern. Die einzelnen Integrationsmaßnahmen werden detailliert beschrieben.

Der Integrationsplan behandelt die Ebenen System, Segment und SW-Einheit bzw. HW-Einheit. Welche evtl. Zerlegung des Integrationsplans gewählt wird, hängt letztendlich von Projektstandards, dem Umfang und der Komplexität der einzelnen Integrationsebenen ab.

IntPl_2  Integrationsprodukte und -strategien

Anhand der hierarchischen Zuordnung (Segmente; SW-Einheiten/HW-Einheiten; SW-Komponenten, SW-Module und Datenbanken) und dem logischen Zusammenhang (ersichtlich aus den Architekturdokumenten) wird der Zusammenbau der Integrationsprodukte pro Integrationsschritt festgelegt. Für jeden Integrationsschritt wird neben den Produkten auch die Integrationsstrategie definiert.

IntPl_3  Integrationsrandbedingungen

IntPl_3.1  Integrations-/Prüfumgebung

Dieses Kapitel nennt die für die Integration benötigte Umgebung. Ihre SW-Komponenten sind Teile des Entwicklungs- und Zielrechners und der Prüfumgebung, daher können die jeweiligen Passagen aus den Technischen Anforderungen und den Prüfplänen an dieser Stelle zitiert oder referenziert werden.

IntPl_3.2  Prioritäten

Aus technischen Gesichtspunkten (logischer Zusammenhang der Integrationsprodukte) ergibt sich die Reihenfolge des Zusammenbaus. Jedem Integrationsschritt wird eine Priorität zugeordnet.

IntPl_3.3  Risiken

Ist ein spezieller Integrationsschritt risikoreich, so müssen Hinweise auf eventuelle Probleme und Gegenmaßnahmen aufgeführt werden (z. B. Gefahren für die Hardware beim Zusammenwirken mit fehlerhafter Software, wenn keine Schutzmaßnahmen vorgesehen sind).

IntPl_3.4  Sonstige Randbedingungen

Hier werden bei Bedarf weitere Voraussetzungen und Einschränkungen aufgeführt (z. B. Verfügbarkeit der Integrationseinrichtungen).

IntPl_4  Organisation der Integration

Die Durchführung der Integration ist anhand der vorher aufgeführten Integrationsschritte und
-randbedingungen zu planen.

IntPl_4.1  Integrations-Netzplan

Die Integrationsschritte werden nach Strategien, Prioritäten, Risiken und anderen Randbedingungen in eine zeitliche Reihenfolge gebracht.

IntPl_4.2  Personal

Die Organisationseinheiten, die an der Integration teilnehmen (SE, QS, KM, PM), werden namentlich genannt.

IntPl_4.3  Verantwortlichkeiten

Den Organisationseinheiten/Instanzen werden im Rahmen der Integration Verantwortlichkeiten zugedacht (Überwachung des Zeitplans, Durchführung bestimmter Integrationsschritte, Qualitätssicherungsmaßnahmen, usw.).

IntPl_5  Integrationsmaßnahmen

IntPl_5.1  Erforderliche Produkte

Die zur Durchführung der Integrationsmaßnahmen notwendigen Produkte werden aufgeführt.

IntPl_5.2  Integrationsanleitung

Aufbauend auf den Integrationsstrategien und -randbedingungen ist die technische Anleitung zu erstellen. Dazu zählen Prozeduren zum Zusammenbau der Produkte und Bedienungsanleitungen der Integrationseinrichtungen.

IntPl_5.3  Spezielle Hantierungen

Besondere Maßnahmen (z. B. bedingt durch den Aufbau von Geräten, An-/Abschaltprozeduren) werden erläutert.


SWPÄ-Konzept (SWPÄK_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.7	SWPÄ-Konzept (SWPÄK_)

Im SWPÄ-Konzept werden Regelungen getroffen, wie das System in die Nutzung übergeleitet werden kann, welche organisatorischen Maßnahmen für die spätere SWPÄ zu treffen sind und welche Ressourcen erforderlich sind.

SWPÄK_2  Rahmenbedingungen

SWPÄK_2.1  Vorbemerkungen

Hier wird angegeben, welchen Geltungsbereich das SWPÄ-Konzept besitzt, welche Einsatzbedingungen es berücksichtigt und wie die Fortschreibung geregelt wird.

SWPÄK_2.2  Bezugsdokumente

Hier werden die Bezugsdokumente für das SWPÄ-Konzept aufgeführt.

SWPÄK_2.3  Begriffsbestimmungen

Hier sind die Begriffe zu definieren, die vom SWPÄ-Konzept neu eingeführt werden und für das Verständnis des Produkts wesentlich sind.

SWPÄK_2.4  Vorgaben für die SWPÄ-Organisation

Hier werden Rahmenbedingungen hinsichtlich Personal, Ausbildung, Organisation, Infrastruktur, Logistik und Programmiersprachen festgeschrieben. Auf bestehende logistische Verfahren ist hinzuweisen.

SWPÄK_3  Systembeschreibung

Allgemeine Faktoren wie Einsatzort, Zeitpunkt/-spanne und Inbetriebnahme sind zu beschreiben.

Besondere Merkmale hinsichtlich

−	Anforderungen an die Verfügbarkeit,

−	Sicherheits- und Zuverlässigkeitskriterien,

−	Interoperabilität und

−	Abhängigkeiten von anderen Systemen

sind anzugeben.

SWPÄK_4  Bewertung hinsichtlich SWPÄ

Für die einzelnen Bestandteile des Systems ist anzugeben, ob SWPÄ durchzuführen ist/erforderlich werden könnte bzw. ob keine SWPÄ notwendig ist. Die Verantwortung für die SWPÄ ist jeweils den betroffenen Organisationen (z. B. Behörde, Industrie) zuzuordnen. Besondere Merkmale der Systembestandteile mit ihren Auswirkungen auf die SWPÄ sind anzugeben (z. B. Qualität der SW, Programmiersprachen, Dokumentation, Anwendung von Standards).

SWPÄK_5  SWPÄ-Organisation

Hier erfolgt die Beschreibung der SWPÄ-Organisation. Es wird geklärt, wie sich das SWPÄ-Team zusammensetzt (aus welchen Stellen, Instanzen), wie sich Aufgaben und Verantwortlichkeiten auf diese verteilen und welche Schnittstellen zu beachten sind.

SWPÄK_5.1  Aufbauorganisation

Hier werden die Stellen genannt, die Tätigkeiten im Rahmen der SWPÄ durchführen.

SWPÄK_5.2  Aufgaben und Verantwortlichkeiten

Hier werden Aufgaben und Verantwortlichkeiten der beteiligten Stellen festgeschrieben.

SWPÄK_5.3  Schnittstellen

Kommunikationsschnittstellen mit firmeninternen und firmenexternen Stellen (Auftraggeber, Unterauftragnehmer, Partner, Gremien und Ausschüsse, Zulassungsstellen) werden hier festgelegt. Dokumentiert wird, wer welche Art und Form von Information (technisch oder administrativ, schriftlich oder mündlich) wann (fester Termin, periodisch, ereignisbedingt) von wem erhält bzw. an wen weitergibt.

SWPÄK_6  SWPÄ-Prozeß

Der Prozeß zur Durchführung der SWPÄ (z. B. Beantragung, Analyse und Klassifikation von Änderungen, Bewertung von Änderungen, Konfigurationsverwaltung, Verteilung von Datenträgern und Installation) ist zu beschreiben. Insbesondere ist die Vorgehensweise bezüglich Fertigprodukten festzulegen.

SWPÄK_7  Ressourcen

Die erforderlichen personellen und technischen Ressourcen werden aufgeführt.

SWPÄK_7.1  Personal

Der für die SWPÄ erforderliche Personalbedarf wird bestimmt. Es ist anzugeben, inwieweit der Personalbedarf aus dem eigenen Bereich gedeckt werden kann oder ob die Durchführung von SWPÄ-Maßnahmen an externe Auftragnehmer vergeben werden soll. Die erforderlichen Kenntnisse sind jeweils anzugeben.

SWPÄK_7.2  Technische Voraussetzungen

Es sind Anforderungen an die für die Durchführung der SWPÄ-Maßnahmen notwendigen technischen Voraussetzungen zu definieren. Hierzu zählen

−	erforderliche Entwicklungsdokumentation,

−	Entwicklungs- und Prüfumgebung,

−	Infrastruktur,

−	IT-Sicherheit (z. B. Schlüsselgeräte, Abstrahlsicherheit) und

−	Logistik.

SWPÄK_8  Herstellung der SWPÄ-Bereitschaft

Die Herstellung der SWPÄ-Bereitschaft ist zu planen. Hierzu zählen u. a.

−	Schaffung der personellen und technischen Voraussetzungen,

−	Ausbildung und

−	entwicklungsbegleitende Maßnahmen (z. B. um im Rahmen der Systementwicklung die notwendige Qualifikation für die Durchführung von SWPÄ-Maßnahmen in der Nutzung zu erwerben).

SWPÄK_9  Überleitung in die Nutzung

Hier wird dokumentiert, wie das System an die SWPÄ-Organisation übergehen soll. Dabei werden berücksichtigt:

−	Zeitplanung,

−	Beteiligte,

−	Verfahren zur Überführung,

−	Datenbestände.


SW-Produkte
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.8	SW-Produkte

Unter den SW-Produkten werden die SW-Architektur, der SW-Entwurf, der Datenkatalog und die Implementierungsdokumente zusammengefaßt.


SW-Architektur (SwArc_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.8	SW-Produkte

8.2.8.1	SW-Architektur (SwArc_)

In der SW-Architektur (Grobentwurf) werden Vorschläge für mögliche SW-Architekturen und die ausgewählte Dekomposition der SW-Einheit angegeben: dynamisch in einzelne Prozesse, statisch in SW-Komponenten, SW-Module und Datenbanken. Die Zusammenhänge zwischen Prozessen, SW-Komponenten, SW-Modulen und Datenbanken werden dargestellt. Ferner werden die externen und internen Schnittstellen der SW-Einheit identifiziert und abschließend die Zuordnung zu den Anforderungen hergestellt.

Für jede SW-Einheit existiert ein solches Produkt.

SwArc_2  Lösungsvorschläge

Dieses Kapitel nimmt eine Beschreibung und anschließende Bewertung möglicher Architekturen der SW-Einheit auf.

Lösungsvorschläge für die Architektur der SW-Einheit werden skizziert. Sie beschreiben auf grobem Niveau die Zerlegung der SW-Einheit in Prozesse sowie in SW-Komponenten, SW-Module und Datenbanken.

Für jeden Lösungsvorschlag werden einzeln die Vor- und Nachteile (z. B. bzgl. Schnittstellenkomplexität, Verwendbarkeit von Fertigprodukten, usw.) und die Realisierbarkeit dargestellt. Die Auswahl eines Lösungsvorschlags wird dokumentiert und begründet.

SwArc_3  Modularisierung/Datenbankentwurf

Die Modularisierung gibt die statische Zerlegung einer SW-Einheit in SW-Komponenten und SW-Module sowie die realzeitspezifischen Zusammenhänge an. Ferner enthält dieses Kapitel einen Grobentwurf der Datenbanken (falls vorhanden) der SW-Einheit.

SwArc_3.1  Übersicht der SW-Komponenten, SW-Module, Prozesse und Datenbanken

Alle SW-Module, Prozesse, SW-Komponenten und Datenbanken werden mit ihren Identifikatoren und einer Langbezeichnung aufgelistet. Daneben sollte ergänzend eine grafische Darstellung (Baum) gewählt werden, aus der die "Besteht-aus"-Hierarchie deutlich wird.

SwArc_3.2  Einzelbeschreibungen

SwArc_3.2.m  SW-Komponente/SW-Modul/Prozeß/Datenbank (m)

Die SW-Komponente/das SW-Modul/der Prozeß/die Datenbank wird durch eine Leistungsbeschreibung (Zweck und Funktion) und die in Anspruch genommenen Ressourcen (CPU, Speicher, Peripherie, Prozessoren) definiert.

Sofern relevant, erfolgt hier ferner die Zuordnung der SW-Komponente/des SW-Moduls zum realisierenden Prozess.

Hinweis: "m" wird verwendet für eine fortlaufende Numerierung der Einzelbeschreibungen von 3.2.1 bis 3.2.n und als Platzhalter für den Bezeichner der SW-Komponente, des SW-Moduls, des Prozesses oder der Datenbank gemäß den im KM-Plan festgelegten Konventionen zur Identifikation.

SwArc_3.3  Dynamisches Ablaufmodell

Dieses Kapitel beschreibt die dynamischen Zusammenhänge von Prozessen. Zur Darstellung eignen sich vorwiegend grafische Methoden.

Weiter enthält dieses Kapitel die von der Laufzeitumgebung bereitgestellten und bei der Realisierung der Prozesse angewandten Mechanismen und Konzepte.

SwArc_3.4  Kritikalität der SW-Komponenten/SW-Module/Prozesse/Datenbanken

In Tabellenform wird jeder SW-Komponente/jedem SW-Modul/jedem Prozeß/jeder Datenbank eine Kritikalitätsstufe zugeordnet. Die Kritikalitätsstufe leitet sich aus der Kritikalität der Funktion ab, die die SW-Komponente/das SW-Modul/der Prozeß/die Datenbank realisiert.

SwArc_3.5  Sonstige Entwurfsentscheidungen

In diesem Kapitel werden sonstige Entwurfsentscheidungen, soweit sie obenstehend noch nicht genannt wurden, erläutert.

SwArc_4  Schnittstellen

Die aus den "Technischen Anforderungen" und der "Systemarchitektur" resultierenden externen Schnittstellen der SW-Einheit und die sich aus der Struktur der SW-Einheit ergebenden internen Schnittstellen werden identifiziert und den SW-Komponenten, SW-Modulen und Datenbanken zugeordnet.

Dieses Kapitel wird in das Produkt "Schnittstellenübersicht" übernommen.

SwArc_4.1  Externe Schnittstellen der SW-Einheit

Externe Schnittstellen sind Schnittstellen der SW-Einheit zu seiner Umgebung, d. h. zu anderen SW-Einheiten oder HW-Einheiten und zum Nutzer.

SwArc_4.2  Interne Schnittstellen der SW-Einheit

Interne Schnittstellen der SW-Einheit sind Schnittstellen zwischen SW-Komponenten, SW-Modulen und Datenbanken.

SwArc_5  Anforderungszuordnung

Die Bezüge zu den Technischen Anforderungen werden hergestellt. Es ist zu dokumentieren, ob alle Anforderungen an die betreffende SW-Einheit abgedeckt werden und wie die Anforderungen auf Prozesse/SW-Komponenten/SW-Module/Datenbanken heruntergebrochen wurden.

Folgende Punkte sind bei der Anforderungszuordnung zu beachten:

−	Jede Anforderung wird auf das in der Detaillierungsschichtung niedrigste Element zugeordnet, das die Erfüllung der Anforderung komplett ermöglicht.

−	Jede Anforderung muß auf mindestens ein Element, im Idealfall auf genau ein Architekturelement zugeordnet werden.

−	Sofern eine Anforderung von element-übergreifender Bedeutung ist, muß im Rahmen der Zuordnung genau abgewägt werden, welche einzelnen Architekturelemente diese Anforderung letztendlich zu erfüllen haben.

−	Die Zuordnung muß so erfolgen, daß durch die Prüfung des entsprechenden Elements die Erfüllung der Anforderung nachgewiesen werden kann.


SW-Entwurf (SwEnt_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.8	SW-Produkte

8.2.8.2	SW-Entwurf (SwEnt_)

Nach der Festlegung der Architektur der SW-Einheit beschreibt dieses Produkt den Feinentwurf einer SW-Komponente, eines SW-Moduls oder einer Datenbank. Dokumentiert werden ferner Ergebnisse von Betriebsmittel- und Zeitbedarfsanalysen.

Im Fall einer SW-Komponente/eines SW-Moduls wird bis zur Ebene einer Programmiervorgabe aufgezeigt, wie welche Funktionen und Daten durch die SW-Komponente oder das SW-Modul realisiert sind, sowie welche Daten und Dienste über die Schnittstellen ausgetauscht werden. Die Realisierung der Daten wird in das Produkt "Datenkatalog" eingebracht. Im Falle einer Datenbank wird diese vollständig bis zur Schemadefinition beschrieben.

Für jedes SW-Modul, jede SW-Komponente und jede Datenbank (jeder SW-Einheit jedes Segments im System) existiert ein solches Produkt.

Es ist möglich, mehrere SW-Entwürfe zu einem Produkt "SW-Entwurf" zusammenzufassen.

  Kapitel 2 für den Fall: Entwurf einer SW-Komponente oder eines SW-Moduls

SwEnt_2  SW-Komponenten-/SW-Modul-Beschreibung

Jede einzelne SW-Komponente und jedes SW-Modul wird hier in seiner Realisierung bis auf die Ebene einer Programmiervorgabe detailliert beschrieben.

SwEnt_2.1  Charakterisierung der Aufgabe

Die Aufgabe, die realisierte Funktion und der Zweck der SW-Komponente/des SW-Moduls werden beschrieben.

SwEnt_2.2  Umgebung

Die Umgebung der zu beschreibenden SW-Komponente bzw. des SW-Moduls und seine Dekomposition in SW-Komponenten und/oder SW-Module werden beschrieben.

SwEnt_2.3  Schnittstellen

SwEnt_2.3.1  Passiv-Aktiv-Aufrufmatrix

Die Passiv-Aktiv-Aufrufmatrix, die einen Überblick über die Einbettung gibt, dokumentiert die Beziehungen:

−	Aufruf von (anderen SW-Komponenten, anderen SW-Modulen) und

−	aufgerufen von (übergeordneter SW-Komponente oder SW-Einheit).

Zur Verdeutlichung kann neben der verbalen Darstellung eine Grafik mit aufgenommen werden.

SwEnt_2.3.2  Eingabe-/Ausgabedaten

Zu den Ein- und Ausgabedaten ist neben der Syntax und Semantik auch anzugeben, inwieweit die SW-Komponente/das SW-Modul auf fehlerhafte Daten reagiert: welche Eingabe- und Ausgabedaten werden worauf abgeprüft und wie wird im Falle einer Nicht-Übereinstimmung reagiert?

SwEnt_2.3.3  Weitere Schnittstellen

Hier sind die Prozeßschnittstellen und die Schnittstellen zu SW-Komponenten außerhalb der operativen Software (z. B. zum Betriebs- oder Laufzeitsystem) zu beschreiben.

SwEnt_2.4  Realisierung der SW-Komponente/des SW-Moduls

Es wird der Kontroll- und Datenfluß der SW-Komponente/des SW-Moduls als Programmiervorgabe dargestellt.

Die SW-Komponente/das SW-Modul ist vollständig zu beschreiben: Algorithmen für den Normal- und Ausnahme-/Fehlerfall, Initialisierungs- und Finalisierungsschritte, Pre- und Postconditions, Verarbeitung globaler Daten und Zustände, usw.

Die Realisierung der Daten (Datentyp, -format, Location) wird in das Produkt "Datenkatalog" übernommen.

SwEnt_2.5  Lokale Daten

Hier werden die modulinternen lokalen Daten hinsichtlich Typ, Format, Vorbelegung, Wertebereich, Inhalt, Zweck und Zugriffsart, usw. beschrieben.

SwEnt_2.6  Ausnahmeverhalten

Algorithmen zur Erkennung von Fehlersituationen, zur Behebung und zum definierten Beenden werden beschrieben.

  Kapitel 2 für den Fall: Entwurf einer Datenbank

SwEnt_2  Datenbankbeschreibung

Im Falle des Feinentwurfs einer Datenbank ist statt der SW-Komponenten-/SW-Modul-Beschreibung dieses Kapitel auszufüllen.

SwEnt_2.1  DBMS-Name

Das verwendete Datenbankmanagementsystem wird an dieser Stelle genannt.

SwEnt_2.2  Schemadefinition

Der Feinentwurf ist bis auf die Datenelementebene festzulegen. Dies bedeutet

−	bei Dateisystemen:
Festlegung der Satzaufbauten und der darin enthaltenen Datenelemente,

−	bei hierarchischen Datenbanken:
Festlegung der Segmente, der enthaltenen Datenelemente und der Segmenthierarchien,

−	bei relationalen Datenbanken:
Festlegung der Tabellen, gegebenenfalls von Views, der enthaltenen Datenelemente, von Fremdschlüsseln und Integritätsbedingungen.

Die Realisierung der Daten (Datentyp, -format, Adresse) wird in das Produkt "Datenkatalog" übernommen.

  Kapitel 3 ist relevant für den Entwurf einer SW-Komponente/eines SW-Moduls/einer Datenbank:

SwEnt_3  Kenngrößen

Unter Kenngrößen werden u. a. folgende Themen behandelt:

−	Betriebsmittel- und Zeitbedarf,

−	Prioritäten und Ablauffolge,

−	Genauigkeiten in der Bearbeitung,

−	maximale, minimale und wahrscheinliche Häufigkeit von Signalen.


Datenkatalog (DatK_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.8	SW-Produkte

8.2.8.3	Datenkatalog (DatK_)

Dieses Produkt enthält alle Informationen über die in SW-Einheiten benutzten Daten (Einzeldaten und komplexere Gebilde). Es kann manuell − besser jedoch durch ein Werkzeug unterstützt − erstellt werden. Die Informationen werden durch die Aktivität KM 4.1 "Daten administrieren" erfaßt und verwaltet.

Die Eingangsinformation für den Datenkatalog liefern die SW-Architektur und der SW-Entwurf. Im Datenkatalog sind die Bezeichner, die Eigenschaften und Attribute der Datenstrukturen und deren Elemente (Datenbeschreibung) festzuhalten. Wichtig sind ferner implementierungsabhängige Informationen (Datenrealisierung).

Für jedes Projekt existiert ein solches Produkt.

DatK_2  Datenbeschreibung

Die tabellarische Beschreibung enthält folgende Angaben:

−	Identifikator
Entsprechend den Konventionen der Programmiersprache und den Projektregeln zur Identifikation im KM-Plan gewählter eindeutiger Bezeichner der Datenelemente.

−	Bezeichnung in Langform
Die Langbezeichnung erklärt den Inhalt und die Verwendung der Datenelemente.

−	Beziehungen innerhalb eines Datenelements
Z. B. Gliederung in Record − Field − Item, identifizierender Schlüssel, usw.

−	Beziehungen zu anderen Datenelementen
Z. B. Redundanz, inhaltliche oder zeitliche Abhängigkeit

−	Physikalische Einheit und Normierung
Entscheidend für die Verarbeitung eines Datums ist dessen physikalische Einheit. Handelt es sich z. B. bei einer Temperaturangabe um Celsius, Fahrenheit oder Kelvin, bei einer Entfernungsangabe um Kilometer oder Meilen?

−	Verfeinerung
Es werden Bezeichner der Datenelemente angegeben, in die sich das (komplexe) Datum aufgliedert.

−	Definierende(s) SW-Komponente/SW-Modul
Ein Datenelement wird nur von einer SW-Komponente oder einem SW-Modul definiert. Der Bezeichner wird hier angegeben.

−	Referenzierende SW-Komponenten/SW-Module
Alle SW-Komponenten und SW-Module, die das Datenelement referenzieren (benutzen wollen), werden unter Angabe ihrer Bezeichner und der Referenzierungsart aufgeführt:

−	lesender Zugriff

−	schreibender Zugriff

−	Plausibilitäten/Integrität

−	Spezielle Eigenschaften und Attribute

DatK_3  Datenrealisierung

Folgende Angaben sind zu machen:

−	Datentyp und -länge
bei einfachen Daten: z. B. integer, real, char und Anzahl Stellen,
bei zusammengesetzten Daten: z. B. record, array und Beschreibung der einzelnen Felder analog den einfachen Daten.

−	Werte- und Definitionsbereich

−	Genauigkeit

−	Voreinstellung

−	Zugriff
Art des Zugriffs (z. B. sequentiell, indiziert) und identifizierender Schlüssel

−	Lebensdauer
Entstehungszeiten und -frequenzen

−	Speicherplatzbedarf
errechnet aus Datentyp und -format unter Beachtung der HW-Auslegung

−	Location
Falls Speicherplätze statisch zugewiesen sind, werden Angaben über Speicherplatzadressen den Cross-Referenz-Listen der Compiler und/oder Binder entnommen.
Es ist die Anfangslocation anzugeben, bei Teilen von Datenelementen die relative Location zum Anfang der Struktur. Ein Vermerk, daß es sich um eine relative Adresse handelt, ist notwendig.


Implementierungsdokumente (ImplD_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.9	Implementierungsdokumente (ImplD_)

Die Implementierungsdokumente enthalten Verweise auf den Code des SW-Moduls, der Datenbank, der SW-Komponente bzw. SW-Einheit sowie Kommandoprozeduren zur Code-Generierung, Installation, usw., ferner Verweise auf Listings und Protokolle von Übersetzer-, Binde- und Ladeläufen.

Für jede SW-Komponente, jedes SW-Modul, jede Datenbank (jeder SW-Einheit) und jede SW-Einheit (jedes Segments im System) existiert ein solches Produkt.

Es ist möglich, mehrere Implementierungsdokumente zu einem Dokument zusammenzufassen, beispielsweise für eine SW-Einheit.

ImplD_2  Code

Es werden Verweise angegeben, wo sich die Dateien (Datenträger) befinden und wie sie benannt sind (Hinweise hierzu im Produkt "KM-Plan" Gliederungspunkt "Konventionen zur Identifikation").

ImplD_2.1  Quellcode

Der Quellcode selbst wird aus dem Produkt "SW-Entwurf" hergeleitet. Der Text besteht aus Programmkopf und Anweisungsteil.

Der Programmkopf enthält folgende Informationen:

−	SW-Modul- bzw. SW-Komponentenname

−	Dateiname

−	Version und Variante

−	Bearbeiter/Datum

−	Projektbezeichnung

−	Kurzbeschreibung, evtl. Schlüsselbegriffe für die Wiederverwendbarkeit

−	Programmiersprache

−	Aufrufbefehl, gegebenenfalls mit Parameterliste

−	Eingabedaten

−	Ausgabedaten

−	Globale Daten

−	Lokale Daten

−	Konstanten

−	aufrufende SW-Komponente(n)

−	aufgerufene SW-Komponente(n)/SW-Modul(e)/Datenbank(en)

−	Kenngrößen

−	zugehörige andere Produkte, z. B. einkopierte Dateien mit Datendefinitionen,
Standardroutinen

−	Anmerkungen

Der Anweisungsteil besteht aus Statements mit Kommentaren.

ImplD_2.2  Verweis auf Objektcode

Es werden Referenzen zu Dateien und Datenträgern angegeben.

ImplD_2.3  Verweis auf ausführbaren Code

Es werden Referenzen zu Dateien und Datenträgern angegeben.

ImplD_3  Prozeduren

Diese sollten neben dem Anweisungsteil einen aussagekräftigen Prozedurkopf mit folgenden Angaben enthalten:

−	Prozedurname

−	Dateiname

−	Version und Variante

−	Identifikation des Werkzeugs (Compiler, Binder, usw.), genaue Bezeichnung, Hersteller- und Versionsangabe

−	Bearbeiter/Datum

−	Projektbezeichnung

−	Aufrufbefehl, gegebenenfalls mit Parameterliste

−	Kurzbeschreibung in Kommentarform

ImplD_3.1  Compileprozedur

ImplD_3.2  Bindeprozedur

ImplD_3.3  Ladeprozedur

ImplD_3.4  Installationsprozedur

ImplD_4  Listen/Protokolle

Es werden gegebenenfalls Referenzen zu Dateien und Datenträgern angegeben.

ImplD_4.1  Compiler-Protokoll

ImplD_4.2  Binder-Protokoll

ImplD_4.3  Lade-Protokoll

ImplD_4.4  Cross-Referenz-Listen

ImplD_4.5  Sonstige Generierungslisten


Betriebsinformationen
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.10	Betriebsinformationen

Unter den Betriebsinformationen werden die Informationen zum Anwendungshandbuch, die Informationen zum Diagnosehandbuch, die Informationen zum Betriebshandbuch und Sonstige Einsatzinformationen zusammengefaßt.


Informationen zum Anwendungshandbuch (AHb_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.10	Betriebsinformationen

8.2.10.1	Informationen zum Anwendungshandbuch (AHb_)

Die Informationen zum Anwendungshandbuch beinhalten alle Angaben, die der Anwender eines Systems benötigt, um das System ordnungsgemäß bedienen und im Falle von Problemen richtig reagieren zu können. Über jede einzelne Funktion werden hier detaillierte Ausführungen erwartet, die die Anforderungen verschieden geübter Nutzer erfüllen.

AHb_2  Anwenderfunktionen

Hier ist eine Übersicht anzugeben.

AHb_2.f  Funktion (f)

Hinweis: "f" wird verwendet für eine fortlaufende Numerierung der Anwenderfunktionen von 2.1 bis 2.n und als Platzhalter für den Funktionsbezeichner gemäß den im KM-Plan festgelegten Konventionen zur Identifikation.

AHb_2.f.1  Aufgabe

Anhand einer Kurzbeschreibung wird die Aufgabe der Funktion zur Erfüllung des Gesamtauftrags identifiziert.

AHb_2.f.2  Instruktionen zu Anwendung und Betrieb

Anwendung bedeutet nicht nur Bedienung durch Personal (Nutzerschnittstellen) sondern auch durch andere Systeme, Segmente, SW-Einheiten oder HW-Einheiten. Auf folgende Anwendungsschritte ist bei der Beschreibung näher einzugehen:

−	Initialisierung

Hierunter fallen Maßnahmen zur Vorbereitung des Betriebs (notwendige Ausrüstung, Einschalten, Systemvorbereitungen, Versorgung mit Anfangsinformationen, usw.).

−	Durchführung

Hierunter fallen alle zur regulären Bedienung und Nutzung der Funktion erforderlichen Kennntisse:

•	Ausführungsoptionen

Sofern die Funktion unter verschiedenen Optionen betrieben werden kann, werden diese in Syntax und Semantik hier kurz beschrieben.

•	Nutzer-Eingabe

Zu jeder von der Funktion benötigten Information wird angegeben, wie sie zugeführt werden muß (Bedienung der externen Schnittstellen).

•	Ausführung

Informationen, wie z. B. Zeitdauer, Signale, Meldungen, die Indikatoren für eine ordnungsgemäße Verarbeitung sind, werden genannt. Bei Bedarf wird aufgeführt, welche Handgriffe und Dienstleistungen während einer Funktionsausführung zum Betrieb notwendig sind.

•	Erwartete Ausgabe

Zu jeder von der Funktion bei korrektem Betrieb gelieferten Information wird angegeben, wie sie abgenommen werden muß (Bedienung der externen Schnittstellen).

•	Beziehungen zu anderen Funktionen

−	Terminierung

Maßnahmen sowohl zum regulären Beenden als auch zur Unterbrechung einer Funktionsausführung werden beschrieben.

−	Restart

Maßnahmen zum bewußten Wiederanlauf werden beschrieben. Dazu sind eventuell Initialisierungsschritte notwendig.

−	Überwachungsverfahren

Methoden und Maßnahmen der Überwachung des Betriebs (Monitoring, Watchdog, usw.) werden beschrieben. Wichtig dabei ist die Bedienung der zugehörigen externen Schnittstellen.

AHb_2.f.3  Fehlerfall

Die Gesamtmenge der möglichen Fehlersituationen bei einer Funktionsausführung ist zu beschreiben; dabei ist auf folgende Punkte näher einzugehen:

−	Fehlermeldungen

Meldungen an den Nutzer werden aufgelistet und dem Inhalt und Zusammenhang nach möglichst ausführlich erläutert.

−	Fehlerdiagnosemöglichkeiten

Zu den möglichen Fehlern werden die − möglichst eng eingegrenzten − Ursachen (Fehlbedienung, falsche Informationen, defektes Gerät, usw.) angegeben und die zur Verfügung stehenden Möglichkeiten zum Finden einer Ursache werden aufgeführt (z. B. Werkzeuge). An dieser Stelle sind Verweise auf das Diagnosehandbuch aufzunehmen.

−	Fehlerbehebungsmaßnahmen

Es werden Maßnahmen angegeben, die einen aufgetretenen Fehler wieder rückgängig machen (Rückstufung, Versorgung mit korrekter Information, Hardware-Austausch, usw.).

−	Recovery-Verfahren

Bei schwerwiegenden Betriebsstörungen ist unter Umständen ein besonderes Verfahren zum Wiederanlauf notwendig. Das Verfahren ist exakt zu beschreiben (Umschaltung auf Notbetrieb, anderer Kanal bei redundantem Aufbau, Rückführung zu definiertem Informationsstand, usw.). Im Gegensatz zu einem gewollten Restart steht hier die zwingend notwendige weitere Funktionserfüllung im Vordergrund.


Informationen zum Diagnosehandbuch (DiagHb_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.10	Betriebsinformationen

8.2.10.2	Informationen zum Diagnosehandbuch (DiagHb_)

Die Informationen zum Diagnosehandbuch beinhalten die Angaben, die zu SWPÄ- und Diagnoseaktivitäten am System benötigt werden. Die Funktion des Systems und die Diagnoseumgebung werden beschrieben, sodann wird auf jede einzelne Diagnose-Möglichkeit und Fehlermeldung eingegangen.

DiagHb_2  Funktion des zu wartenden Systems

Die Gesamtfunktion wird im Hinblick auf SWPÄ-Arbeiten beschrieben. Quellen sind die Beschreibungen aus den Entwicklungsdokumenten.

DiagHb_3  Diagnoseumgebung

DiagHb_3.1  Benötigte Software-Werkzeuge

DiagHb_3.2  Benötigte Rechner und Geräte

DiagHb_3.3  Sonstige Einrichtungen und Hilfsmittel

DiagHb_3.4  Bereitstellung der Umgebung

Es wird beschrieben, wie die genannten Software-Werkzeuge, Rechner, Geräte und Einrichtungen zur Diagnoseumgebung zusammengestellt werden. Dabei sind die Schnittstellen zum System (oder zu Teilen davon) zu berücksichtigen. Gegebenenfalls sind Referenzen auf die einschlägigen Handbücher anzugeben.

DiagHb_3.5  Betrieb der Umgebung

Hinweise zum allgemeinen Betrieb der Umgebung (Ressourcen, Datenträger, allgemeine Bedienung von Geräten und Werkzeugen, usw.) werden angegeben. Hierzu zählt noch nicht die Durchführung der eigentlichen Diagnoseaktivitäten.

DiagHb_4  Diagnose

DiagHb_4.1  Diagnose-Möglichkeiten

In übersichtlicher Form ist anzugeben, welche Situationen, Fehler und Mängel mit welchem Werkzeug diagnostizierbar sind. Es ist auf der anderen Seite klarzustellen, in welchen Fällen eine Diagnose nicht möglich bzw. wenig erfolgreich ist.

DiagHb_4.2  Diagnose-Werkzeuge

Handelt es sich um eine größere Anzahl an Diagnose-Werkzeugen, so sind diese hier in einer Übersicht zusammenzustellen.

DiagHb_4.2.w  Werkzeug (w)

Die einzelnen zur Verfügung stehenden Werkzeuge (Rechner, Testbench, Software, usw.) werden anhand ihrer Einsatzmöglichkeiten und -ziele beschrieben.

Hinweis: "w" wird verwendet für eine fortlaufende Numerierung der Diagnose-Werkzeuge von 4.2.1 bis 4.2.n und als Platzhalter für den Werkzeugbezeichner.

Für die Diagnose-Durchführung sind folgende Punkte zu beschreiben:

−	Werkzeugbedienung und Versorgung mit Eingabeinformationen wie Auswahl der Werkzeugfunktionen/-optionen

−	Bedienung des Prüfgegenstandes, Versorgung mit notwendigen Informationen, Abnahme der Ausgabeinformationen und Registrierung der Wirkungen auf die Umgebung

Für die Diagnose-Auswertung sind folgende Punkte zu beschreiben:

−	Menge der möglichen Diagnose-Ergebnisse und deren Auswertung

−	Erläuterungen und Hinweise zu weiteren Prüfmaßnahmen unter Berücksichtigung der Auswertungsergebnisse

−	Maßnahmen zur Behebung des so aufgedeckten Fehlers bzw. Problems

−	Auflistung von Ausfällen, die die Ausschaltung von bestimmten Sicherheitsfunktionen verursachen können

DiagHb_4.3  Fehler im laufenden Betrieb

In Ergänzung zum Anwendungshandbuch, wo Fehlermeldungen aus Sicht und zur Hilfestellung eines Anwenders beschrieben werden, werden im Diagnosehandbuch Fehlermeldungen zur Unterstützung von Systembetreuung detailliert und aus wartungstechnischer Sicht behandelt.

DiagHb_4.3.f  Fehlermeldung (f)

Der genaue Wortlaut der Fehlermeldung bzw. die Warn-/Fehlersignale an den Bediener sind in einer übersichtlichen Form aufzulisten.

(Hinweis: "f" wird verwendet für eine fortlaufende Numerierung der Fehlermeldungen von 4.3.1 bis 4.3.n und als Platzhalter für die Fehlerbezeichnung).

Zu jeder Fehlermeldung sind folgende Informationen aufzuführen:

−	Bedeutung und Zusammenhang

Möglichst eingrenzend wird beschrieben, wie der Fehler zustande kommt und welche Teile des Systems (bei der Software insbesondere Prozesse, SW-Komponenten, SW-Module, Datenbanken) nicht korrekt arbeiten.

−	Maßnahmen zur Behebung

Die notwendigen Maßnahmen zur Behebung von Fehlern/Problemen beinhalten:

•	Korrekte Bedienung des Systems, Gerätes, der Software,

•	Korrekte Versorgung mit notwendiger Information; korrekte Bedienung der Schnittstellen,

•	notwendige Reparaturarbeiten am System.

DiagHb_4.4  Verweis auf das Anwendungshandbuch

Bei Fehlern, die erfahrungsgemäß durch Fehlbedienungen entstehen, sind Verweise auf die entsprechenden Passagen im Anwendungshandbuch anzugeben.

DiagHb_5  Sonstiges, generelle Informationen

Hier werden weitere Informationen von Interesse aufgeführt. Wichtig sind insbesondere Hinweise zur Behandlung und Unterstützung von Fertigprodukten und zum Ablauf der SWPÄ (im Submodell KM).


Informationen zum Betriebshandbuch (BetrHb_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.10	Betriebsinformationen

8.2.10.3	Informationen zum Betriebshandbuch (BetrHb_)

Die Informationen zum Betriebshandbuch beschreiben für eine Funktionseinheit die erforderlichen Maßnahmen zur Aufnahme des Betriebs, zur Durchführung und Überwachung des Betriebs und zur Unterbrechung und Beendigung des Betriebs. Ferner sind der Aufbau der Funktionseinheit und Sicherheitsbestimmungen zu beschreiben.

BetrHb_2  Aufbau der Funktionseinheit

BetrHb_2.1  Technischer Aufbau

Der technische Aufbau der Funktionseinheit (System, Segment, HW-Einheit oder SW-Einheit) ist zu beschreiben; dies umfaßt neben der Architektur auch die technischen Daten.

BetrHb_2.2  Funktionszuordnung

Die Funktionszuordnung innerhalb der Funktionseinheit ist zu klären. Insbesondere interessiert hier die Beschreibung, welche Funktionen durch HW, welche durch SW realisiert werden.

BetrHb_3  Maßnahmen zur Aufnahme des Betriebs

BetrHb_3.1  Voraussetzungen

Dieses Kapitel beschreibt die Voraussetzungen zur Aufnahme bzw. Wiederaufnahme des Betriebs.

BetrHb_3.2  Initialisierung

Die Maßnahmen zur regulären Aufnahme des Betriebs sind zu nennen; dies umfaßt Systemvorbereitungen, Einschalten der Geräte, Laden der Software, Versorgung mit Anfangsinformationen, usw.

BetrHb_3.3  Wiederaufnahme des Betriebs

Die Maßnahmen zur Wiederaufnahme des Betriebs (nach einem Systemabsturz, Fehlerfall, usw.) sind zu nennen.

BetrHb_4  Maßnahmen zur Durchführung und Überwachung des Betriebs

BetrHb_4.1  Störmerkmale

Alle Merkmale, die einen Fehlerfall beschreiben oder auf eine Störung im System hindeuten, sind zu nennen. Detailliertere Informationen bzgl. der Fehlerlokalisierung und -behandlung finden sich im Anwendungshandbuch bzw. im Diagnosehandbuch, worauf gegebenenfalls zu verweisen ist.

BetrHb_4.2  Vermeidung von Fehlern

Maßnahmen, die dazu beitragen, Fehler zu umgehen, sind hier zu nennen. Ebenfalls ist auszuführen, welche Umgebungsbedingungen, Konstellationen, Aktionsfolgen, usw. vermieden werden sollten.

BetrHb_4.3  Behebung von Fehlern

Es sind Maßnahmen zur Lokalisierung von Fehlern und zur Behebung von Fehlern zu nennen. Für nähere Angaben ist auf das Diagnosehandbuch zu verweisen.

BetrHb_5  Maßnahmen zur Unterbrechung oder Beendigung des Betriebs

BetrHb_5.1  Voraussetzungen

Die Voraussetzungen sowohl für eine außerordentliche Unterbrechung des Betriebs als auch für die reguläre Beendigung des Betriebs sind zu nennen.

BetrHb_5.2  Unterbrechung des Betriebs

Die Maßnahmen zur Unterbrechung des Betriebs aufgrund besonderer Umstände sind zu nennen. Die hier beschriebenen Maßnahmen sollen gewährleisten, daß ohne große Schwierigkeiten eine Wiederaufnahme des Betriebs möglich ist.

BetrHb_5.3  Beendigung des Betriebs

Die Maßnahmen zur Beendigung des Betriebs sind in ihrer zeitlichen Abfolge zu nennen und zu beschreiben.

BetrHb_5.4  Nachbehandlung

Sind nach Beendigung des Betriebs noch Abschlußarbeiten erforderlich, so sind diese hier zu nennen. Dies kann z. B. die Behandlung von Datenträgern betreffen.

BetrHb_6  Sicherheitsbestimmungen

Dieses Kapitel beschreibt Bestimmungen und Maßnahmen zur Gewährleistung der erforderlichen Sicherheit. Diese umfassen die Bereiche Infrastruktur, Organisation und Personal, IT-Technik, Kommunikationstechnik und Abstrahlschutz sowie Katastrophenvorsorge und Versicherungen. Regelmäßige Überprüfungen der Einhaltung der Mechanismenstärke sind gegebenenfalls zu planen.


Sonstige Einsatzinformationen (EinInf_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.2	Produkte des Submodells SE

8.2.10	Betriebsinformationen

8.2.10.4	Sonstige Einsatzinformationen (EinInf_)

Unter Sonstige Einsatzinformationen werden alle diejenigen Informationen zusammengefaßt, die für den Betreiber im Rahmen der Übernahme, der Einführung und des Betriebs des Systems von Interesse sind. Aufgrund der Vielfältigkeit von Systemen und der unterschiedlichsten relevanten Themenbereiche wird hier keine allgemeingültige Produktstruktur festgelegt.

Im einzelnen können Themen wie

−	Ausbildung,

−	Besonderheiten der Installation und Konfigurationsmöglichkeiten,

−	Datenübernahme,

−	Einführungs- und Überleitungsstrategie,

−	Weiterentwicklungen,

−	Betriebsorganisation,

−	Logistik,

−	Infrastruktur,

−	usw.

betroffen sein.


QS-Plan (QPl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.3	Produkte des Submodells QS

8.3.1	QS-Plan (QPl_)

Der QS-Plan enthält die für ein Projekt gültigen generellen Festlegungen bezüglich der Prävention und der Nachweisführung (Arbeitsweisen, Hilfsmittel, Abläufe). Geplant werden konstruktive Maßnahmen zur Erreichung der Qualitätsziele, präventive Maßnahmen zur Vermeidung von Qualitätsrisiken und analytische Maßnahmen zum Nachweis der Erfüllung von Qualitätsforderungen.

QPl_2  Qualitätsziele und Risiken im Projekt

QPl_2.1  Qualitätsziele für Produkte und Prozesse

Die im Projektauftrag fixierten Projektziele sind aus Sicht der Qualitätssicherung zu beleuchten und entsprechend der Projektkriterien und -randbedingungen zu gewichten, so daß meßbare Qualitätsziele für das Projekt und seine Produkte definiert werden.

QPl_2.2  Qualitätsrisiken

Qualitätsrisiken, die bestehen, wenn die Projektziele und -kriterien unter den gegebenen Projektrandbedingungen zu erfüllen sind, sind hier aufzuführen, zu gewichten und zu analysieren.

QPl_2.3  Maßnahmen aufgrund der Qualitätsziele und -risiken

Hierunter fallen Maßnahmen, die für das Erreichen und die Kontrolle der Qualitätsziele sowie für das Vermeiden und die Korrektur von Qualitätsrisiken erforderlich sind.

QPl_3  QS-Maßnahmen gemäß Kritikalität und IT-Sicherheit

QPl_3.1  Verwendete Richtlinien oder Normen

Alle im Projekt relevanten Richtlinien und Normen betreffend die Kritikalität und die IT-Sicherheit sind hier zu nennen:

−	Definition von Kritikalität und ihrer Stufen

Es ist von der im V-Modell enthaltenen Festlegung auszugehen, die gegebenenfalls projektspezifisch konkretisiert werden soll. In Absprache mit dem Auftraggeber kann hier auch eine Definition aus geeigneten bestehenden Normen (z. B. /RTCA-178B/) gewählt werden; dabei sind u. U. bereits im Projekthandbuch getroffene Festlegungen zu berücksichtigen.

In den Anwenderforderungen wird die Kritikalität des Systems, der definierten Bereiche und der darunter liegenden Strukturelemente festgelegt. Die Kritikalitätseinstufung der Funktionseinheiten Segment und SW-Einheit bzw. HW-Einheit erfolgt in den Technischen Anforderungen. In der SW-Architektur erfolgt die Kritikalitätseinstufung für die Funktionseinheiten SW-Komponente und SW-Modul.

−	Definition IT-sicherheitsrelevanter Stufen, wie die Einstufung in Evaluierungsstufen und die Festlegung der benötigten Stärke von IT-Sicherheitsmechanismen

Dabei wird i. d. R. auf einen veröffentlichten Kriterienkatalog verwiesen und eine projektspezifische Interpretation der dortigen Regelungen vorgenommen.

QPl_3.2  Einstufungsbedingte QS-Maßnahmen

Dieses Kapitel nennt die aufgrund der Einstufungen der Kritikalität und IT-Sicherheit durchzuführenden Maßnahmen.

Bezüglich der Kritikalität erfolgt diese Festlegung mit Hilfe einer Kritikalitäten/Methoden-Matrix, welche aus zwei Teilmatrizen besteht: eine Matrix für konstruktive (Erstellungsvorgaben) und eine für analytische (Prüfvorgaben) QS-Methoden. Beispiele für diese beiden Matrizen finden sich im Teil 3 "Handbuchsammlung" des V-Modells (Handbuch "Sicherheit und Kritikalität").

In der Matrix für konstruktive QS-Methoden werden die für jede Kritikalitätsstufe vereinbarten konstruktiven QS-Methoden festgelegt. Nach den Vorgaben dieser Matrix sind die Aktivitäten des Submodells SE (in Sonderfällen auch der anderen Submodelle) auszuführen.

In der Matrix für analytische QS-Methoden werden die für jede Kritikalitätsstufe vereinbarten analytischen QS-Methoden festgelegt. Nach den Vorgaben dieser Matrix sind die von den Submodellen Systemerstellung, Qualitätssicherung, Konfigurationsmanagement und Projektmanagement erzeugten Produkte zu prüfen.

Abhängig von der IT-sicherheitsrelevanten Einstufung sind Anforderungen von QS-Seite zu erfüllen, welche dem zugrundeliegenden Kriterienkatalog entnommen werden können und bereits im Projekthandbuch angeführt sind. Diese Anforderungen und die dadurch bedingten QS-Maßnahmen werden projektspezifisch präzisiert.

QPl_4  Entwicklungsbegleitende Qualitätssicherung

QPl_4.1  Zu prüfende Produkte

Alle von QS zu prüfenden − generischen − Produkte sind aufzulisten.

QPl_4.2  Zu prüfende Aktivitäten

Es sind diejenigen − generischen − Aktivitäten aufzulisten, deren Konformität mit vorgeschriebenen Regeln (Standards, Richtlinien, Methoden) durch eine Prozeßprüfung nachzuweisen ist.

QPl_5  Spezifische Kontrollmaßnahmen

QPl_5.1  Eingangskontrolle von Fertigprodukten

Fertigprodukte sind bereits fertiggestellte Softwarepakete. Sie können sein:

a)	gekaufte Software, z. B. Bibliotheksprogramme, Testmonitor, Betriebssysteme, Compiler, Werkzeuge,

b)	verwendbare Software, die in der gleichen Firma, aber außerhalb des laufenden Projekts entwickelt wurde.

Hierbei ist nach dem geplanten Verwendungszweck zu unterscheiden in

−	Fertigprodukte, die in die Funktionalität des Systems eingehen und

−	Fertigprodukte, die für den Erstellungsprozeß genutzt werden.

Es sind in einem von der Verwendung der Software (z. B. Kritikalität) abhängigen Maßnahmenkatalog die einzelnen Kontrollen festzulegen. In jedem Fall ist wichtig:

−	Identifikation von Hersteller und Produkt muß sichergestellt sein.

−	Es ist zu prüfen, ob die Dokumentation entsprechend den Projektrichtlinien vorliegt.

−	Es ist zu klären, ob ausreichende Qualitätssicherungsmaßnahmen durchgeführt wurden bzw. in welchen Fällen Prüfungen durch QS nachzuholen sind.

Gegebenenfalls ist hier eine stichprobenartige Verwendungsprüfung (im Falle hoher Kritikalität aber ein kompletter QS-Zyklus) zu definieren.

QPl_5.2  Kontrolle von Unterauftragnehmern

Es ist festzulegen, welche Ausführungsrichtlinien für einen Unterauftragnehmer maßgebend sind. Durch solche Ausführungsrichtlinien sind

−	Umfang der Dokumentation und

−	Entwicklungsstandards

vorzuschreiben. Es sind ferner die Kontrollmaßnahmen für den Unterauftragnehmer festzulegen:

−	Begleitende Überprüfung der Entwicklung

−	Abnahmekontrollen für entwickelte Produkte

−	Vorgaben für die UAN-internen Prüfungen

QPl_5.3  Ausgangskontrolle der Softwarebausteine

Für die verschiedenen Arten der Auslieferung wird im Detail festgelegt, was bezüglich Dokumentation, Prüfungen und Abnahmekontrollen (ergänzend zu den projektbegleitenden Aktivitäten) zu tun ist.

QPl_5.4  Änderungskontrolle

Die QS-seitigen Vorgaben an das Verfahren der Änderungskontrolle und die QS-seitigen Überprüfungen dieses Verfahrens werden dargestellt. Das Änderungsmanagement selbst wird im Produkt "KM-Plan" festgelegt.

QPl_5.5  Kontrolle von Bearbeitungskompetenzen

Das Verfahren zur Kontrolle der Bearbeitungskompetenzen wird beschrieben. Dies betrifft insbesondere den Zugriff auf die Produktbibliothek. Die Zugriffsrechte selbst werden hingegen im Produkt "KM-Plan" festgelegt.

QPl_5.6  Kontrolle des Konfigurationsmanagements

Die im Konfigurationsmanagement angewendeten Verfahren sind zu kontollieren. Hierzu zählt auch die Überwachung der Ergebnissicherung und Archivierung.

Hinweis: Im KM-Plan werden die jeweiligen Vorgehensweisen z. B. der Ergebnissicherung und Archivierung beschrieben, hier im QS-Plan dagegen die zugehörigen Kontrollmaßnahmen, z. B. auf ordnungsgemäße Ergebnissicherung.


Prüfplan (PrPl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.3	Produkte des Submodells QS

8.3.2	Prüfplan (PrPl_)

Der Prüfplan definiert die Prüfgegenstände und die Aufgaben und Verantwortlichkeiten bei den Prüfungen, die zeitliche Planung sowie die für die Durchführung erforderlichen Ressourcen. Im Prüfplan ist festgelegt, welche Produkte und Aktivitäten in welchem Zustand wann, von wem und womit zu prüfen sind.

Orientiert an den Projektgegebenheiten wird entweder ein − für alle Prüfungen verbindlicher − Prüfplan erstellt, oder es erfolgt eine zweckmäßige Aufteilung in mehrere, physikalisch getrennte Prüfpläne, die jeweils Teilmengen der Prüfungen umfassen. Eine solche Aufteilung könnte beispielsweise anhand von Teilprojekten oder anhand der Bezugsprodukte (System, Segment, SW-Einheit/HW-Einheit) erfolgen.

PrPl_2  Prüfgegenstände und Qualifikationserfordernisse

Die jeweils einer Prüfung durch QS zu unterziehenden Prüfgegenstände werden in ihrer konkreten Ausprägung genannt und die jeweiligen Qualifikationserfordernisse beschrieben. Zu den Prüfgegenständen zählen:

−	Anwenderforderungen

−	Technische Anforderungen

−	Systemarchitektur

−	SW-Architektur

−	HW-Architektur

−	Schnittstellenübersicht

−	Schnittstellenbeschreibung

−	Integrationsplan

−	Betriebsinformationen (Informationen zum Anwendungshandbuch, Informationen zum Diagnosehandbuch, Informationen zum Betriebshandbuch und Sonstige Einsatzinformationen)

−	System (Prüfung des integrierten, ablauffähigen Produkts und der Schnittstellen zwischen Segmenten oder gegebenenfalls SW-Einheiten/HW-Einheiten und zur Systemumwelt)

−	Segment (Prüfung des integrierten, ablauffähigen Produkts und der Schnittstellen zwischen SW-Einheit und HW-Einheit und zum Nutzer)

−	SW-Einheit (Prüfung des integrierten, ablauffähigen Produkts und der Schnittstellen zwischen SW-Komponenten, SW-Modulen und Datenbanken)

−	HW-Einheit (Prüfung des integrierten, funktionsfähigen Produkts, der Schnittstellen und gegebenenfalls einzelner HW-Komponenten und HW-Module)

−	SW-Entwurf (zu jeder SW-Komponente, jedem SW-Modul, jeder Datenbank)

−	Datenkatalog

−	Implementierungsdokumente (zu jeder SW-Einheit, jeder SW-Komponente, jedem SW-Modul, jeder Datenbank)

−	SW-Komponente (Prüfung des integrierten, ablauffähigen Produkts und der Schnittstellen zwischen integrierten SW-Komponenten, SW-Modulen und Datenbanken)

−	SW-Modul

−	Datenbank

−	Zeichnungssatz

−	Realisierungsdokumente

Des weiteren kann es aufgrund strenger Qualifikationserfordernisse erforderlich sein, auch Prüfungen für folgende Prüfgegenstände festzulegen:

−	SWPÄ-Konzept

−	KM-Plan

−	Projekthandbuch

−	Projektplan

−	KID

−	Prüfplan, Prüfspezifikation und Prüfprozedur, sofern kritische Produktbedingungen vorliegen. Bei Prüfungen von QS-Produkten ist auf eine entsprechende Rollenverteilung zu achten.

Achtung: Es dürfen durch die Festlegung der Prüfgegenstände keine iterativen Prüfzyklen zustandekommen.

−	Weitere Produkte (soweit erforderlich)

−	Aktivitäten (als "Prüfgegenstände" für Aktivität QS 2 "Prüfungsvorbereitung")

Die Identifikation der Prüfgegenstände (System, Segmente, SW-Einheiten/HW-Einheiten, SW-Komponenten, SW-Module, Datenbanken und Dokumente) erfolgt gemäß den im KM-Plan festgelegten Konventionen.

Der Inhalt dieses Gliederungspunktes ist nicht redundant zum Punkt "zu prüfende Produkte" im QS-Plan. Dort werden die Produkte anhand ihrer neutralen Bezeichnungen, z. B. SW-Architektur, genannt; hier jedoch müssen sie projektspezifisch konkretisiert werden (z. B. SW-Entwurf zum SW-Modul "Logarithmusberechnung").

PrPl_3  Aufgaben und Verantwortlichkeiten

Zu jeder an der Prüfung beteiligten Organisationseinheit (benannt im QS-Plan) wird ihre Verantwortlichkeit in bezug auf die Prüfung kurz beschrieben. Es wird hier unterschieden zwischen ausführender, mitwirkender, beratender oder beaufsichtigender Beteiligung. Weiter werden die einzelnen Prüfungen auf Personen zugeordnet und diese namentlich genannt.

Im Falle von Prüfungen der Produkte SW-Einheit bzw. HW-Einheit, Segment und System hängt dieser Punkt eng mit dem entsprechenden Gliederungspunkt des Produkts "Integrationsplan" zusammen.

PrPl_4  Zeitplan

Der SW-Lebenszyklus mit seinen Baselines sowie die Randbedingungen der Entwicklung bestimmen die zeitliche Folge der Prüfungen. Hier sind die Termine für die Prüfungsvorbereitung und -durchführung der o. g. Prüfgegenstände und für die Vorbereitung von Durchführungsentscheidungen zu nennen.

Im Falle von Prüfungen der Produkte SW-Einheit bzw. HW-Einheit, Segment und System hängt dieser Punkt eng mit dem entsprechenden Gliederungspunkt des Produkts "Integrationsplan" zusammen.

PrPl_5  Ressourcen

PrPl_5.1  Prüfumgebung

Die zur Prüfung notwendige Prüfumgebung wird beschrieben. Existiert eine Prüfumgebung der geforderten Art bereits, so ist diese mit ihren HW-Bausteinen (Geräte, Analysatoren, Monitore, Testrigs, usw.) und SW-Bausteinen (Systemsoftware, Firmware, Simulatoren, Testdatengeneratoren, Testtreiber, Stubs, usw.) eindeutig zu identifizieren; andernfalls sind die Anforderungen an diese Umgebung zu definieren.

PrPl_5.2  Weitere Ressourcen

Die für die einzelnen Prüfungen außerdem benötigten Ressourcen (IT-Betriebsmittel, betriebliche Infrastruktur, Arbeitsmittel) sind zu nennen mit Detailangaben, wann und in welchem Umfang sie verfügbar sein müssen.


Prüfspezifikation (PrSpez_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.3	Produkte des Submodells QS

8.3.3	Prüfspezifikation (PrSpez_)

Die Prüfspezifikation enthält die Beschreibung von Prüfanforderungen und -zielen, Prüfmethoden, von den Anforderungen abgeleitete Prüfkriterien und die Prüffälle. Die Abdeckung der Anforderungen durch die Prüffälle wird durch eine Abdeckungsmatrix dokumentiert. Mit Hilfe der Prüfspezifikation muß entschieden werden können, ob die Prüfung erfolgreich war oder nicht.

Eine Prüfspezifikation wird für jeden Prüfgegenstand erstellt − vgl. Festlegung der "Prüfgegenstände" im Prüfplan.

Es ist möglich, mehrere Prüfspezifikationen zu einem Dokument zusammenzufassen.

PrSpez_2  Anforderungen

PrSpez_2.1  Einstufung der Funktionseinheit hinsichtlich Kritikalität und IT-Sicherheit

Die Einstufung der Funktionseinheit (System, Segment, SW-Einheit/HW-Einheit, SW-Komponente, SW-Modul, Datenbank) hinsichtlich Kritikalität  und IT-Sicherheit  ist in den Entwicklungsdokumenten definiert. Sie wird von dort übernommen.

PrSpez_2.2  Prüfanforderungen

Dieses Kapitel nimmt Anforderungen allgemeiner Art an eine Prüfung auf. Beispiele hierfür sind:

−	Prüfungen sind mit Normal-, Grenz- und fehlerhaften Werten durchzuführen.

−	Prüfungen sind unter Normal- und Ausnahmebedingungen (Höchstleistungen, Komponentenausfall, usw.) durchzuführen.

−	Prüfungen sind mit Echtdaten durchzuführen.

−	Möglichst alle Ausführungsoptionen und fehlerhafte Nutzereingaben sind abzuprüfen.

PrSpez_3  Methoden der Prüfung

Eine Prüfung unterteilt sich in die Abschnitte Vorbereitung, Durchführung und Auswertung. Werden die Vorbereitung und die Auswertung in der Prüfprozedur ausreichend beschrieben, so können sie hier entfallen.

Die Vorbereitung einer Prüfung umfaßt z. B. die Generierung von Testdaten. Die Methoden und Vorgehensweisen hierfür werden festgelegt und, sofern nicht als bekannt voraussetzbar, beschrieben.

Methoden zur Durchführung der Prüfung sind z. B. statische Analyse, Test, Simulation, Korrektheitsbeweis, symbolische Programmausführung, Review, Inspektion. Die Methoden der Prüfungsdurchführung werden anhand der kritikalitäts- und IT-sicherheitsbezogenen Einstufung des Prüflings, der den jeweiligen Stufen zugeordneten Maßnahmen und weiteren an ihn gestellten Qualitätsforderungen ermittelt.

Festzuschreiben sind die Art und Weise der Ergebnissicherung und -auswertung, insbesondere im Hinblick auf Wiederholung von Prüfungen. Es wird geklärt, welche Daten während und nach der Prüfung wie festzuhalten sind.

Die Methoden und Vorgehensweisen werden hier festgelegt und beschrieben, z. B. die Nutzung von automatisierten Vergleichsroutinen, die persönliche Begutachtung, das Führen eines chronologischen Logbuchs.

PrSpez_4  Prüfkriterien

Unter diesem Gliederungspunkt werden die Kriterien jeder Prüfung genannt. Sie sind derart festzulegen, daß die Prüfung hinsichtlich ihrer erfolgreichen Durchführung bewertbar ist.

PrSpez_4.1  Abdeckungsgrad

Es wird festgelegt, wie tief zu prüfen ist (z. B. Angabe über Pfadabdeckung), um die Tauglichkeit des Prüfgegenstands sicherzustellen. Der Abdeckungsgrad ist im allgemeinen von der Kritikalität des Prüfgegenstands abhängig.

PrSpez_4.2  Checklisten

Hier wird ein Fragenkatalog aufgeführt, der bei den Prüfungen von Produkten und Aktivitäten abgearbeitet wird. Die nachfolgenden Prüfchecklisten sind im Minimum je − generischem − Prüfobjekt, in kritischen Fällen jedoch für einzelne Prüfobjekte zu überarbeiten, d. h. zu ergänzen. Sie sind so zu formulieren, daß mögliche Fehler mit größtmöglicher Wahrscheinlichkeit aufgedeckt werden. In den Checklisten sind die verschiedenen Fehlerquellen ausreichend abzudecken:

−	Allgemeine Kriterien wie Vollständigkeit, Produktlayout, Rechtschreibung, Konsistenz innerhalb des Prüfgegenstands, Eindeutigkeit, usw.

−	Entwicklungstechnische Kriterien wie Konsistenz zu Vorgänger- und Nachbarprodukten, Nachvollziehbarkeit, Methodenkonformität, usw.

−	Produktspezifische Kriterien wie Praktikabilität einer Anforderung, Anforderungserfüllung eines Entwurfs, Kommentierung von Code, Detaillierungsgrad einer Spezifikation, usw.

−	System- oder anwendungsspezifische Kriterien wie Erfüllung spezieller Anwenderforderungen, Einhaltung strenger Projektplandaten, Integrierbarkeit in Org-Umgebung, harmonisches Zusammenwirken mit vorhandenem (Teil-) System, usw.

Nachfolgend sind beispielhaft einige grundlegende Fragestellungen für die Checklisten der verschiedenen Prüfgegenstände formuliert. Wie bereits oben erwähnt, bedürfen diese einer Ergänzung und projektspezifischen Interpretation. Für Prüfprodukte sind die allgemein gehaltene "Basis"-Checkliste und die entsprechende "Produkt"-Checkliste als Ausgangspunkt heranzuziehen.

"Basis"-Checkliste für jedes zu prüfende Produkt:

(Die folgenden Fragestellungen zeichnen sich dadurch aus, daß sie alleinig anhand des vorliegenden Prüfgegenstandes beanwortet werden können.)

−	Ist das Produkt nach dem Produktschema aufgebaut?

−	Enthält das Produkt keine Syntaxfehler (z. B. Schreibfehler)?

−	Sind in dem Produkt keine widersprüchlichen Aussagen?

−	Sind alle Aussagen in dem Produkt eindeutig formuliert?

−	Ist das Produkt vollständig?

−	Sind in dem Produkt alle nach dem Produktschema relevanten Inhalte in adäquater Ausführlichkeit vorhanden?

(Die folgenden Fragestellungen zielen auf den Entwicklungshergang eines Produktes, d. h. andere in Beziehung stehende Produkte müssen bei der Prüfung als Input herangezogen werden.)

−	Ist das Produkt konsistent mit allen Vorgänger-Produkten, aus denen das zu prüfende Produkt hervorging?

−	Ist das Produkt frei von Inkonsistenzen und Widersprüchen zu "Nachbar-"Produkten, die mit ihm in Beziehung stehen?

"Produkt"-Checklisten für die einzelnen Vertreter der jeweiligen Produktklassen:

(Diese Fragestellungen behandeln produkttypische Fehlerquellen, d. h. sie zielen auf den Inhalt und Besonderheiten der jeweiligen Produkte.)

−	Anwenderforderungen

•	Sind die Anforderungen erfüllbar, und ist die Erfüllung der Anforderungen prüfbar?

•	Enthalten die Anwenderforderungen allein die vom AG gewünschten Anforderungen frei von überflüssigem Ballast?

•	Sind die Anwenderforderungen frei von versteckten Entwurfsentscheidungen?

•	Entsprechen die fachlichen Anforderungen den Angaben der Ist-Analyse?

•	Sind die Vorgaben aus der Bedrohungs- und Risikoanalyse über die Anforderungen an die IT-Sicherheit ausreichend gewährleistet?

•	Sind die Qualitätsforderungen in ihrer Gesamtheit erfüllbar, d. h. kann die gegenseitige (negative) Beeinflussung einzelner Qualitätskriterien, wie z. B. Zuverlässigkeit gegen Effizienz, kompensiert werden?

−	Systemarchitektur

•	Ist die Systemarchitektur mit den Anwenderforderungen und den Technischen Anforderungen verträglich?

•	Deckt die Systemarchitektur alle Anwenderforderungen plausibel ab?

•	Erfüllen IT-Sicherheitskonzept  und IT-Sicherheitsmodell  die Anforderungen an die IT-Sicherheit und die Anforderungen aus der Bedrohungs- und Risikoanalyse?

•	Ist die Anforderungszuordnung von Anwenderforderungen auf die Elemente der Systemarchitektur eindeutig und vollständig?

•	Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?

•	Sind die Realisierbarkeitsuntersuchungen aussagekräftig?

−	Technische Anforderungen

•	Sind die Anforderungen erfüllbar, und ist die Erfüllung der Anforderungen prüfbar?

•	Entsprechen die Technischen Anforderungen den Absichten der Ersteller der Systemarchitektur?

•	Sind die Technischen Anforderungen frei von versteckten Entwurfsentscheidungen?

•	Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?

•	Sind die Anforderungen an die Software und Hardware ausreichend detailliert spezifiziert?

•	Sind die Entwicklungs- und SWPÄ-Umgebung vollständig und eindeutig beschrieben?

−	Schnittstellenübersicht

•	Sind alle Schnittstellen aufgeführt?

•	Besteht Konsistenz zu den Architekturdokumenten?

−	Schnittstellenbeschreibung

•	Sind alle in der Schnittstellenübersicht identifizierten Schnittstellen beschrieben?

•	Sind die Schnittstellen ausreichend detailliert beschrieben?

−	Integrationsplan

•	Passen die im Integrationsplan aufgeführten Architekturelemente zu denjenigen, die im zugehörigen Architekturdokument aufgeführt sind?

•	Ist die Integrations-/Prüfumgebung verträglich mit der Entwicklungsumgebung?

•	Sind die organisatorischen und terminlichen Vorgaben mit dem Projektplan vereinbar?

−	SW-Architektur

•	Ist der Prozeßentwurf frei von Verklemmungen?

•	Ist der Zugriff auf gemeinsame Betriebsmittel ausreichend geregelt?

•	Ist der Prozeßentwurf mit dem verwendeten Betriebssystem verträglich?

•	Wurden die Vererbungsregeln bezüglich Kritikalität und IT-Sicherheitseinstufung richtig angewandt?

•	Wurden konstruktive Maßnahmen entsprechend der Kritikalitätsstufe eingehalten?

•	Erfüllt die SW-Architektur die Anwenderforderungen und die Technischen Anforderungen?

−	SW-Entwurf

•	Wurden die Realisierbarkeitsuntersuchungen überprüft?

•	Wurden konstruktive Maßnahmen entsprechend der Kritikalitätsstufe eingehalten?

•	Ist der SW-Entwurf im Sinne einer Programmiervorgabe gehalten?

−	Datenkatalog

•	Sind die Angaben im Datenkatalog konsistent zur Datenbank-Beschreibung?

•	Besteht Konsistenz zum zentralen Datenkatalog?

−	Implementierungsdokumente

•	Wird ein einheitlicher Modulrahmen verwendet?

•	Wurden die Programmier-/Codierstandards eingehalten?

•	Wurde der Code ausreichend und verständlich dokumentiert?

•	Ist der Prüfplan konsistent zu den Vorgaben im QS-Plan?

•	Ist die Auswahl der Prüfgegenstände konform mit den Tailoring-Entscheidungen?

•	Sind die organisatorischen und zeitlichen Zuordnungen konsistent zum Projektplan?

−	Prüfspezifikation

•	Deckt die Prüfspezifikation die im Prüfplan dafür festgelegten Vorgaben und Anforderungen ab?

•	Wird gegebenenfalls die Prüfung der Schnittstellen in der Prüfspezifikation behandelt?

•	Entsprechen die Prüfmethoden der dem Prüfgegenstand zugeordneten Kritikalitätsstufe bzw. seiner IT-Sicherheitseinstufung?

•	Sind die vorgegebenen Prüfkriterien objektiv entscheidbar?

−	Prüfprozedur

•	Ist die Prüfprozedur für kritische Komponenten ausreichend detailliert und genau verfaßt?

−	Projekthandbuch

•	Sind die Tailoring-Entscheidungen eindeutig und sind diese nachvollziehbar dokumentiert?

−	Projektplan

•	Ist die Terminplanung frei von Verklemmungssituationen?

•	Ist der Auslastungsgrad der Einsatzmittel (Personal und Ressourcen) kleiner als 100 Prozent?

•	Sind die Inhalte des Projektplans verträglich mit den Vorgaben und Verfahren im Projekthandbuch, KM-Plan und QS-Plan?

−	KM-Plan

•	Berücksichtigt der KM-Plan die besonderen Konfigurationserfordernisse des Projekts?

•	Werden sowohl Vorgaben bzgl. der Identifikation von Software als auch von Hardware getroffen?

−	KID

•	Ist das KID übersichtlich gestaltet, so daß Konfigurationsbeziehungen schnell ersichtlich sind?

•	Ist eindeutig festgelegt, welche Konfigurationseinheiten definiert sind?

•	Wird über das System-KID deutlich, welche weiteren KID existieren?

•	Sind alle Bausteine und Dokumente der Konfiguration vollständig mit ihren Versionskennungen verzeichnet?

"Aktivitäten"-Checkliste für jede zu prüfende Aktivität:

−	Wird die Aktivität entsprechend den relevanten Verfahrensvorschriften ausgeführt?

−	Werden die geltenden Projektstandards eingehalten?

−	Werden bei der Durchführung der Aktivität die Rollen angemessen verteilt?

PrSpez_4.3  Endekriterien

Endekriterien benennen Bedingungen, unter denen die Prüfung als erfolgreich abgeschlossen betrachtet werden kann. In diesem Gliederungspunkt werden sowohl Endekriterien einer erfolgreichen Prüfung (z. B. die geforderte Genauigkeit ist mit einer maximalen Abweichung von +/−0.0005 erfüllt) als auch einer nicht bestandenen Prüfung (z. B. Meldung "Überlauf", "Division durch Null", "Speichermedium voll") genannt.

PrSpez_5  Prüffälle

PrSpez_5.1  Prüffallbeschreibung

Es wird beschrieben,

−	was (Funktion, Genauigkeit, usw.) zu prüfen ist,

−	welche Ausgangssituation hierfür erforderlich ist,

−	welche Eingaben (Daten und Signale mit allen für die Prüfung ausschlaggebenden Eigenschaften wie Zeitbedingungen) notwendig sind und

−	welche Ergebnisse (Ausgabedaten und Reaktionen/Effekte) zu erwarten sind.

Mit den hier aufgeführten Prüffällen müssen die o. g. Endekriterien ausreichend erfüllbar und entscheidbar sein.

PrSpez_5.2  Abdeckungsmatrix

Diese Matrix dokumentiert die Abdeckung der Anforderungen an den Prüfgegenstand durch die einzelnen Prüffälle.

PrSpez_5.2.1  Architektur-Elemente und Schnittstellen

Dieses Kapitel enthält eine Dokumentation der Abdeckung von architektonischen Elementen des Prüflings (z. B. Überdeckung von integrierten Bausteinen durch SW-Module, externe und interne Schnittstellen usw.) und von Code-Elementen (z. B. Zweig-, Bedingungs-, Pfadüberdeckung) durch die Prüffälle.

Wichtig ist, daß die Prüfungen der Schnittstellen durch entsprechende Prüffälle bei den einzelnen Prüfgegenständen ausreichend mit abgedeckt werden.

PrSpez_5.2.2  Fachliche und technische Anforderungen

Dieses Kapitel enthält eine Dokumentation der Abdeckung von fachlichen und technischen Anforderungen (z. B. durch Abdeckung von Äquivalenzklassen und Grenzwerten oder von Zeit- und Mengenanforderungen) durch die Prüffälle.


Prüfprozedur (PrProz_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.3	Produkte des Submodells QS

8.3.4	Prüfprozedur (PrProz_)

Die Prüfprozedur ist eine Arbeitsanleitung, die exakte Anweisungen für jede einzelne Prüfung enthält. Hier sind die einzelnen Schritte der Prüfung definiert. Ebenfalls festgelegt sind die erwarteten Prüfergebnisse sowie Vorschriften zur Prüfungsvor- und -nachbereitung.

Die Prüfprozedur wird für "lauffähige" Prüfgegenstände erstellt, d. h. für das System, für Segmente, für HW-Einheiten und SW-Einheiten, für SW-Komponenten, SW-Module und Datenbanken. Rein physikalisch kann die Prüfprozedur für diese Prüfgegenstände zusammen mit der jeweiligen Prüfspezifikation gehalten werden.

PrProz_2  Identifikation von Prüfgegenstand und Prüffall

Dieser Gliederungspunkt stellt den Bezug zur Prüfspezifikation und zum Prüfplan her. Der Prüfgegenstand wird anhand des KM-Bezeichners (mit gültiger Version) identifiziert.

PrProz_3  Arbeitsanleitung

PrProz_3.1  Vorbereitung (Beschreibung des Ausgangszustandes)

PrProz_3.1.1  Voraussetzungen

Es wird beschrieben, wie die Prüfvoraussetzungen beschaffen sind und der geforderte Ausgangszustand für die Prüfung herzustellen ist (Vorbereitung der Prüfumgebung, Datenträger zur Testdatenerfassung, freier Speicherplatz, usw.).

PrProz_3.1.2  Konfiguration

Es wird beschrieben, wie der Prüfgegenstand zu konfigurieren (aus SW-Modulen, Datenbanken, SW-Komponenten, SW-Einheiten/HW-Einheiten, Segmenten, Stubs und Dummies) und zu installieren ist und wie er mit der Prüfumgebung in Verbindung steht. Es ist anzumerken, welche Zustände oder Daten zu generieren sind und ob Initialisierungen durchzuführen sind.

PrProz_3.2  Durchführung

Bei der Beschreibung der Prüfungsdurchführung wird auf jeden einzelnen Prüfschritt (x = 1..n) eingegangen.

PrProz_3.2.x  Schritt (x)

Die Handgriffe und Interaktionen werden für jeden Schritt beschrieben; insbesondere ist auf Zustand der Hardware/des Geräts, Einstellungen des Prüfers an Geräten, Reihenfolge der Eingaben, usw. einzugehen. Bei automatisierten Prüfungen ist der Prüfablauf zu beschreiben (z. B. Emulatorprozedur für Modultest).

PrProz_3.3  Nachbereitung

PrProz_3.3.1  Ergebnissicherung

Es wird beschrieben, welche Prüfergebnisse wie zu dokumentieren sind: auf Papier, Datenträger, o. ä.

PrProz_3.3.2  Ergebnisauswertung

Es wird spezifiziert, in welcher Art (von Hand, werkzeugunterstützt, usw.) und unter welchen Gesichtspunkten und Bedingungen die Ergebnisauswertung durchgeführt werden soll. Die erwarteten Prüfergebnisse (Soll-Daten) befinden sich in der Prüfspezifikation.


Prüfprotokoll (PrProt_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.3	Produkte des Submodells QS

8.3.5	Prüfprotokoll (PrProt_)

Das Prüfprotokoll enthält die vom Prüfer verfaßten Aufzeichnungen über den Verlauf der Prüfung, vor allem die Gegenüberstellung von erwartetem und erzieltem Ergebnis. Diese Aussagen werden im Rahmen der Auswertung um Analysen über mögliche Ursachen des Fehlverhaltens und um vorgeschlagene Maßnahmen ergänzt.

Das Prüfprotokoll existiert je Prüfgegenstand und je Prüfung.

PrProt_2  Identifikation der Prüfung

PrProt_2.1  Bezug zu Prüfplan, Prüfgegenstand, Prüfspezifikation und Prüfprozedur

Das Prüfprotokoll bezieht sich auf eine konkrete Prüfung und somit auf eine eindeutig definierte Version von Prüfgegenstand, Prüfspezifikation und Prüfprozedur.

PrProt_2.2  Angaben zur Durchführung

Es werden Angaben zu Prüfer, Ort, Datum und Zeit gemacht und der Ausgang der Prüfung (Produkt "akzeptiert" oder "in Bearb.") festgehalten.

PrProt_3  Ergebnisse

Die durch die Prüfung ermittelten Ist-Ergebnisse werden festgehalten. Die End- und Zwischenergebnisse und gegebenenfalls weitere notwendige Informationen werden in chronologischer Folge aufgezeichnet.

Die erwarteten Soll-Ergebnisse aus dem Produkt "Prüfspezifikation" (Gliederungspunkt 5.1) werden aufgelistet.

PrProt_4  Auswertung

PrProt_4.1  Ergebnisauswertung und -beurteilung

Abweichungen der Ergebnisse werden festgehalten und deren Einfluß auf die Funktions-tüchtigkeit des Systems beurteilt. Die möglichen Fehlerursachen werden genannt.

Gegebenenfalls werden Folgemaßnahmen und Empfehlungen ausgesprochen, insbesondere Lösungs- und Korrekturmöglichkeiten.

Wird bei der Durchführung der Prüfung festgestellt, daß spezifizierte Prüffälle fehlerhaft sind (z. B. erwartetes Ergebnis falsch oder Anforderung nicht erfüllbar), so sind diese Prüffälle an dieser Stelle zu nennen und gegebenenfalls eine separate Problemmeldung zu verfassen.

PrProt_4.2  Entwicklungstrends bezüglich Auftreten von Mängeln

Zeigt sich aus den Prüfresultaten ein bestimmter Trend im Auftreten gleichartiger Mängel, so sind diesbezügliche Vermutungen zu dokumentieren und gegebenenfalls Gegenmaßnahmen vorzuschlagen. Diese Informationen fließen ein in das QS-Berichtswesen.


KM-Plan (KPl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.1	KM-Plan (KPl_)

Der Konfigurationsmanagement-Plan schreibt die abwicklungstechnischen Details bezüglich des Konfigurationsmanagements fest. Es werden Projektregeln und Konventionen bezüglich der Punkte Einführung des Konfigurationsmanagements, Änderungsmanagement (Konfigurationssteuerung) sowie Sicherung und Archivierung vereinbart, die im gesamten Projektverlauf verbindlich einzuhalten sind.

KPl_2  Einführung des Konfigurationsmanagements

Alle zur Einführung des KM erforderlichen Regelungen werden hier getroffen. Dies betrifft die Produktbibliothek, Identifikationsrichtlinien und weitere projektspezifische Regelungen.

KPl_2.1  Produktbibliothek

Alle Produkte − soweit sinnvoll und möglich − werden in einer Produktbibliothek zusammengefaßt und geführt. Hier ist die Produktbibliothek mit ihrer Systematik der Produkt-, Nutzer-, Rechte- und Relationsverwaltung zu beschreiben, bzw. auf geeignete Dokumente/Handbücher zu verweisen.

KPl_2.2  Projektspezifische Festlegungen

Dieser Gliederungspunkt legt fest,

−	welche Produkte unter KM-Kontrolle gestellt werden,

−	anhand welcher Kriterien die Konfigurationseinheiten gebildet werden,

−	welche Zustände die Produkte durchlaufen,

−	welche Produktattribute mitgeführt werden,

−	wie Zugriffsrechte vergeben und kontrolliert werden,

−	wie Produkte von Unterauftragnehmern unter KM-Kontrolle gestellt werden,

−	welche sonstigen Objekte (Entwicklungsrechner, Werkzeuge, Prüfumgebung, usw.) unter KM-Kontrolle gestellt werden,

−	wie KM-Instanzen (z. B. Change Control Board, Interface Control Working Group) eingeführt und besetzt werden,

−	welche Hilfsmittel (z. B. KM-Werkzeuge, Formblätter) bereitgestellt werden.

Zu Produktattribute:

Es wird festgeschrieben, welche Produktattribute geführt werden, welchen Initialwert sie besitzen und wie mögliche Wertfolgen der Attribute aussehen können. Beispiele für Produktattribute sind:

−	Zustand,
klassifiziert den Fertigstellungsgrad des Produkts (geplant, in Bearb., vorgelegt, akzeptiert).

−	Eigentümer,
bezeichnet den Eigentümer (Projekt, usw.) des Produkts.

−	Bearbeiter,
bezeichnet das Submodell oder den Bearbeiter, der das Produkt bearbeitet und verändert.

−	Entstehungsdatum

−	Änderungshistorie

−	Vorgegebene Bearbeitungsdauer,
bezeichnet die vom Projektmanagement vorgegebene Bearbeitungsdauer.

−	Zugriffsrecht,
bezeichnet Zugriffsrechte für die Projektmitglieder.

−	Klassifizierung,
VS-Vermerke unterschiedlicher Abstufung.

−	Schlüsselbegriffe,
bezeichnen das Produkt und dienen zum Wiederfinden. Mögliche Bezeichnungen wären: Treiber, usw.

−	Zugehörige andere Produkte,
hier kann eine Verkettung aller zu einem SW-Modul/SW-Komponente gehörenden Produkte erfolgen.

−	Versionsattribute,
ist das gegenwärtige Produkt eine Version eines Vorgängers, so werden die Versionsattribute eingetragen. Jede Änderung an dem Produkt, die mit einer Zustandsänderung verknüpft ist, bedeutet automatisch eine Änderung der Versionsbezeichnung (normalerweise Versionserhöhung).

Zu Produktzustände:

Ein projektspezifischer Mechanismus, der die erlaubten Zustandsübergänge beschreibt, wird hier festgelegt. Dazu kann Abbildung 6.1 "Zulässige Zustandsübergänge von Produkten" aus dem V-Modell übernommen werden; bei Bedarf können diese Festlegungen weiter detailliert werden durch ein Verfeinern oder Zwischenschalten von Zuständen, wobei allerdings genau definiert werden muß, durch welche Aktivität oder welches Ereignis ein Zustandswechsel erfolgt. Denkbar wäre z. B. die Verfeinerung von "akzeptiert" in "qualitätsgesichert" (durch interne QS) und "freigegeben" (durch externe Prüfstelle) oder die Ergänzung des Zustands "abgenommen" (nach einer Abnahme durch den Auftraggeber).

Zu Zugriffsrechte:

Entsprechend den Bearbeitungskompetenzen der Organisationseinheiten (vgl. Projekthandbuch: Projektorganisation) und der VS-Einstufung der Produkte werden hier Richtlinien für die Vergabe und Kontrolle von Zugriffsrechten auf Daten(basis), Programme, Prozeduren, Werkzeuge festgelegt. Ferner sind in diesem Zusammenhang auch Schutz- und Kontrollmechanismen zu beschreiben und festzulegen.

KPl_2.3  Konventionen zur Identifikation

Alle entwickelten Produkte, Dokumente des Berichts- und Änderungswesens, beauftragte und beigestellte Produkte, referenzierte und verwendete Produkte (z. B. Schnittstellen, Prüfumgebung) und alle Komponenten der Entwicklungsumgebung (Methoden, Werkzeuge, Hilfsmittel) sind eindeutig zu bezeichnen (dazu gehört z. B. auch die eindeutige Beschriftung von Datenträgern).

Es werden den Produkten Identifikatoren zugeordnet, die diese eindeutig einschließlich ihrer Version kennzeichnen. Bei einigen Produkten bietet sich auch eine Identifikation von Produktinterna (z. B. Numerierung von Source-Code-Zeilen) an, die hier mit zu beschreiben ist.

Zu beschreiben sind:

−	Struktur des Identifikators,

−	Informationen, die der Identifikator widerspiegeln soll,

−	Methodik, wie der Identifikator sich bei Änderungen des "Produkts" (z. B. neue Version, neues Release) verhält,

−	Hilfsmittel (eventuell automatisch), die eine selbsttätige Identifikation der Produkte ermöglichen, z. B. bordautonome Analyse der PROM-Checksumme zur Identifikation der Segment-Version,

−	Identifikation von produktinternen Einheiten.

Die Identifikationsrichtlinien gelten jeweils für alle Architekturelemente vom System bis zum Modul, alle zugehörigen Dokumente und verwendeten Produkte. Es wird empfohlen, bei den Identifikatoren der Software die gleiche Methodik wie bei der Hardware anzuwenden (z. B. über Zeichnungsnummer).

KPl_3  Änderungsmanagement

Dieses Kapitel enthält Regelungen im Zusammenhang mit der Durchführung von Änderungen: das Verfahren vom Änderungsantrag/Problemmeldung bis zur Änderungsmitteilung, alle erforderlichen Änderungsformulare und Richtlinien der Versionsführung.

KPl_3.1  Änderungsprozedur

In diesem Kapitel wird der Ablauf einer Änderung beginnend bei ihrem Antrag bis zur abschließenden Mitteilung beschrieben. Häufig wird bei der Änderungsprozedur unterschieden, ob Produkte bereits an den AG ausgeliefert wurden. Bei noch in der Entwicklung befindlichen Produkten wird meist eine vereinfachte Änderungsprozedur verwendet. Falls unterschiedliche Änderungsprozeduren zum Einsatz kommen, sind alle zu beschreiben.

Hier ist zu berücksichtigen, daß in der Praxis mehrere Änderungsvorgänge zusammengeführt werden können. Die Auswirkungen von Änderungen auf die Festlegung von Baselines sind zu beschreiben.

KPl_3.1.1  Verfahren im Änderungswesen

Folgende Situationen sind hier abzudecken:

−	Änderungswunsch für noch in der Entwicklung befindliche Produkte und bereits ausgelieferte Produkte,

−	Änderungswunsch projektexterner (Anwender, AG) und -interner Stellen,

−	Inhalt des Änderungswunsches: Problem, Fehler, Modifikation und Erweiterung,

−	Festlegung von Baselines.

Zu regeln sind in diesem Kapitel:

−	Erfassung und Verfolgung des Änderungswunsches,

−	Weg der Änderung vom Änderungsantrag/Problemmeldung über den Änderungsvorschlag und Änderungsauftrag bis zur Änderungsmitteilung,

−	beteiligte Instanzen mit ihren Pflichten und Entscheidungsbefugnissen.

KPl_3.1.2  Änderungsaufträge

Es wird festgelegt, wie mit Änderungsaufträgen weiter verfahren wird; dies umfaßt insbesondere die Regelung von Release-Ausgaben (Zusammenfassung mehrerer Änderungen) und die Vorgehensweise für das Verfolgen von Änderungen. IT-sicherheitskritische Ergänzungen bzw. Modifikationen zum Änderungsverfahren sind zu beschreiben.

KPl_3.1.3  Schnittstellen zum Auftraggeber und zu anderen Stellen

In bezug auf das Änderungsmanagement werden die Kommunikationsbeziehungen festgelegt. Es ist u. a. zu klären, über welche Art von Änderungen der AG wann und wie detailliert zu informieren ist und wer über welche Änderungen entscheidet.

KPl_3.1.4  Änderungskontrolle und Statusanzeige

Es wird ein Verfahren festgelegt, wie der Stand der Bearbeitung (Status in der Änderungsstatusliste) von Problemen und beauftragten Änderungen verfolgt wird, wie insbesondere noch offene Probleme und Änderungen identifiziert werden können.

Auch werden Richtlinien für die Dokumentation von Änderungen und Verfahren zur Cross-Referenzierung zwischen Formularen definiert.

KPl_3.2  Formulare des Änderungswesens und deren Handhabung

In diesem Kapitel werden die Formulare des Änderungswesens präsentiert. Neben der Festlegung des Inhalts der Dokumente sind auch die exakte Struktur und der formale Aufbau von

−	Änderungsantrag/Problemmeldung,

−	Änderungsvorschlag,

−	Änderungsauftrag und

−	Änderungsmitteilung

geregelt.

KPl_3.3  Versionskontrolle

Nach erfolgter Änderung müssen die Versionen  der geänderten Produkte mitgeführt werden. Die Methoden werden in bezug auf das Produkt festgelegt.

KPl_3.4  Dokumente des Konfigurationsmanagements

Hier wird festgelegt

−	welche Dokumente im Rahmen des Konfigurationsmanagements zu erstellen sind,

−	welche Inhalte und

−	welche äußere Form die Dokumente aufzuweisen haben.

−	Insbesondere werden Verfahren zur Cross-Referenzierung zwischen Formularen definiert, damit Änderungen im Detail verfolgt werden können.

KPl_4  Sicherung und Archivierung

Die Vorgehensweise der Ergebnissicherung wird festgelegt:

−	wann (fester Termin, periodisch, ereignisorientiert)

−	wer (Organisationseinheit)

−	was (welche Produkte)

−	wie (Datenträger, Verfahren)

−	wo (Ablage)

sichert bzw. archiviert.


Konfigurations-Identifikationsdokument (KID_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.2	Konfigurations-Identifikationsdokument (KID_)

Das Konfigurations-Identifikationsdokument reflektiert die Konfigurationen auf den Hierarchiestufen System (System-KID) und SW-Einheit (SW-KID) bzw. HW-Einheit (HW-KID).

Im System-KID werden Segmente, HW-Einheiten und SW-Einheiten (einschließlich einem Verweis auf deren KID) und Dokumente der System-Ebene aufgeführt. Im SW-KID werden die SW-Komponenten, SW-Module und Datenbanken der SW-Einheit sowie die zugehörigen Dokumente aufgeführt. Im HW-KID werden HW-Komponenten und HW-Module der HW-Einheit sowie die zugehörigen Dokumente aufgeführt. Übergreifende Produkte werden jeweils beim Vertragsgegenstand eingehängt.

Es ist möglich, mehrere Konfigurations-Identifikationsdokumente zu einem Dokument zusammenzufassen.

KID_2  Identifikation

Das Konfigurationsobjekt ist zu identifzieren, die Konfigurationsattribute (z. B. Laborversion, Testversion, Serie) zu beschreiben, die Kenndaten der Konfiguration sind anzugeben, und es ist auf ein übergeordnetes System-KID bzw. auf untergeordnete SW-KID und HW-KID zu verweisen. Daneben werden folgende Informationen aufgeführt:

−	Version/Nummer der Konfiguration

−	Projektbezeichnung

−	KM-Verantwortlicher

−	Zustand der Konfiguration

−	Datum der letzten Konfigurationsänderung

In Anlehnung an die Architekturdokumente (System-, HW-Architektur und SW-Architektur) sind ebenfalls auf diesen beiden Ebenen "System" und "Software" bzw. "Hardware" getrennte KID vorgeschrieben. Projektspezifische Besonderheiten, wie z. B. Auslieferung von einzelnen oder konfigurierten Software- oder Hardware-Komponenten als eine Liefereinheit, können weitere KID-Stufen erfordern, nachdem einer Liefereinheit immer auch ein eigenes KID zuzuordnen ist. Nach diesen Projektentscheidungen richtet sich die Definition und Anzahl der KID im Projekt und damit auch die Interpretation einer "Konfigurationseinheit", d. h. es liegt in der Verantwortung des Konfigurationsmanagements, gegebenenfalls weitere KID zu halten und damit weitere Konfigurationseinheiten zu definieren.

KID_3  Bausteine

Die zur Konfiguration benötigten Elemente werden anhand ihrer eindeutigen Kennung und ihrer Version identifiziert. Für ein System-KID sind dies: Segmente, SW-Einheiten  und HW-Einheiten; für ein SW-KID: SW-Komponenten, SW-Module und Datenbanken; für ein HW-KID: HW-Komponenten und HW-Module. Mit aufzunehmen ist eine genaue Anleitung zur Konfiguration bzw. eine automatisierte Prozedur.

Die Relationen zwischen den einzelnen Bausteinen (interne Bezüge innerhalb der Konfiguration) sind zu dokumentieren. Um Generierungen automatisieren zu können, müssen hier redundante und kopierte Produktteile, Schnittstellen und hierarchischen Beziehungen zwischen den Bausteinen festgehalten werden.

KID_4  Dokumentation

Alle zur Konfiguration und ihren Bestandteilen gehörenden Dokumente (Anforderungs-, Architektur-, Entwurfs-, Prüfdokumente, usw.) werden aufgeführt.


Änderungsformulare
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

Unter den Änderungsformularen werden der Änderungsantrag/Problemmeldung, der Änderungsvorschlag, der Änderungsauftrag, die Änderungsmitteilung und die Änderungsstatusliste zusammengefaßt.


Änderungsantrag/Problemmeldung (ÄA_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

8.4.3.1	Änderungsantrag/Problemmeldung (ÄA_)

Der Änderungsantrag/Problemmeldung ist der schriftlich formulierte Wunsch eines Projektmitglieds, des Auftraggebers oder Anwenders nach Durchführung einer Änderung.

Der Antrag/die Meldung muß enthalten:

−	Identifikation

•	Nummer des Änderungsantrag/Problemmeldung

•	Kurzbeschreibung des Problems

•	Identifikation des Projektes

•	Identifikation der betroffenen Konfiguration

•	Datum

•	Verfasser

−	Einordnung

•	Dringlichkeit

•	Gewünschter Fertigstellungszeitpunkt

•	Kategorie (Fehler [in Spezifikation, Entwurf, Codierung, im Verfahren], Problem, Modifikation, Erweiterung, Verbesserung, usw.)

−	Gegenstand des Änderungsantrag/Problemmeldung

•	Identifikation betroffener Produkte
Zu ändernde Produkte mit ihrer Versions-/Konfigurationsbezeichnung, nach Möglichkeit zu unterscheiden in primär betroffene Produkte und sekundär (in Konsequenz) zu ändernde Produkte

•	Darstellung des Ist-Zustandes
Angaben zur Rekonstruktion eines Problems (System-Zustand, Umgebungsbedingungen, Nutzer- und Systemreaktionen, Auswirkungen usw.)

•	Darstellung des Soll-Zustandes
Erläuterung und Begründung der gewünschten Reaktionen, Zustände, Bedingungen, usw.

−	Bemerkung,
z. B. über Beziehungen zu bereits gestellten Änderungsanträgen/Problemmeldungen


Änderungsvorschlag (ÄVor_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

8.4.3.2	Änderungsvorschlag (ÄVor_)

Der Änderungsvorschlag beinhaltet die technische und wirtschaftliche Bewertung des Änderungsantrags/Problemmeldung und zeigt die verschiedenen Möglichkeiten zur Durchführung der gewünschten Pflege/Änderung auf.

Der Vorschlag muß enthalten:

−	Identifikation

•	Nummer des Änderungsvorschlages

•	Nummer des zugehörigen Änderungsantrags/Problemmeldung

•	Identifikation des Projektes

•	Identifikation der betroffenen Konfiguration

•	Datum

•	Verfasser

−	Kurzbeschreibung der gewünschten Änderung

−	Diagnose und Beschreibung aller möglichen Lösungswege
(fortlaufend numeriert)

•	Beschreibung der empfohlenen Maßnahmen

•	Aufsetzpunkt im V-Modell (Startaktivität)

•	Umfang der Änderungen

•	Art und Weise der Änderungen

•	betroffene Produkte (primär und sekundär)

•	Beschreibung der Auswirkungen

•	Erfüllung der Anwenderforderungen und Technischen Anforderungen

•	Beeinträchtigung von Zuverlässigkeit, Effizienz, Realzeit-Verhalten

•	Bewertung

•	Technisch: "Güte" der Lösung und Begründung

•	Wirtschaftlich: Aufwand, Abschätzung von Betriebsmittel- und Zeitbedarf, Durchführbarkeit, Auswirkungen auf den weiteren Projektverlauf


Änderungsauftrag (ÄAuf_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

8.4.3.3	Änderungsauftrag (ÄAuf_)

Der Änderungsauftrag enthält eine Verfeinerung des ausgewählten Lösungswegs aus dem Änderungsvorschlag. Der Auftrag resultiert aus einem Genehmigungsverfahren. Der Änderungsauftrag hat Anforderungscharakter und spezifiziert im Detail die durchzuführenden Änderungen.

Der Auftrag muß enthalten:

−	Identifikation

•	Nummer des Änderungsauftrags

•	Nummer des zugehörigen Änderungsvorschlages

•	Nummer des zugehörigen Änderungsantrags/Problemmeldung

•	Identifikation des Projektes

•	Identifikation der betroffenen Konfiguration

•	Datum

•	Verfasser

−	Angaben zur Ausführung

•	Betroffene Produkte (primär und sekundär)

•	Verantwortlicher für die Änderung

•	Aufwand- und Terminvorgabe

−	Ausgewählte Lösung

Detaillierte Beschreibung der Änderung

Je betroffenem Produkt:

•	Aufsetzpunkt im V-Modell

•	Umfang und Inhalt der Änderung

•	Auswirkungen, Bemerkungen

•	Hinweise zur Ausführung


Änderungsmitteilung (ÄMit_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

8.4.3.4	Änderungsmitteilung (ÄMit_)

Die Änderungsmitteilung beschreibt die aufgrund eines Änderungsantrags/Problemmeldung durchgeführten Änderungen.

Die Mitteilung muß enthalten:

−	Identifikation

•	Nummer der Mitteilung

•	Nummer des zugehörigen Änderungsauftrags

•	Nummer des zugehörigen Änderungsvorschlages

•	Nummer des zugehörigen Änderungsantrags/Problemmeldung

•	Identifikation des Projektes

•	Identifikation der betroffenen Konfiguration

•	Datum

•	Verfasser (geprüft von)

−	Kurzbeschreibung der Änderung

−	Änderungsbeschreibung
Geänderte Elemente mit ihrer Versionsnummer und im Detail jede geänderte Zeile, Blatt, usw.

−	Bemerkungen
Z. B. Abweichung vom Änderungsauftrag


Änderungsstatusliste (ÄStat_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.3	Änderungsformulare

8.4.3.5	Änderungsstatusliste (ÄStat_)

In diese Liste werden alle eingehenden Änderungsanträge/Problemmeldungen eingetragen. Aufgabe der Liste ist es, einen Überblick über die Anzahl, Art und den Bearbeitungszustand von Änderungsanträgen/Problemmeldungen zu erhalten, den Status der Änderungen sichtbar zu machen und die Verfolgung aller Änderungsaufträge sicherzustellen.

Die Liste muß enthalten:

−	Identifikation

•	Identifikation des Projektes

•	Datum

•	Verantwortlicher

−	Je Änderungsantrag/Problemmeldung:

•	Nummer des Änderungsantrags/Problemmeldung

•	Nummer des zugehörigen Änderungsvorschlages

•	Nummer des zugehörigen Änderungsauftrags

•	Nummer der zugehörigen Mitteilung

•	Identifikation der betroffenen Konfiguration

•	Status der Änderung ("abgelehnt", "beabsichtigt", "genehmigt", "in Arbeit", "erledigt")

•	Änderungsverantwortlicher

•	Änderungsbeginn/-ende


Projekthistorie (PHis_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.4	Produkte des Submodells KM

8.4.4	Projekthistorie (PHis_)

In der Projekthistorie wird die Entwicklungs- und Änderungsgeschichte des Systems dokumentiert. Sie dient als Informationsquelle und Nachschlagewerk über den Projektverlauf und durch das Führen statistischer Plan- und Änderungsdaten auch als Planungs- und Kontrollinstrument.

PHis_2  Entwicklungsverlauf

PHis_2.1  Entscheidungen

Alle Entscheidungen, die den weiteren Projektverlauf in technischer oder administrativer Hinsicht bestimmen, sind zu begründen.

PHis_2.2  Schwierigkeiten, deren Ursachen und Behebung

Im Projekt aufgetretene Schwierigkeiten sind mit ihren Ursachen (sofern bekannt), ihren Auswirkungen und den unternommenen Maßnahmen zu dokumentieren.

PHis_3  Änderungs-/Versionshistorie

Mit der Änderungs- und Versionshistorie wird das Ziel verfolgt, den Inhalt, die Ursachen, die Entscheidungen und den Verlauf von Änderungen zwischen den aufeinanderfolgenden Produktversionen über die gesamte Projektlaufzeit und für das gesamte System nachvollziehbar zu machen.

PHis_3.1  Nachvollziehbarkeit von Änderungen

Dieses Kapitel beschreibt Informationen zur Nachvollziehbarkeit von Änderungen (Dokumentation der Änderungen von einer Version zur nächstfolgenden und Dokumentation, welche Änderungen in welche Version eingeflossen sind).

PHis_3.2  Dokumentation der Änderungshistorie

Alle gestellten Änderungsanträge/Problemmeldungen mit den aus ihnen resultierenden Änderungsvorschlägen und Änderungsaufträgen sind mit ihrem jeweiligen Zustand zu verzeichnen.

PHis_3.3  Dokumentation der Änderungsentscheidungen

Für jeden Änderungsantrag/Problemmeldung ist eine Begründung der Entscheidung (Genehmigung, Zurückstellung oder Ablehnung) zu liefern.

PHis_4  Planungsstatistik

Mit der Planungsstatistik wird festgehalten, in welchen Punkten der Projektplan wann, von wem und warum geändert wurde. Folgende Informationen sind aufzunehmen:

PHis_4.1  Planabweichungen

Soll-/Ist-Abweichungen aus dem Projektplan sind zu nennen.

PHis_4.2  Planänderungen

Haben sich Planänderungen z. B. wegen Lieferschwierigkeiten, neuer Wünsche des AG, usw. ergeben, so sind diese anzugeben.

PHis_4.3  Analyse der Ursachen

Die Analyseergebnisse zu obigen Planabweichungen und Planänderungen sind aufzuführen.

PHis_4.4  Möglichkeiten zur Verhinderung weiterer Planabweichungen

In diesem Kapitel werden, aufbauend auf den Analysen der Ursachen, Maßnahmen zur Vermeidung weiterer Planabweichungen und Verzögerungen des Abschlußtermins festgehalten.

PHis_5  Änderungs- und Fehlerstatistik

PHis_5.1  Änderungsantrag/Problemmeldung, Änderungsvorschlag, Änderungsauftrag, Änderungsmitteilung

In statistischer Form wird angegeben, wieviele Änderungsanträge/Problemmeldungen, Änderungsvorschläge, Änderungsaufträge und Änderungsmitteilungen während des Projekts auftraten.

PHis_5.2  Betroffene Produkte

Alle von Änderungen betroffenen Produkte werden aufgelistet. Dabei sollte unterschieden werden zwischen denjenigen Produkten, die von einer Änderung unmittelbar betroffen sind, und denjenigen, die nur in der Konsequenz geändert werden müssen.

PHis_5.3  Klassifizierung und Beurteilung

Die oben aufgeführten Änderungsanträge/Problemmeldungen, Änderungsvorschläge und Änderungsaufträge werden nach Art der Fehler und Häufigkeit klassifiziert und beurteilt.

PHis_5.4  Diagnose/Ursache

Die Ursachen der Änderungsanträge/Problemmeldungen werden klassifiziert und statistisch aufbereitet. Dies ist die Basis zur Empfehlung von Maßnahmen.

PHis_5.5  Maßnahmen

Aus der Diagnose/Ursachenuntersuchung werden für jede Fehlerklasse Maßnahmen zur zukünftigen Vermeidung abgeleitet.

PHis_6  Analyse/Auswertung der Projekthistorie

Über die Analyse und Auswertung der Projekthistorie können Erfahrungswerte und Erkenntnisse über den Entwicklungsgang des Projektes gewonnen werden, die späteren Projekten zugute kommen ("lessons learned").


Projekthandbuch (PHb_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.1	Projekthandbuch (PHb_)

Das Projekthandbuch enthält die Projektbeschreibung, eine Übersicht über vertragsrelevante Festlegungen (durchzuführende bzw. gestrichene Aktivitäten und Produkte, Liefergegenstände, Beteiligung des AG), die Anleitung zur Durchführung des Projekts, d. h. das projektspezifische V-Modell, das in vier Abschnitten dargestellt wird (SE-, QS-, KM- und PM-Regelungen), die Festschreibung der Projektorganisation, die ausgewählten Methoden und Werkzeuge und die festgelegten Standards und Richtlinien.

PHb_2  Projektbeschreibung

In einer kurzen, prägnanten Beschreibung wird den Projektbeteiligten der Gegenstand des Projektes nahegebracht.

Weiterhin sollen Aussagen zu folgenden Projektkennzeichen enthalten sein:

−	Produktart (System, Segment, HW-Einheit oder SW-Einheit) des Entwicklungsgegenstands

−	geplante Ausbaustufen

−	Klassifizierung der Software (operative Software, Nachweissoftware, SWPÄ-Software, Unterstützungssoftware, Ausbildungssoftware,  usw.)

−	Kritikalitäts- und IT-Sicherheitseinstufung

−	Qualitätsziele und -risiken

−	Wartbarkeitsanforderungen

−	Entwicklungsrandbedingungen

−	Projektgröße

−	Kritische Erfolgsfaktoren

PHb_3  Übersicht

Dieses Kapitel nimmt alle wesentlichen vertragsrelevanten Festlegungen zum Projekt auf (siehe Tabelle 8.1). Insbesondere sind der Leistungs- und Lieferumfang abzuklären.

Der Leistungsumfang wird über das Tailoring des V-Modells ermittelt. Hier sollen alle Aktivitäten und Produkte der Submodelle SE, QS, KM und PM unter Angabe der Tailoring-Kriterien (Streichbegründungen für gestrichene Aktivitäten und technische Streichbedingungen für optionale Streichungen während des Projektverlaufs) aufgeführt werden. (Hierfür können die Übersichtsdarstellungen auf der letzten Seite des jeweiligen Submodells im generischen V-Modell herangezogen werden). Zu den einzelnen (Teil-) Aktivitäten und (Teil-) Produkten sind die gegebenenfalls erfüllten (Hinweis "entfällt" unter Angabe des Streichgrunds) bzw. die relevanten technischen Streichbedingungen anzugeben. (Teil-) Aktivitäten/(Teil-) Produkte, für die keine Streichbedingungen angeführt werden, müssen im Projekt durchgeführt/erstellt werden.

Die Festlegung der Prüfgegenstände, auf die sich einzelne QS-Aktivitäten beziehen, erfolgt im QS-Plan.

Alle Produkte des V-Modells, die an den Auftraggeber auszuliefern sind (Lieferumfang)  werden markiert. Neben den SE- und QS-Produkten kann vom AG auch die Auslieferung von KM- und PM-Produkten verlangt werden.

Die unter Beteiligung des AG zu bearbeitenden (Teil-) Aktivitäten und (Teil-) Produkte des projektspezifischen V-Modells sind zu nennen. Nähere Einzelheiten zur Beteiligung werden in Kapitel PHb_7.5 festgelegt.

Nr.	Aktivität	Produkt	Streich- art	entfällt, weil (AT-Begründung)  wenn (TT-Bedingung)	AG-Beteiligung	Lieferge- genstand
...	.....
SE 4-SW	SW-Grobentwurf	SW-Architektur	-	-	Genehmigung	ja
SE 4.1-SW	SW-Architektur entwerfen		-	-	-
SE 4.2-SW	SW-interne und -externe Schnittstellen entwerfen	Schnittstellenbe- schreibung	-	-	-	ja
SE 4.3-SW	SW-Integration spezifizieren	SW-Integrations- plan	TT	entfällt, wenn die Integration nicht komplex ist	-	nein
SE 5-SW	SW-Feinentwurf		-	-	-	-
SE 5.1-SW	SW-Komponente/- Modul/Datenbank be schreiben	Datenkatalog SW-Entwurf	AT	entfällt grundsätzlich für SW- Module und SW-Komponenten, weil der Algorithmus in der Architektur ausreichend beschrieben wird	-	nein
SE 5.2-SW	Betriebsmittel- und Zeitbedarf analysieren	SW-Entwurf	AT	entfällt grundsätzlich, weil genügend Ressourcen vorhanden sind	-	nein
...	...	...		...	...	...
Tabelle 8.1:	Beispiel einer Aktivitäten-/Produktübersicht

PHb_4  Entwicklungsstrategie

Die dem V-Modell zugrundeliegende Entwicklungsstategie ist die inkrementelle Entwicklung. (In dem Handbuch "Szenarien" der Handbuchsammlung, Teil 3, werden mögliche Einsatzstrategien mit ihren Auswirkungen auf die Planungs- und Entwicklungsaktivitäten aufgezeigt.)

In diesem Kapitel ist (zusätzlich zur Aktivitäten-/Produktübersicht) die Anwendung der geplanten Entwicklungsstrategie (inkrementell, Einsatz von Fertigprodukten, objektorientiert, usw.) für die verschiedenen Projektabschnitte bzw. Ausbaustufen aufzuführen. Die Auswirkungen der gewählten Entwicklungsstrategie (wiederholende Abfolge von Entwicklungsaktiviäten) sind durch die Projektplanung (Projektplan) zu berücksichtigen.

Werden für unterschiedliche Systemteile unterschiedliche Szenarien angewendet, so ist die Anwendung mehrerer Szenarien darzustellen.

PHb_5  Projektspezifisches V-Modell

Zum projektspezifischen V-Modell gelangt man über das Tailoring  des (generischen) V-Modells. Hierzu werden aus dem generischen V-Modell projektspezifisch diejenigen Regelungen der Aktivitäten und Produkte extrahiert, die bei der Projektbearbeitung als verbindliche Arbeitsvorgabe zur Anwendung kommen. Im Projekthandbuch sind somit nur die Regelungen enthalten, die in dem jeweiligen Projekt zur Anwendung kommen. Es ist dies die Aktivitäten und Produkte des generischen Modells, verringert um alle nicht relevanten (Teil-) Aktivitäten und (Teil-) Produkte.

Die Aktivitäten und Produkte können hier vollständig beschrieben werden oder lediglich als Referenz auf die V-Modell-Aktivitäten und -Produkte aufgeführt werden.

PHb_5.1  SE-Regelungen

PHb_5.1.1  Aktivitäten

PHb_5.1.2  Produkte

PHb_5.2  QS-Regelungen

PHb_5.2.1  Aktivitäten

PHb_5.2.2  Produkte

PHb_5.3  KM-Regelungen

PHb_5.3.1  Aktivitäten

PHb_5.3.2  Produkte

PHb_5.4  PM-Regelungen

PHb_5.4.1  Aktivitäten

PHb_5.4.2  Produkte

PHb_6  Auswahl von Methoden und Werkzeugen

Sofern die Anwendung bestimmter Methoden- und Werkzeuge vereinbart ist, enthält dieses Kapitel für die in Kapitel PHb_5 aufgeführten Aktivitäten die Zuordnung der Methoden und Werkzeuge (siehe Tabelle 8.2).

Nr.	Aktivität	Methode	Werkzeug
SE 1.1	Ist-Aufnahme/-Analyse durchführen	ER-Modellierung Datenflußmodellierung	Werkz. 1 Werkz. 2
SE 1.5	System fachlich strukturieren	Funktionale  Dekomposition	Werkz. 3
SE 1.7	System technisch entwerfen	Funktionale  Dekomposition	Werkz. 3
SE 3.3	Anforderungen an die Funktionalität definieren	Funktionale  Dekomposition	Werkz. 3
SE 4.1-SW	SW-Architektur entwerfen	Structured Design	Werkz. 4
...	...	...	...
Tabelle 8.2:	Beispiel einer Methoden-/Werkzeugzuordnung

Zusätzlich können hier nähere Einzelheiten zu den getroffenen Methoden- und Werkzeugfestlegungen festgehalten werden.

PHb_7  Projektorganisation

Hier erfolgt eine Beschreibung der Projekt-Aufbauorganisation. Es wird geklärt, wie sich das Projektteam zusammensetzt (aus welchen Stellen, Instanzen), wie sich Aufgaben und Verantwortlichkeiten auf diese verteilen und welche Schnittstellen das Projekt aufweist.

PHb_7.1  Aufbauorganisation

Hier werden die Stellen genannt, die für die Bearbeitung der Aktivitäten aus den Submodellen (SE, QS, KM, PM) zuständig sind.

Insbesondere werden die im V-Modell aufgeführten Rollen auf die betrieblichen Organisationseinheiten abgebildet und gegebenenfalls projektbedingte Instanzen oder Arbeitsgruppen (z. B. Change Control Board) gebildet. Es muß klargestellt sein, inwieweit die Organisationsform den vorgegebenen Einschränkungen im V-Modell hinsichtlich der Belegung der Rollen gerecht wird.

Der Grad der Unabhängigkeit der Organisationseinheit "Qualitätssicherung" und die Beziehungen zur Systemerstellung, zum Konfigurationsmanagement und Projektmanagement, aber auch zum Anwender und Auftraggeber müssen ersichtlich sein.

PHb_7.2  Aufgaben und Verantwortlichkeiten

Im Projektorganisationsplan ist ferner einzutragen, wie sich Aufgaben und Verantwortung auf die oben genannten Organisationseinheiten verteilen. Entscheidungs- und Genehmigungsinstanzen sind im Detail festzulegen.

−	Dabei sind auch die QS und KM (z. B. firmeninterne Qualitätssicherung, Güteprüfstelle, usw.) festzulegen (u. a. wer hat Produkte zu prüfen, welche Instanz darf  Produkte intern oder extern zur weiteren Verwendung freigeben, usw.).

−	Es ist in Abhängigkeit von der VS-Einstufung festzulegen, welche KM-Aktivitäten von welchen Instanzen wahrgenommen werden.

−	Besondere Beachtung muß die Kontrolle der technischen Schnittstellen zwischen Segmenten und SW-Einheiten/HW-Einheiten finden. Die Kontrolle dieser Schnittstellen bedarf insofern besonderer Kontroll-, Informations-, Abstimm- und Austauschverfahren, da in der Regel verschiedene Instanzen oder Firmen an diesen Schnittstellen arbeiten. Auch innerhalb einer betrieblichen Organisationseinheit muß vor allem die Entwicklung und Abstimmung der SW-HW-Schnittstellen genauestens geregelt sein. Ändert eine Seite eine Schnittstelle, so muß sichergestellt und überwacht werden, daß notwendige Folgeänderungen auf der anderen Seite durchgeführt werden. Die dafür notwendigen KM-Maßnahmen werden den KM-Instanzen (z. B. Interface Control Working Group) zugeordnet.

PHb_7.3  Externe Schnittstellen

Kommunikations- und Verfahrensschnittstellen mit firmenexternen Stellen (Auftraggeber, Unterauftragnehmer, Partner, Gremien und Ausschüsse, Zulassungsstellen) werden hier festgelegt. Dokumentiert wird, wer welche Art und Form von Information (technisch oder administrativ, schriftlich oder mündlich) wann (fester Termin, periodisch, ereignisbedingt) von wem erhält bzw. an wen weitergibt.

Für die einzelnen Schnittstellen sind Ansprechpartner zu benennen, und es ist zu klären, welche Aktivitäten sie betreuen bzw. für welche Produkte sie verantwortlich bzw. in welchen Angelegenheiten sie kompetent sind.

Diese Liste sollte folgende Angaben über jeden Ansprechpartner enthalten:

−	Name des Ansprechpartners

−	Vollständige Adresse des Ansprechpartners

−	Abteilung

−	Funktion im Projekt, Zuständigkeit, Fachgebiet

−	Telefon-/Telefaxnummer(n)

−	Kommunikationsadresse(n).

Phb_7.4  Berichtswesen

Kommunikations- und Verfahrensschnittstellen mit firmeninternen Stellen werden hier festgelegt. Dokumentiert wird, wer welche Art und Form von Information (technisch oder administrativ, schriftlich oder mündlich) wann (fester Termin, periodisch, ereignisbedingt) von wem erhält bzw. an wen weitergibt.

Im übrigen gilt hier das bereits oben unter Kapitel 7.3 "Externe Schnittstellen" Gesagte.

PHb_7.5  Beteiligung des AG

Der Aufgabenbereich von Auftraggeber und Auftragnehmer ist über eine Zuordnung der Aufgaben (Aktivitäten des V-Modells) und Verantwortlichkeiten auf Auftraggeber und (Unter-) Auftragnehmer festzulegen. Insbesondere für Aktivitäten von QS, KM und PM muß eine Zuordnung auf beide Seiten unter Berücksichtigung des jeweiligen Zuständigkeitsbereiches erfolgen.

Die Mitwirkung des AG im Projekt liegt in seiner eigenen Entscheidungsbefugnis. Entsprechend seinen Vorstellungen sind die Aktivitäten/Rollen-Matrizen des V-Modells anzupassen.

PHb_8  Standards und Richtlinien

Darunter sind z. B. Codierstandards, Dokumentenmuster und Namenskonventionen zu verstehen. Hier im Projekthandbuch kann entweder die Beschreibung der Standards, Normen und Richtlinien oder aber ein Verweis auf ein existierendes und allen Projektbeteiligten zugängliches Dokument erfolgen.


Projektplan (PPl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.2	Projektplan (PPl_)

Der Projektplan enthält die Planung und Festschreibung von Projektablauf, Zeit und Einsatzmitteln für alle Submodelle. Er ist ein Instrument zur Planung, Steuerung und Kontrolle durch das Projektmanagement.

PPl_2  Projektablauf

Dieses Kapitel beschreibt die Produktstruktur des Entwicklungsprodukts und darauf aufbauend die ablauforganisatorischen Gegebenheiten.

PPl_2.1  Produktstrukturplan

Alle Produkte, die zum jeweiligen Planungsstand bekannt sind, werden identifiziert und in ihrer Abhängigkeit (Struktur) untereinander festgelegt. Hierbei ist auf Konsistenz mit dem KID zu achten.

Es sind in der Beschreibung zwei verschiedene Blickrichtungen abzudecken: die entwicklungsbegleitende Dokumentation des Systems (Anforderungen, Entwurf, usw.) und der technische Aufbau des Systems (SW-Module, SW-Komponenten, usw.).

Dieses Kapitel enthält sowohl die als Vertragsbestandteil festgelegten Produkte als auch die "internen" Produkte.

PPl_2.2  Ablauforganisation

Den im Produktstrukturplan festgelegten Produkten werden die im Projekthandbuch vorgesehenen generischen Aktivitäten zugeordnet. Dies ist eine Instantiierung der Aktivitäten. So wird hier nicht mehr z. B. von der Aktivität "Feinentwurf", sondern exakt von "Feinentwurf der SW-Komponente xy" gesprochen. Für die Planung und Steuerung des Projektablaufs müssen die instantiierten Aktivitäten in ihren Abhängigkeiten untereinander dargestellt werden.

PPl_3  Aufwands- und Terminplan

Hier wird festgelegt, welche Tätigkeiten wann und mit welchem Aufwand zu erfüllen sind.

PPl_3.1  Grobplan

Dieser Plan orientiert sich an den instantiierten Hauptaktivitäten und hält die zugehörigen Plandaten in einer ersten Näherung fest.

PPl_3.1.1  Aufwände (Soll und Ist) für SE-/QS-/KM-/PM-Aktivitäten

Für alle Projektaktivitäten (also auch für PM selbst!) werden die zeitlichen Aufwände ermittelt.

Vor Beginn der Aktivitäten wird hier der Soll-Aufwand eingetragen. Nach Abschluß werden ihm die tatsächlich gebrauchten Zeiten tabellarisch oder grafisch gegenübergestellt.

PPl_3.1.2  Termine (Soll und Ist) für SE-/QS-/KM-/PM-Aktivitäten

Aus den zeitlichen Aufwänden und den festgelegten Abhängigkeiten der Aktivitäten werden die Soll-Termine ermittelt. Auch hier erfolgt ein abschließender Soll/Ist-Vergleich in tabellarischer oder grafischer Form.

PPl_3.1.3  Meilensteinplan

Entscheidende Termine werden zu Meilensteinen ernannt, so z. B. der Abschluß der Entwurfsarbeiten, die Fertigstellung eines Prototyps oder Teilsystems. Die Fertigstellung einer Baseline definiert ebenfalls einen Meilenstein.

PPl_3.1.4  Baselines

Produkte, die für nachfolgende Entwicklungsschritte, Unteraufträge oder Weiterentwicklungen einen definierten Ausgangspunkt bilden, werden zu einer Baseline zusammengefaßt. Eine Baseline definiert eine Sollbruchstelle für das Projekt. Hier ist festzulegen, welche Baselines erforderlich sind und welche Produkte diesen Baselines zugeordnet werden.

PPl_3.1.5  Durchführungsentscheidungen

Die terminliche, personelle und organisatorische Planung der Durchführungsentscheidungen wird festgelegt:

−	Zeitpunkt (z. B. anhand von Meilensteinen)

−	Produkte und Unterlagen, über welche entschieden werden muß

−	Teilnehmer (der verschiedenen Organisationseinheiten)

−	Tagesordnung

PPl_3.1.6  Zu- und Ausliefertermine

In diesem Kapitel sind all die Termine gesondert festzuhalten, die auch projektexterne Stellen betreffen, wie Auslieferungen von Produkten an den Auftraggeber, Zulieferungen von Unterauftragnehmern, gemeinsame Aktivitäten (z. B. Erprobungen) mehrerer Auftragnehmer, Bereitstellungen von Produkten an UAN, usw. Hier müssen fünf Ws beantwortet werden: Wer liefert wem was wann wie?

PPl_3.2  Feinplan

Dieser Plan detailliert den Grobplan bis auf die projektspezifisch tiefste Detaillierungsebene der Aktivitäten.

Geeigneterweise sollte hier die Gegenüberstellung der Soll-/Ist-Aufwände und -Termine tabellarisch oder besser grafisch erfolgen. Dadurch werden Prognosen über den weiteren Projektverlauf möglich und Managemententscheidungen dokumentiert.

PPl_3.2.1  Soll-Werte

Festzuschreiben sind hier Soll-Aufwände und Soll-Termine. Soll-Aufwände beziehen sich im wesentlichen auf das Personal. Bei den Soll-Terminen werden

−	die Aktivitäten-Dauer,

−	die frühesten und spätesten Starttermine und

−	die frühesten und spätesten Endetermine

ermittelt.

PPl_3.2.2  Ist-Werte

Dieses Kapitel enthält Ist-Aufwände und Ist- (Start- und Ende-) Termine. Informationen zu Ist-Aufwänden bzw. -Terminen stellen eine Bringschuld der Projektbeteiligten dar.

PPl_4  Einsatzmittelplan

Unter "Einsatzmittel" werden das Personal und die technischen Ressourcen verstanden.

PPl_4.1  Personal

Hier erfolgt eine Zuordnung der Projektaktivitäten auf die zur Verfügung stehenden Mitarbeiter entsprechend ihrer Qualifikation, VS-Zulassung und zeitlichen Verfügbarkeit.

PPl_4.2  Ressourcen

Es wird festgelegt, welche Ressourcen wann und in welchem Umfang benötigt werden. Diese Planung muß in Übereinstimmung mit dem Projektablauf stehen und terminlich mitgeführt werden.

PPl_4.2.1  Infrastruktur

Hierunter fallen z. B. Büroräume, Besprechungsräume, Telefon, Telefax, Kopierer, Wandtafeln.

PPl_4.2.2  HW-, System-SW- und Werkzeug-Ausstattung und -Auslastung

Dieses Kapitel nennt die einzelnen Komponenten der Entwicklungs- und Prüfumgebungen, aber auch z. B. eine erforderliche Vernetzung, Direktleitung zum AG, usw.

PPl_4.2.3  Geräte

Sind besondere Geräte für das Projekt erforderlich, sind diese hier aufzulisten.

PPl_5  Risikobetrachtungen

PPl_5.1  Risikoabschätzung

Auf der Basis des Projektplanung und technischer Realisierbarkeitsuntersuchungen werden risikoträchtige Sachverhalte festgehalten und in ihren möglichen Auswirkungen und dem wahrscheinlichen Auftreten analysiert.

PPl_5.2  Maßnahmen zur Minderung bzw. Vermeidung von Risiken

Alle für das Projekt in Frage kommenden Maßnahmen zur Abwehr von Problemen sind aufzulisten. Die Maßnahmen sind anhand ihrer Eignung, den jeweiligen Problemen entgegenzuwirken, zu priorisieren. Ferner sind geeignete Maßnahmen zur Kompensation bereits aufgetretener Probleme anzubieten.


Angebotsbewertung (AnBew_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.3	Angebotsbewertung (AnBew_)

Die Angebotsbewertung faßt die Ergebnisse der Auswertung der Angebote zusammen. Die Ausgangssituation wird geschildert, die eingegangenen Angebote werden einander gegenübergestellt, das ausgewählte Angebot wird genannt und die Auswahl begründet.

AnBew_2  Ausgangslage

Alle die Bewertung und Auswahl der Angebote beeinflussenden Faktoren und Randbedingungen sind zu nennen. Grundlagendokument für die Angebotsbewertung sind die Vergabeunterlagen zusammen mit dem Projekthandbuch. Neben der technischen Ausgangssituation ist abzuklären, welche administrativen Vorgaben die Angebotsbewertung beeinflussen.

Bestimmte Rahmenbedingungen stellen für die anschließende Beurteilung bedingungslose K.-o.-Kriterien dar, wie z. B. ein nicht zu überschreitendes Budget, die Nicht-Einhaltung eines festen Angebotsabgabetermins oder eine fehlende Zertifizierung des Anbieters.

AnBew_3  Kriterienkatalog zur Bewertung

Bereits im Rahmen der Vorbereitung der Vergabe ist ein Kriterienkatalog mit Wichtungen für die Angebotsbewertung zu definieren. Dort sind alle technischen, kaufmännischen und juristischen Kriterien zusammen mit einer projekt-individuellen Gewichtung aufzuführen. Auch immaterielle Kriterien wie das Unternehmensimage des Anbieters, Angebotsseriosität oder Erfahrungen aus einer früheren Zusammenarbeit und "scheinbar unwichtige" Kriterien wie die räumliche Entfernung des Unternehmens können dabei eine entscheidende Rolle spielen, soweit die Angebote nach den vorgegebenen Auswertungskriterien als wirtschaftlich gleichwertig zu qualifizieren sind.

Ein Bewertungskatalog hat mindestens die folgenden Kriterien zu berücksichtigen:

−	Vollständigkeit der angebotenen technischen Leistungen

−	IT- und Fachanwendungs-Know-how

−	Ausrüstung des Unternehmens

−	Kosten und Termine

−	Gewährleistung

AnBew_4  Beurteilung der Angebote

Die Beurteilung der Angebote erfolgt zunächst über die K.-o.-Kriterien. Die danach verbleibenden Angebote werden über den Kriterienkatalog einander gegenübergestellt.

AnBew_5  Auswahl und Begründung

Sofern die Beurteilung über den Kriterienkatalog eine Auswahl bereits vorwegnimmt, ist hier keine Begründung erforderlich. Liegen jedoch Anbieter für eine klare Entscheidung zu nahe zusammen oder hat eine Auswahl strategische Bedeutung, so ist für die Projektdokumentation die getroffene Wahl nachvollziehbar zu begründen.


Kosten-/Nutzenanalyse (KNA_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.4	Kosten-/Nutzenanalyse (KNA_)

Die Ergebnisse der Kosten-/Nutzenanalyse dienen als Grundlage für anstehende Entscheidungen bzw. als Dokumentation für die getroffene Entscheidung. Eine Kosten-/Nutzenanalyse wird durchgeführt zur Bewertung des wirtschaftlichen Einsatzes der IT aus Nutzersicht, zur Bewertung alternativer technischer Realisierungswege und zur Bewertung planerischer und organisatorischer Möglichkeiten. Prinzip der Kosten-/Nutzenanalyse ist eine monetäre Bewertung von Kosten und Nutzen, wobei die beeinflussenden Kriterien differenziert gewichtet werden können.

Die Kosten-/Nutzenanalyse enthält Aussagen zu folgenden Punkten:

−	Kriterienkatalog,

−	Daten zur Wirtschaftlichkeitsberechnung

−	Barwerte und Ermittlung des Kapitalwertes

−	Risikoabschätzung

−	Dringlichkeitskriterien

−	Strategische Kriterien

Im Bereich der öffentlichen Verwaltung wird die Durchführung der Kosten-/Nutzenanalyse durch die IT-WiBe (Band 26 der KBSt-Schriftenreihe "Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung") geregelt.


Arbeitsauftrag (ArbAuf_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.5	Arbeitsauftrag (ArbAuf_)

Der Arbeitsauftrag enthält alle für einen Mitarbeiter relevanten Informationen zur Erledigung der ihm gestellten Projektaufgabe. Der Arbeitsauftrag soll in der Regel in schriftlicher Form vorliegen.

ArbAuf_2  Beschreibung der gestellten Aufgabe

−	Identifikation und Beschreibung der Aktivität

•	Titel der Aktivität

•	Beschreibung der Tätigkeit

•	Beschreibung der Ergebnisse

•	Technisches Umfeld
(Ausgangsprodukte, Einordnung der Ergebnisse in die Systemstruktur, Schnittstellen, usw.)

−	Soll-Vorgaben

•	Geplante Dauer der Aktivität

•	Start- und Endetermin

•	Erwartete Zwischenberichte

−	Abstimmnotwendigkeiten

Dieses Kapitel enthält inhaltliche und terminliche Angaben über Zulieferungen und Beistellungen, Austausch von Ergebnissen, gemeinsame Tätigkeiten mehrerer Mitarbeiter, Absprachen über technische Details und Schnittstellen.

−	Ansprechpartner

ArbAuf_3  Ergänzende Unterlagen

−	Auszug aus dem Projekthandbuch oder Verweis auf das Projekthandbuch zur Beschreibung der Aktivität und der zu bearbeitenden Produkte

−	Verweis auf erforderliche Methoden- und Werkzeugbeschreibungen

−	Verweis auf anzuwendende Richtlinien und Standards


Berichtsdokumente
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

Unter den Berichtsdokumente werden die nicht nachzuführenden Arbeitspapiere Protokoll, Sachstandsbericht, Projektabschlußbericht und Sachbericht, Aktennotiz, Interne Mitteilung und Einladung zusammengefaßt. Sofern im Unternehmen nicht bereits bindend vorgeschriebene Formulare für das Berichtswesen eingeführt sind, werden Leer- bzw. Muster-Formulare den Projektbeteiligten über das Projekthandbuch zugänglich gemacht.


Protokoll (Prot_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.1	Protokoll (Prot_)

Das Protokoll ist eine schriftliche Dokumentation über den Verlauf und die Resultate einer Besprechung.


Sachstandsbericht (SStB_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.2	Sachstandsbericht (SStB_)

Beim Sachstandsbericht handelt es sich um einen Bericht des Auftragnehmers an den Auftraggeber über den Stand des Projektes im Abgleich zum Projektplan. U. a. enthält dieser Bericht Informationen

−	über den Arbeitsfortschritt,

−	über erledigte und noch ausstehende Tätigkeiten mit einer Gegenüberstellung der Planwerte,

−	über Schwierigkeiten und Neuerungen im Projekt und

−	gegebenenfalls über Inhalt und Ursache einer Änderung des Projektplans (personelle Besetzung, Termine) und Veränderungen in der Aufgabenstellung und -abgrenzung.


Projektabschlußbericht (PAB_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.3	Projektabschlußbericht (PAB_)

Der Projektabschlußbericht ist eine besondere Ausprägung des Sachstandsberichtes, der eine Gesamtschau über den Projektverlauf bietet und gemeinsam mit dem entwickelten Produkt übergeben wird. Es sollte außerdem ein Hinweis enthalten sein, wie mit den Projektergebnissen und -produkten (im Hinblick auf nachfolgende SWPÄ-Projekte) weiter verfahren wird.


Sachbericht (SaB_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.4	Sachbericht (SaB_)

Der Sachbericht hat technische Gutachten, Stellungnahmen oder Bewertungen zum Inhalt. Dies können sein: Dokumentation der Risikoanalyse oder alternativer Maßnahmen inkl. einer Bewertung, Marktsichtung und Gutachten über verwendbare Fertigprodukte, Vergleiche von technischen Lösungen, Realisierbarkeitsuntersuchungen, usw.


Aktennotiz (AktNo_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.5	Aktennotiz (AktNo_)

Die Aktennotiz ist ein Bericht über technische oder administrative Belange von projektübergreifendem Interesse, die den Projektverlauf aus Management-Sicht oder die Systementwicklung aus technischer Sicht in entscheidendem Maße mitbestimmen und zu Projektbeginn noch nicht bekannt oder entscheidbar waren.


Interne Mitteilung (IntMit_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.6	Interne Mitteilung (IntMit_)

Hierbei handelt es sich um eine projektinterne Mitteilung technischen oder administrativen Inhalts, die von jedem Projektmitarbeiter ohne vorherige Absprache verfaßt werden kann.


Einladung (Einl_)
Teil 1	Vorgehensmodell / Regelungsteil

8	Produktmuster

8.5	Produkte des Submodells PM

8.5.6	Berichtsdokumente

8.5.6.7	Einladung (Einl_)

Eine Einladung schreibt alle notwendigen organisatorischen Daten für die verschiedensten Arten von Zusammenkünften innerhalb des Projektes fest und muß genaue Angaben über das jeweilige Thema und das angestrebte Ziel enthalten.


Definitionen (AU250/1)
Teil 1	Anhang zum Regelungsteil (AU250/1)

A	Definitionen

Definitionen, zu denen keine Quellenangabe gegeben wird, sind eigene Definitionen des V-Modells.

Abnahme

Mit der erfolgreichen Abnahme wird der Auftragnehmer entlastet, und das abgenommene Produkt geht in das Eigentum des Auftraggebers über. Die Abnahme ist ein juristisch definierter Vorgang.

Änderbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf den Aufwand, der zur Durchführung vorgegebener Änderungen notwendig ist.

Akquisition

Alle Maßnahmen, die zur Beschaffung, Abwicklung der Entwicklungsschritte, Betrieb und Außerbetriebstellung eines Systems oder von Systemteilen im Rahmen des gesamten Lebenszyklus notwendig sind.

Aktivität

Im V-Modell geregelte Tätigkeit. Sie wird eindeutig durch ihre Abwicklung und ihre Ergebnisse beschrieben.

Aktivitätenklasse

Synonym: Aktivitätentyp

Eine Reihe von Aktivitäten im V-Modell werden im Rahmen eines konkreten Projekts mehrfach durchgeführt (z. B. für jede einzelne Komponente, Modul, usw.). Diese Aktivitäten werden im V-Modell als sogenannte "Aktivitätenklassen" oder "generische Aktivitäten" nur einmal beschrieben. Eine tatsächlich durchgeführte Aktivität wird als "Instanz" (auch "Ausprägung") der (generischen) Aktivität bezeichnet.

Anmerkung:

Alle Aktivitäten des V-Modells sind generische Aktivitäten (d. h. Elemente einer Aktivitätenklasse), auch wenn es einige Aktivitäten gibt, die nur einmal durchgeführt werden (z. B. SE 1, QS 1, KM 1, PM 1)

Aktivitätenschema

Schema zur Beschreibung einer Aktivität im V-Modell. Zu jeder Aktivität werden Name, Produktfluß und Abwicklung angegeben, gegebenenfalls zusätzlich Empfehlungen und Erläuterungen.

Aktivitätenzerlegung

Grafische Darstellung der hierarchischen Zerlegung von Aktivitäten.

Anwender

(Quelle: in Anlehnung an den Entwurf DIN 66285 "Anwendungssoftware")

Eine organisatorische Einheit, die die Verfügungsgewalt über die Sache erhalten soll, deren Entstehen der Zweck des jeweiligen Vorhabens ist.

Anwenderforderungen

Alle vom Anwender vorgegebenen fachlichen Anforderungen an das System und die zugehörigen Randbedingungen.

Ausbaustufe

Synonym: Inkrement

Operationell einsetzbarer Zwischenstand der Entwicklung an einem Meilenstein im Rahmen einer inkrementellen Entwicklung.

Ausbildungs-Software

Software zur Schulung der Nutzer des operationellen Systems.

Austauschbare Einheit

Engl. "Replaceable Unit"

Eine austauschbare Einheit ist ein HW-Baustein, der gegen einen bevorrateten oder nachlieferbaren Baustein ausgetauscht werden kann.

Baseline

Als "Baseline" wird eine genau spezifizierte Menge an Produkten (Dokumente, Software und Hardware) zu einem definierten Zeitpunkt verstanden, die im Rahmen des Konfigurationsmanagements verwaltet werden und die eine verläßliche Basis für das (arbeitsteilige) Weiterarbeiten bilden.

Hinweis:

Baselines markieren "Reifezustände" (Anforderungen, Lösungskonzept, Entwurf, Liefereinheit) eines Entwicklungsgegenstandes.

Bedrohung

Unter "Bedrohung" versteht man einen Umstand oder ein Ereignis, das die Einhaltung der Sicherheitspolitik und der Schutzziele an das IT-System gefährden kann.

Bedrohungsanalyse

In der Bedrohungsanalyse sind die für das System relevanten Bedrohungen unter Berücksichtigung der (vorgesehenen) Einsatzumgebung zu ermitteln und hinsichtlich ihrer Bedeutung (Art des zu erwartenden Schadens) zu bewerten.

Benutzbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken

−	auf den Aufwand, der zur Benutzung erforderlich ist und

−	auf die individuelle Beurteilung einer solchen Benutzung

durch eine festgelegte oder vorausgesetzte Gruppe von Nutzern.

Daten

Angaben, Tatsachen und Informationen oder deren kodierte Form.

Datenbank

Eine Datenbank ist die Menge der Daten, die gemäß den formalen Regeln eines zugehörigen Datenbankschemas organisiert sind und die durch ein Datenbanksystem verwaltet werden.

Datenbanksystem

Ein Datenbanksystem (Datenbank-Managementsystem, DBMS) übernimmt die technische Organisation und Bereitstellung von Daten, die in einer Datenbank abgelegt sind.

Datensicherheit

Zustand, bei dem Daten vor Beeinträchtigung bewahrt sind. Die Beeinträchtigung kann durch unerlaubtes Lesen, Kopieren, Modifizieren oder Löschen der Daten geschehen.

(Die Datensicherheit ist von der Systemsicherheit zu unterscheiden.)

Datenstruktur

Eine Datenstruktur definiert die Gliederung der von einem System, Segment oder einer SW-Einheit/HW-Einheit benutzten Daten und deren Beziehungen untereinander.

Durchführungsplan

Darstellung der Reihenfolge, zeitlichen Lage und Dauer der Tätigkeiten, die zur Realisierung eines Vorhabens unter Berücksichtigung der notwendigen und/oder verfügbaren Einsatzmittel erforderlich sind. Als Grundlage dient der Strukturplan.

Effizienz

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf das Verhältnis zwischen dem Leistungsniveau der Funktionseinheit und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen.

Einsatzmittel

Leistungsfaktoren wie Arbeitskräfte, Geräte, Maschinen und sonstige technische Anlagen und Hilfsmittel sowie Kombinationen hieraus, über die eine Stelle verfügt und die bei der Erbringung einer Leistung nicht verbraucht, sondern nur in Anspruch genommen und zur Durchführung eines Vorhabens benötigt werden.

Element der Systemarchitektur

Synonym: Funktionseinheit, Baustein

Ein nach Aufgabe oder Wirkung abgrenzbares Gebilde.

Ein Element kann ein System, ein Segment, eine SW-Einheit/HW-Einheit, eine SW-Komponente, ein SW-Modul oder eine Datenbank sein.

Evaluation

Prüfung und Bewertung eines Systems anhand der IT-Sicherheitskriterien. Die Evaluationsstellen können neben der Evaluation eines fertigen Produkts auch begleitende Evaluationen durchführen, d. h. die einzelnen Prüfschritte werden während des Entwicklungsprozesses durchgeführt, sobald die entsprechenden Zwischenergebnisse den Zustand "akzeptiert" haben.

Evolutionäre Akquisition

Synonym: Evolutionäres Prototyping

Auf der Basis einer ersten Version der Anwenderforderungen, die den funktionalen Systemkern beschreibt und den Gesamthorizont des Systems vorgibt, wird eine operative, erste Systemversion akquiriert.

Zukünftige Ergänzungen und Änderungen der Anwenderforderungen sind zu diesem Zeitpunkt nicht vollständig absehbar.

Die erste Systemversion wird in weiteren Akquisitionsschritten bis zum endgültigen System ausgebaut, wobei die Anwenderforderungen in allen Teilen ergänzt und geändert werden können.

Exploratives Prototyping

Entwicklung eines Prototypen als Kommunikationsmedium. Im direkten Meinungsaustausch mit dem Anwender werden anhand des Prototypen die Anwenderforderungen verfeinert, ergänzt und geklärt.

Experimentelles Prototyping

Entwicklung, um durch Versuche technische Eigenschaften eines Systems oder Systemteils (z. B. als Entscheidungsgrundlage) zu ermitteln.

Fehlverhalten

−	Funktionsversagen, d. h. Versagen einer Funktionseinheit bei ihrer Ausführung,

−	Funktionsunterlassung, d. h. Unterlassung einer erforderlichen Ausführung oder

−	modifizierte Ausführung (z. B. Mehrfunktionalität).

Fertigprodukt

Komplett verfügbare Funktionseinheit (verfügbar im eigenen Unternehmen, im Amtsbereich oder auf dem Markt).

Festspeicher

Speicher, dessen Inhalt betriebsmäßig nicht geändert werden kann.

Firmware

Computerbefehle oder -daten, die als nur lesbare Information in einem Festspeicher gespeichert sind.

Forderungscontrolling

Das Forderungscontrolling analysiert die aufgestellten Anwenderforderungen hinsichtlich Realisierbarkeit und Wirtschaftlichkeit und basiert zumindest auf ersten Architekturüberlegungen. Die Ergebnisse der Analyse führen gegebenenfalls zu Vorschlägen für Modifikation/Reduzierung von Anwenderforderungen.

Funktionalität

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf das Vorhandensein eines Satzes von Funktionen und auf deren festgelegte Eigenschaften. Die Funktionen sind jene, die die festgelegten oder vorausgesetzten Erfordernisse erfüllen.

Anmerkung:

Diese Menge von Eigenschaften charakterisiert, was eine Funktionseinheit zur Erfüllung von Erfordernissen tut, während die anderen Qualitätsmerkmale hauptsächlich charakterisieren, wann und wie sie das tut.

Funktionseinheit

Synonym: Element der Systemarchitektur

Ein nach Aufgabe oder Wirkung abgrenzbares Gebilde.

Eine Funktionseinheit kann ein System, ein Segment, eine SW-Einheit/HW-Einheit, eine SW-Komponente, ein SW-Modul oder eine Datenbank sein.

Funktionsstruktur

Eine Funktionsstruktur definiert die (statische) Gliederung der Funktionalität eines Systems, Segments oder einer SW-Einheit/HW-Einheit in Funktionen.

Gesamthorizont

Fachliche, anwenderorientierte Beschreibung des Funktionsumfangs des IT-Systems unter Nennung der darin enthaltenen (Funktions-) Bereiche (z. B. Mail, Nutzerverwaltung). Die Beschreibung muß so detailliert sein, daß darüber entschieden werden kann, welche Funktionsteile innerhalb des Gesamthorizonts liegen.

Geschäftsprozeß

Kette der Aufgaben, die ein geschäfts- bzw. aufgabenrelevantes Ergebnis erzeugen (Arbeitsgangfolge).

Hardware

Gesamtheit oder Teil der apparativen Ausstattung von Datenverarbeitungssystemen.

Hardware-Einheit (HW-Einheit)

Element der Erzeugnisstruktur, das ausschließlich aus Hardware besteht.

Hauptaktivität

Aktivität der obersten Ebene im V-Modell.

Hardware-Komponente (HW-Komponente)

Hardware-Baustein einer HW-Einheit. HW-Komponenten können ihrerseits andere HW-Komponenten und HW-Module enthalten.

Hinweis:

Die Definition wurde in Analogie zu "SW-Komponente" getroffen.

Hardware-Modul (HW-Modul)

HW-Module sind die kleinsten Bausteine einer HW-Einheit, deren Behandlung noch durch das V-Modell geregelt wird.

Hinweis:

Der Begriff wurde in Analogie zur Definition von "SW-Modul" getroffen. HW-Module grenzen sich von HW-Bauteilen (unterste Betrachtungsebene; nicht mehr durch das V-Modell geregelt) dadurch ab, daß sie im Rahmen einer Entwicklung tatsächlich bearbeitet werden, d. h. sie haben insbesondere die Bearbeitungszustände "geplant", "in Bearb.", "vorgelegt", "akzeptiert" gemäß V-Modell.

Individuelles IT-System

Ein individuelles IT-System zeichnet sich durch folgende Bedingungen aus:

−	Es wird nur vom Ersteller selbst genutzt.

−	Es operiert auf Datenbeständen, über die der Ersteller die alleinige Verantwortlichkeit hat.

−	Es wird ausschließlich auf der Hardware des Erstellers eingesetzt.

−	Es hat keine besonderen sicherheitsrelevanten bzw. qualitativen Anforderungen zu berücksichtigen.

Inkrementelle Entwicklung

Synonym: Inkrementelles Prototyping

Stufenweise Entwicklung eines Systems (oder von Systemteilen) auf der Basis insgesamt gefestigter Anwenderforderungen.

Instanz, Instantiierung

Bevor eine im V-Modell beschriebene (generische) Aktivität durchgeführt wird, muß sie instantiiert (ausgeprägt) werden. Das Ergebnis der Instantiierung ist die Instanz. Eine Instanz ist der konkrete Bezug einer Aktivität auf ein bestimmtes Objekt (z. B. Modul, Komponente, usw.).

Oben angeführtes gilt auch für Produkte.

Anmerkung:

Werden beispielsweise in Aktivität SE 2 "System-Entwurf" drei SW-Einheiten identifiziert, so muß die Aktivität SE 3 "SW-/HW-Anforderungsanalyse" dreimal instantiiert werden (für jede SW-Einheit separat).

IT-System

Siehe: System

IT-Sicherheitsanteil

(Quelle: ITSEC, angepaßt)

Die Gesamtheit aller Elemente der technischen Architektur, die zum Erreichen der IT-Sicherheitsziele und -anforderungen von Bedeutung sind.

Klassische Akquisition

Synonyme: Big Bang, Grand Design, One Shot

Auf der Basis vollständiger Anwenderforderungen wird ein System oder Systemteil in einem Schritt akquiriert.

Klassische Entwicklung

Synonyme: Wasserfallmodell, Traditionelle Entwicklung, Big Bang, One Shot

Auf der Basis vollständiger und verfeinerter Systemanforderungen wird ein System oder Systemteil in einem Schritt (phasenorientiert) entwickelt.

Konfiguration

Eine Konfiguration ist eine benannte und formal freigegebene Menge von Entwicklungsergebnissen, mit den jeweils gültigen Versionsangaben, die in ihrer Wirkungsweise und ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorgegebene Aufgabe erfüllen sollen.

Hinweise:

Als Entwicklungsergebnisse werden alle Ergebnisse betrachtet, die im Verlauf der SW-Entwicklung nach dem V-Modell entstehen, und nicht nur der freigegebene Code.
Der eindeutige Aufbau von Softwaresystemen erfolgt über eine Konfigurationen-Hierarchie, in der jedes Entwicklungsergebnis genau einer Konfiguration (z. B. durch Eintrag in eine entsprechende Liste) zugeordnet ist. Die Konfigurationen der oberen Ebene stützen sich auf unterliegende Konfigurationen ab. Konfigurationen sowie Versionen können selbst Teil in mehreren Konfigurationen sein.

Der Begriff "Konfiguration" wird oft mit dem Begriff "Rechnerkonfiguration" gleichgesetzt. Bei der Rechnerkonfiguration ist der Schwerpunkt die Ablauffähigkeit von Software beim Rechnereinsatz. Darüber hinaus sind aus SWPÄ-Gesichtspunkten für eine Konfiguration auch diejenigen Informationen relevant, die eine Rolle in der Entwicklung gespielt haben (z. B. die beteiligten Werkzeuge, Compiler, usw.). Dadurch wird sichergestellt, daß jederzeit auf einem konsistenten Stand der Entwicklung aufgesetzt werden kann.

Konfigurationseinheit (KE)

Eine Konfigurationseinheit ist Gegenstand der Aktivitäten des Konfigurationsmanagements (KM) mit abgrenzbaren und zu einem bestimmten Zeitpunkt definierten Eigenschaften (Beschaffenheit und Funktionalität), welche auf möglichst niedriger Ebene unter Berücksichtigung bestimmter Faktoren ausgewählt wird, um den Managementerfordernissen während der Entwicklung und/oder Nutzung zu genügen.

Anmerkung:

Beispiele solcher Faktoren sind Sicherheitsanforderungen, Kostenintensität, Änderungshäufigkeit, Fehlerrate, kommerzielle Verfügbarkeit.

Kritikalität

Die Kritikalität einer Einheit drückt aus, welche Bedeutung ihrem Fehlverhalten beigemessen wird.

Die Kritikalität wird in Stufen angegeben, wobei die Einstufung umso höher ist, je gravierendere Auswirkungen bei Fehlverhalten zu erwarten sind.

Anmerkung 1:

Den Kritikalitätsstufen kann ein zu vereinbarender Aufwand gegenübergestellt werden, der in die Realisierung und Prüfung der Einheit investiert werden muß.

Anmerkung 2:

Es ist zweckmäßig, die Kritikalitätsstufen individuell für die verschiedenen Arten von IT-Systemen zu definieren. Darüber hinaus kann es sinnvoll sein, diese Definitionen projektspezifisch (z. B. bzgl. Terminologie) anzupassen.

Lademodul

Softwarebaustein, der in den Speicher geladen werden kann und ablauffähig ist. Üblicherweise enthält das Lademodul hinzugebundene Bibliotheksroutinen.

Meilenstein

Bedeutungsvolles Ereignis (Fertigstellung vorbestimmter Produkte) im Vorhabenablauf, das sich terminlich planen und überwachen sowie zur Bewertung des Vorhabenfortschrittes einsetzen läßt.

Meilensteinplan

Grafische oder tabellarische Darstellung von Meilensteinen im Vorhabenablauf auf der Basis der Terminplanung.

Nachweis

(Quelle: DIN EN ISO 8402)

Information, deren Richtigkeit bewiesen werden kann und die auf Tatsachen beruht, welche durch Beobachtung, Messung, Untersuchung oder durch andere Ermittlungsverfahren gewonnen wird.

Nachweis-Software

Software zur Nachweisführung von Leistungen der operativen Software, der Hardware, des Segments mit IT-Anteil oder des Systems während der Integrationsaktivitäten.

Nutzer

(Quelle: in Anlehnung an den Entwurf DIN 66285 "Anwendungssoftware")

Ein Mensch, der unmittelbar mit einer Sache arbeitet und der Verfügungsgewalt von deren Anwender unterliegt.

Operationelles System

IT-System, das einen Systemauftrag erfüllt. Auf dem operationellen System läuft die operative Software.

Operative Aktivität

Aktivität aus dem Submodell SE oder aus einem operativen Modul.

Operative Software

Software, die zur Erfüllung eines Systemauftrages erforderlich (zur Nutzung des IT-Systems) und im operationellen System installiert ist.

Operatives Modul

Eine Menge von zusammengehörigen, abgrenzbaren Aktivitäten- und Produktklassen, die einen Ausschnitt aus den Regelungen des Submodells SE ersetzen können (Beispiel: Hardwareerstellung). Im Extremfall kann das Submodell SE vollständig ersetzt werden (Beispiel: Reverse Engineering).

Platzhalter

Programm oder Programmteil, das/der während der Integration dazu dient, gewisse Funktions- oder Leistungsmerkmale eines SW-Moduls, einer Datenbank, einer SW-Komponente oder einer SW-Einheit bereitzustellen. Im Sinne des V-Modells kann ein Platzhalter ein Stub oder ein Driver sein:

−	Ein Stub ist ein Platzhalter für ein SW-Modul oder eine oder mehrere SW-Komponenten in einer SW-Teilstruktur. Mit dem Platzhalter wird erreicht, daß die SW-Teilstruktur in gegebenenfalls eingeschränkter Weise übersetzbar oder ausführbar wird. Damit können informelle Prüfungen unter bestimmten Kriterien durchgeführt werden, ohne daß ein SW-Modul, eine SW-Komponente oder eine SW-Einheit komplett vorliegt.

−	Ein Driver (Treiber) ist ein Ablaufsteuerungsprogramm. Es ermöglicht die Ausführung und damit die informelle Prüfung von SW- Teilstrukturen, deren bestimmungsgemäße Ablaufumgebung noch nicht zur Verfügung steht.

Portabilität

Grad der Fähigkeit einer Software, auf andere Computer übertragen zu werden.

Produkt

Bearbeitungsgegenstand bzw. Ergebnis einer Aktivität des V-Modells (Dokument oder Software oder Hardware).

Produktklasse

Eine Reihe von Produkten im V-Modell wird im Rahmen eines konkreten Projekts mehrfach erstellt (z. B. für jede einzelne Komponente, Modul, usw.). Diese Produkte werden im V-Modell als sogenannte "Produktklassen" oder "generische Produkte" nur einmal beschrieben. Ein tatsächlich erstelltes Produkt wird als "Instanz" (auch "Ausprägung") des (generischen) Produkts bezeichnet.

Anmerkung:

Alle Produkte des V-Modells sind in der Regel generische Produkte (d. h. Elemente einer Produktklasse). Siehe auch "Instanz".

Produktprüfung

Prüfung, bei der für ein bestimmtes Produkt (z. B. Dokument, Quellcode, HW) gezeigt werden soll, daß die vorher festgelegten Forderungen erfüllt werden.

Produktschema

Beschreibungsschema, dem ein Produkt genügen muß. Insbesondere sind die Gliederung und der Inhalt des Produkts geregelt.

Produktzustand

Eigenschaft eines Produkts, die dessen Bearbeitungsstadium kennzeichnet. Der Wechsel des Produktzustands wird grundsätzlich durch eine Aktivität ausgelöst. Ein Produkt kann den Zustand "geplant", "in Bearb.", "vorgelegt" und "akzeptiert" annehmen.

Projekt

(Quelle: DIN 69901)

Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.

−	Zielvorgabe,

−	zeitliche, finanzielle, personelle oder andere Begrenzungen,

−	Abgrenzung gegenüber anderen Vorhaben,

−	projektspezifische Organisation.

Projektplanung

Verfahren zur Planung von Organisation, Abläufen, Terminen und Einsatzmitteln.

Prototyp

Eine ausführbare und evaluierbare Version eines Systems oder Systemteils (evolutionärer Prototyp) oder eines Werkzeugs, um ausgewählte Merkmale des späteren, operationellen Systems (explorativer oder experimenteller Prototyp) zu evaluieren.

Hinweis:

Für die Erstellung eines Prototypen wird nicht die Erfüllung der Regelungen des V-Modells gefordert. Bei der Integration des Prototypen in das operationelle System muß geklärt werden, welche Nacharbeiten zur Erfüllung der relevanten Anwenderforderungen (insbesondere der Qualitätsanforderungen) notwendig sind.

Prototyping

Vorgehensweise, deren Arbeitsschritte die Entwicklung, Evaluierung und Weiterentwicklung von Prototypen zum Gegenstand haben.

Prozeßprüfung

Synonym: Ablaufprüfung

(Quelle: DIN 55350)

Qualitätsprüfung an einem Prozeß bzw. an einer Tätigkeit anhand der Merkmale des Prozesses bzw. der Tätigkeit selbst.

Anmerkung 1:

Prozeßprüfungen dienen unter anderem der Verfahrensüberwachung.

Anmerkung 2:

Der Prozeß in dem hier verwendeten Sinne unterscheidet sich von dem "Software-Prozeß" innerhalb der operativen Software.

Prüfbarkeit eines HW-Bausteins

Die Prüfbarkeit eines HW-Bausteins gibt die Eignung oder den Grad der Eignung an, daß/inwieweit durch interne und/oder externe Prüfvorkehrungen festgestellt werden kann, ob der Baustein funktionstüchtig ist.

Prüfkriterien

Prüfkriterien sind Fragestellungen, die durch eine Prüfung geklärt werden sollen.

Bei der Prüfung von Papierprodukten sollten als Prüfkriterien Checklisten verwendet werden (Beispiele hierfür in Abschnitt 8 beim Produktmuster Prüfspezifikation).

Wichtig bei der Formulierung der Prüfkriterien ist, daß die Erfüllung des Kriteriums in der Prüfung entscheidbar ist.

Prüfung

(Quelle: DIN EN ISO 8402)

Eine Tätigkeit wie Messen, Untersuchen, Ausmessen von einem oder mehreren Merkmalen einer Einheit sowie Vergleichen mit festgelegten Forderungen um festzustellen, ob Konformität für jedes Merkmal erzielt ist.

Anmerkung:

Prüfung ist ein Oberbegriff für alle analytischen Maßnahmen, die Nachweischarakter haben, unabhängig von Methode oder Prüfgegenstand.

Pseudocode

Sprachliches Ausdrucksmittel für den Programmentwurf. Enthält üblicherweise Konstrukte der Strukturierten Programmierung und natürlichsprachliche Beschreibungen.

Qualifikation

(Quelle: DIN EN ISO 8402)

Prozeß um nachzuweisen, daß eine Einheit fähig ist, die spezifizierten Anforderungen zu erfüllen.

Qualität

(Quelle: DIN EN ISO 8402)

Die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.

Anmerkung 1:

Einheit kann sein: Tätigkeit, Prozeß, Produkt, System, Organisation, Person.

Anmerkung 2:

Das V-Modell beschränkt sich auf das jeweilige Vorhaben und die dafür festgelegten Anforderungen. Sollten im Verlauf des Vorhabens vorausgesetzte Anforderungen neu erkannt werden, sind diese wie Änderungen zu behandeln.

Qualitätsforderung

(Quelle: DIN EN ISO 8402)

Eine Formulierung der Erfordernisse oder deren Umsetzung in eine Serie von quantitativ oder qualitativ festgelegten Forderungen an die Merkmale einer Einheit zur Ermöglichung ihrer Realisierung und Prüfung.

Qualitätsmanagement

(Quelle: DIN EN ISO 8402)

Alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantwortungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen.

Anmerkung:

Das V-Modell beschränkt sich auf einzelne Vorhaben. Deshalb ist im Einzelfall der Bezug zum QM-System zwar gegeben, aber im V-Modell nicht festgelegt.

Qualitätssicherung

(Quelle: DIN EN ISO 8402)

Alle geplanten und systematischen Tätigkeiten, die innerhalb des Qualitätsmanagementsystems verwirklicht sind, und die wie erforderlich dargelegt werden, um angemessenes Vertrauen zu schaffen, daß eine Einheit die Qualitätsforderung erfüllen wird.

Anmerkung: siehe Qualitätsmanagement

Qualitätsmaße

Meßbare Größen, die Rückschlüsse auf die Ausprägung bestimmter Qualitätsmerkmale gestatten.

(Beispiele: Antwortzeit für Funktion ... ist kleiner als ... Sekunden, Länge des Moduls ... ist kleiner als ... Seiten.)

Qualitätsmerkmale

(Quelle: in Anlehnung an DIN ISO 9126)

Eigenschaften einer Funktionseinheit, anhand derer ihre Qualität beschrieben und beurteilt wird, die jedoch nichts über den Grad der Ausprägung aussagen. Ein Qualitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden.

Qualitätsmerkmale sind Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.

Randbedingungen

Technische und organisatorische Vorgaben, die im Rahmen der Systemerstellung zu berücksichtigen sind. Randbedingungen können Entwurfsentscheidungen vorwegnehmen oder eingrenzen.

Risikoanalyse

In der Risikoanalyse wird untersucht, wie wahrscheinlich es ist, daß eine der ermittelten Bedrohungen wirksam wird und wie hoch der Schaden ist, der dabei entsteht. Das Risiko wird aus der Eintrittswahrscheinlichkeit und der zu erwartenden Schadenshöhe ermittelt.

Rolle

Eine Funktion, in der ein Bearbeiter eine bestimmte Aktivität ausführt.

Hinweis:

Durch die Festlegung von Rollen wird die Unabhängigkeit des V-Modells von organisatorischen und projektspezifischen Randbedingungen erreicht. Die Zuordnung von Organisationseinheiten und Personen zu den Rollen erfolgt zu Beginn eines Projekts.

Schnittstelle

Gedachter oder tatsächlicher Übergang an der Grenze zwischen zwei Funktionseinheiten mit den vereinbarten Regeln für die Übergabe von Daten oder Signalen.

Segment

Unterstruktur eines Systems. Es gibt Segmente mit IT-Anteil (auch: IT-Segment) und solche ohne IT-Anteil.

Selbstprüfung

(Quelle: DIN EN ISO 8402)

Prüfung des Arbeitsergebnisses durch den Ausführenden selbst gemäß festgelegter Regeln.

Anmerkung:

Selbstprüfungen finden im Rahmen des Submodells SE statt.

Software

Programme für Datenverarbeitungssysteme, die zusammen mit deren Eigenschaften zusätzliche Betriebsarten oder Anwendungsarten ermöglichen. Software umfaßt die Computerprogramme mit den zugehörigen Daten und der Dokumentation.

Softwarebaustein

Ein nach Aufbau oder Zusammensetzung abgrenzbares programmtechnisches Gebilde. Ein Softwarebaustein kann ein SW-Modul, eine Datenbank, eine SW-Komponente oder eine Software-Konfigurationseinheit sein.

Software-Einheit (SW-Einheit)

Element der Erzeugnisstruktur, das ausschließlich aus Software besteht.

Software-Komponente (SW-Komponente)

Softwarebaustein einer SW-Einheit. SW-Komponenten können ihrerseits andere SW-Komponenten, SW-Module und/oder Datenbanken enthalten.

Software-Modul (SW-Modul)

SW-Module sind die kleinsten zu programmierenden Softwarebausteine einer SW-Einheit, deren Behandlung noch durch das V-Modell geregelt wird.

Hinweise:

Das V-Modell geht nicht auf den technischen Inhalt eines SW-Moduls ein. Es wird angenommen, daß ein SW-Modul anhand folgender Kriterien gebildet wird: Abgeschlossenheit, Geheimnisprinzip, Datenabstraktion, Kapselung, Schnittstellenspezifikation, Schnittstellenminimalität, Überschaubarkeit, Testbarkeit, usw.

Die Programmiersprache Ada bietet zur Implementierung von SW-Modulen das Paketkonzept an (natürlich können auch Unterprogramme oder Tasks benutzt werden).

Software-Pflege und -Änderung

Alle Maßnahmen, die ergriffen werden,

−	um eine zur Benutzung freigegebene Programmausstattung funktionsfähig zu erhalten, ohne daß Spezifikationen geändert oder erweitert werden (Software-Pflege),

−	um eine Änderung oder Erweiterung der Spezifikationen in einer zur Benutzung freigegebenen Programmausstattung zu berücksichtigen (Software-Änderung).

Submodell

Ein aus einer bestimmten Sicht abgeschlossenes Teilmodell des V-Modells. Das V-Modell besteht aus den Submodellen

−	Systemerstellung (SE)

Submodell, in dem die Erstellung eines IT-Systems geregelt wird. Die Erstellung der Software erfolgt unter Berücksichtigung der Schnittstelle zur Hardware.

−	Qualitätssicherung (QS)

Submodell, in dem die präventiven Maßnahmen zur Erreichung der Qualitätsziele und zur Vermeidung von Qualitätsrisiken sowie die analytischen Maßnahmen zum Nachweis der geforderten Qualität beschrieben werden.

Anmerkung:

Das Submodell QS umfaßt

−	Planung von präventiven, konstruktiven und analytischen Maßnahmen;

−	Vorbereitung, Sicherstellung, Durchführung und Berichtswesen für die analytischen Maßnahmen,

und bezieht sich auf

−	Organisation,

−	Prozesse und

−	Produkte.

−	Konfigurationsmanagement (KM)

Submodell, in dem die Verwaltung der während der Systementwicklung anfallenden Produkte aller vier Submodelle geregelt wird. Ihre verschiedenen Versionen und Beziehungen zueinander werden konsistent gehalten, Änderungen überwacht und Zugriffe kontrolliert.

−	Projektmanagement (PM)

Submodell, in dem alle technischen Aspekte der Projektabwicklung geregelt werden. Dazu gehören Planung, Steuerung und Kontrolle aller projektinternen Tätigkeiten sowie projektinterne und projektexterne (z. B. mit Auftraggeber, Anwender) Kommunikation. Nicht abgedeckt sind jedoch System-Management und Finanzplanung.

SW-Teilstruktur

Teil einer (zu erstellenden) SW-Einheit, der einen beliebigen Ausschnitt aus der zukünftigen Software-Architektur darstellt. Dies kann eine SW-Komponente, ein SW-Modul, eine Datenbank oder ein Aggregat von bereits (teil-) integrierten SW- Teilstrukturen sein.

SWPÄ-Software

Software zur Fehlerdiagnose und -lokalisierung in der operativen Software (u. U. auch der HW).

System

(Quelle: ISO/IEC 12207)

Einheitliches Ganzes, das aus einem oder mehreren Prozessen, Hardware, Software, Einrichtungen und Personen besteht, das die Fähigkeit besitzt, vorgegebene Forderungen oder Ziele zu befriedigen.

Für das V-Modell werden nur Systeme betrachtet, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Für derartige Systeme wird abkürzend der Begriff "IT-System" verwendet.

Systemarchitektur

Die Systemarchitektur beschreibt den statischen Aufbau eines Systems als vernetzte Struktur, mit den Elementen der generischen Erzeugnisstruktur. Betrachtet werden dabei die Elemente der Erzeugnisstruktur bis einschließlich der SW-Einheiten/HW-Einheiten. Die Architekturen der SW-Einheiten und HW-Einheiten finden sich in den zugehörigen Architekturdokumenten.

Systemsicherheit

Fähigkeit einer Funktionseinheit, innerhalb vorgegebener Grenzen für eine gegebene Zeitdauer kein Fehlverhalten zu bewirken oder eintreten zu lassen.

(Die Systemsicherheit ist von der Datensicherheit zu unterscheiden.)

Szenario

Beispielhafte Darstellung und Erläuterung einer Entwicklungsstrategie als Ausprägung des V-Modells.

Technische Anforderungen

Ergänzende und interpretierende Forderungen, die aus der technischen Sicht an die Elemente der technischen Architektur gestellt werden.

Anmerkung:

Die Gesamtheit der Forderungen an ein IT-System ergibt sich aus den Anwenderforderungen und den daraus abgeleiteten Technischen Anforderungen.

Testabdeckung

Ausmaß der Testfälle, mit denen ein Programm oder Programmteil getestet wird. Man unterscheidet zwischen den Abdeckungen C0 bis C7, wobei die gebräuchlichsten Testabdeckungen C0, C1 und C2 sind.

C0:	Jede Anweisung wird mindestens einmal durchlaufen.

C1:	Jeder Programmzweig wird mindestens einmal durchlaufen (z. B. erfordert die bedingte Anweisung if ... then ... endif zwei Testfälle).

C2:	Bei zusammengesetzten Bedingungen in bedingten Anweisungen wird jede Bedingung (wahr, falsch) getestet.

Übertragbarkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auswirken auf die Eignung der Funktionseinheit, von einer Umgebung (organisatorische Umgebung, Hardware- oder Softwareumgebung) in eine andere übertragen zu werden.

Unterbrechung

In einem Prozessor das Anhalten eines Prozesses durch ein Signal derart, daß ein anderer vorrangiger Prozeß abläuft und der angehaltene Prozeß zu einem späteren Zeitpunkt fortgesetzt werden kann.

Unterstützungs-Software

Software zur Entwicklung und Pflege/Änderung der operativen Software (Synonym: Werkzeug).

Validierung

(Quelle: DIN EN ISO 8402)

Bestätigen aufgrund einer Untersuchung und durch Führung eines Nachweises, daß die besonderen Forderungen für einen speziellen vorgesehenen Gebrauch (Erwartungshaltung des Anwenders) erfüllt worden sind.

Anmerkung:

Eine Validierung kann durchgeführt werden

−	in Form einer Prüfung des Endproduktes gegen die Erwartung des Anwenders,

−	in Form einer Simulation auf der Basis von Zwischenergebnissen, bei der der Anwender einbezogen wird und

−	als Prüfschritt im Rahmen einer Durchführungsentscheidung am Ende einer Entwicklungsstufe bei inkrementeller Systementwicklung.

Variante

Varianten sind zeitgleich nebeneinander liegende Ausprägungen von Produkten.

Verfügbarkeit

Wahrscheinlichkeit, ein System zu einem vorgegebenen Zeitpunkt in einem funktionsfähigen Zustand anzutreffen.

Verifizierung

(Quelle: DIN EN ISO 8402)

Bestätigen aufgrund einer Untersuchung und durch Führung eines Nachweises, daß die festgelegten Forderungen erfüllt worden sind.

Anmerkung:

Die Verifizierung kann als Prozeß- oder Produktprüfung durchgeführt werden.

Version

Alle Produkte einer Konfiguration (Software, Dokumente) besitzen eine individuelle Versionsangabe (Beispiele: a, b, c; 1.2, 1.3, 1.4). Jede formale oder inhaltliche Änderung an einem Konfigurationsprodukt bewirkt eine Erhöhung der Versionsangabe. Unter "Versionen" werden zeitlich nacheinander liegende Ausprägungen eines Produkts verstanden.

V-Modell

Regelungen, die die Gesamtheit aller Aktivitäten, Produkte und deren logische Abhängigkeiten bei der Entwicklung und Pflege/Änderung von Systemen, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird, im Bereich der Bundesverwaltung festlegen.

Vor Ort austauschbare Einheit

Engl. "Field Replaceable Unit" (FRU)

Eine vor Ort austauschbare Einheit ist eine austauschbare Einheit, die im zur Benutzung freigegebenen System ausgetauscht werden kann.

Zertifikation

Verwaltungsmaßnahmen zur Erlangung der Zulassung einer Funktionseinheit durch eine unabhängige Organisation zu einem bestimmten Einsatzzweck.

Zugesicherte Eigenschaften

Vertraglich vereinbarte, zu validierende Anwenderforderungen.

Zuverlässigkeit

(Quelle: in Anlehnung an DIN ISO 9126)

Eine Menge von Eigenschaften, die sich auf die Fähigkeit der Funktionseinheit auswirken, ihr Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren.

Hinweise:

Die Anwendung der Zuverlässigkeitstheorie auf Software ist besonders schwierig. Im zur Zeit vorherrschenden Erfahrungsbereich der Hardware werden Zuverlässigkeitsbetrachtungen mit Ausfällen infolge Alterung oder Verschleiß verbunden. Bei Software finden Verschleiß oder Alterung im engen Sinne nicht statt. Bei ihr werden Einschränkungen der Zuverlässigkeit auf von vornherein vorhandene Konstruktionsfehler zurückgeführt, die sich z. B. wegen der Unvollständigkeit von ins Programm eingebauten Prüfungen in einem Restfehlergehalt niederschlagen, dessen Auswirkungen in einer vorgegebenen Anwendungsdauer ebenso wie Alterungs- und Verschleißausfälle nicht vorhersehbar sind.

Zuverlässigkeit kann in diesem Bereich allerdings auch durch Manipulationen (z. B. Einschleusen von Viren) während der Einsatzdauer reduziert werden.


Abkürzungsverzeichnis (AU250/1)
Teil 1	Anhang zum Regelungsteil (AU250/1)

B	Verzeichnisse

B.1	Abkürzungsverzeichnis

ArbAuf	Arbeitsauftrag

ÄA	Änderungsantrag/Problemmeldung

Äauf	Änderungsauftrag

Ämit	Änderungsmitteilung

Ästat	Änderungsstatusliste

Ävor	Änderungsvorschlag

AFo	Anwenderforderungen

AG	Auftraggeber

AHb	Informationen zum Anwendungshandbuch

AktNo	Aktennotiz

AN	Auftragnehmer

AnaB	Analysebericht

AnBew	Angebotsbewertung

AQAP	Allied Quality Assurance Publication

AT	Ausschreibungsrelevantes Tailoring

BetrHb	Informationen zum Betriebshandbuch

BMVg	Bundesminister der Verteidigung

BSI	Bundesamt für Sicherheit in der Informationstechnik

BWB	Bundesamt für Wehrtechnik und Beschaffung

DatK	Datenkatalog

DB	Datenbank

DBMS	Datenbankmanagementsystem

DiagHb	Informationen zum Diagnosehandbuch

DIN	Deutsches Institut für Normung e.V.

DV	Datenverarbeitung

EinInf	Sonstige Einsatzinformationen

Einl	Einladung

EStdIT	Entwicklungsstandard für IT-Systeme

HAN	Hauptauftragnehmer

HW	Hardware

HwArc	HW-Architektur

ImplD	Implementierungsdokumente

in Bearb.	in Bearbeitung

IntMit	Interne Mitteilung

IntPl	Integrationsplan

IT	Informationstechnik

ITSEC	Information Technology Security Evaluation Criteria
(IT-Sicherheitskriterien)

KBSt	Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung

KID	Konfigurations-Identifikationsdokument

KM	Konfigurationsmanagement

KNA	Kosten-/Nutzenanalyse

KPl	KM-Plan

PAB	Projektabschlußbericht

PHb	Projekthandbuch

PHis	Projekthistorie

PM	Projektmanagement

PPl	Projektplan

PROM	Programmable Read Only Memory

Prot	Protokoll

PrPl	Prüfplan

PrProt	Prüfprotokoll

PrProz	Prüfprozedur

PrSpez	Prüfspezifikation

QM	Qualitätsmanagement

QS	Qualitätssicherung

QPl	QS-Plan

RealD	Realisierungsdokumente

SaB	Sachbericht

SE	Systemerstellung

SEU	Softwareentwicklungsumgebung

SSB	Schnittstellenbeschreibung

SStB	Sachstandsbericht

SSÜb	Schnittstellenübersicht

SW	Software

SwArc	SW-Architektur

SwEnt	SW-Entwurf

SWPÄ	Software-Pflege und -Änderung

SWPÄK	SWPÄ-Konzept

SysArc	Systemarchitektur

TAnf	Technische Anforderungen

TT	Technisches Tailoring

UAN	Unterauftragnehmer


Abbildungsverzeichnis (AU250/1)
Teil 1	Anhang zum Regelungsteil (AU250/1)

B	Verzeichnisse

B.2	Abbildungsverzeichnis

Abbildung 2.1:	Erzeugnisstruktur und Anwendungsbereich des V-Modells

Abbildung 2.2:	Randbedingungen zur IT-Systemerstellung

Abbildung 2.3:	Symbole für Aktivitäten und Produkte

Abbildung 2.4:	Zulässige Zustandsübergänge von Produkten

Abbildung 2.5:	Muster eines Produktflusses (Aktivität SE 2.4 "Anwenderforderungen zuordnen")

Abbildung 2.6:	Zusammenspiel der Submodelle

Abbildung 2.7:	Produkte des V-Modells (Produktbaum)

Abbildung 3.1:	Planung einer Systementwicklung

Abbildung 4.1:	Funktionsüberblick Submodell SE

Abbildung 5.1:	Konstruktive und analytische Maßnahmen

Abbildung 5.2:	Begriffshierarchie Prüfung

Abbildung 5.3:	Mögliche Stufen der Abwicklung von Selbstprüfungen

Abbildung 5.4:	Funktionsüberblick Submodell QS

Abbildung 6.1:	Zulässige Zustandsübergänge von zu entwickelnden Produkten

Abbildung 6.2:	Status einer Änderung

Abbildung 6.3:	Funktionsüberblick Submodell KM

Abbildung 7.1:	Funktionsüberblick Submodell PM


Tabellenverzeichnis (AU250/1)
Teil 1	Anhang zum Regelungsteil (AU250/1)

B	Verzeichnisse

B.3	Tabellenverzeichnis

Tabelle 5.1:	Beteiligung von Rollen bei den Prüfaktivitäten

Tabelle 8.1:	Beispiel einer Aktivitäten-/Produktübersicht

Tabelle 8.2:	Beispiel einer Methoden-/Werkzeugzuordnung


Literaturverzeichnis (AU250/1)
Teil 1	Anhang zum Regelungsteil (AU250/1)

B	Verzeichnisse

B.4	Literaturverzeichnis

/AQAP-110/	NATO-Qualitätssicherungs-Forderungen für Entwicklung, Konstruktion und Produktion, 2. Ausgabe, Februar 1995.

/AQAP-150/	NATO-Qualitätssicherungs-Forderungen für Software-Entwicklung, 1. Ausgabe, März 1993.

/AU 220/	BMVg: Bestimmungen für die Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben. Allgemeiner Umdruck 220. September 1994.

/DIN ISO 8402/	DIN EN ISO 8402 − Qualitätsmanagement (Begriffe). August 1995.

/DIN 55350/	DIN 55 350, Teil 17 − Begriffe der Qualitätsprüfungsarten. 1987.

/DIN 66285/	DIN V 66 285 − Anwendungssoftware; Prüfgrundsätze. 1985.

/DIN 69901/	DIN 69901 − Projektwirtschaft; Projektmanagement; Begriffe. 1987.

/DIN ISO 9126/	DIN ISO 9126 − Informationstechnik − Beurteilen von Softwareprodukten, Qualitätsmerkmale und Leitfaden zu deren Verwendung. 1991.

/ISO 9001/	ISO 9001 − Qualitätsmanagementsysteme - Modell zur Darlegung des Qualitätsmanagementsystems in Design/Entwicklung, Produktion, Montage und Kundendienst. Juni 1993.

/ISO/IEC 12207/	ISO/IEC 12 207 − Information Technology − Software life cycle processes. First edition, 1995-08-01.

/IT-Org/	Hinweise zum methodischen Vorgehen beim Einsatz der Informationstechnik in der Bundesverwaltung (IT-Org Hinweise) 012-131-130/13. Version 2.0 08/1990.

/IT-RaKonz/	Gliederung der IT-Rahmenkonzepte. Band 18 der KBSt-Schriftenreihe. 08/1990.

/ITSEC/	BSI: Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (ITSEC). Vorläufige Form der harmonisierten Kriterien.
Juni 1991.

/RTCA-178B/	Radio Technical Commission for Aeronautics: Software Considerations in Airborne Systems and Equipment Certification (RTCA/DO-178A). 1992.


Vorbemerkungen
Teil 3	Vorgehensmodell / Handbuchsammlung

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

BRH.1	Vorbemerkungen

Die Forderungen des Bundesrechnungshofs (BRH) in Kapitel 3.1.2 ("... Die Grundsätze zur Gewährleistung einer einheitlichen und systematischen Vorgehensweise bei der Durchführung von IT-Vorhaben ... sind schriftlich zu regeln.") stellen eine grundsätzliche Forderung nach einem Vorgehensmodell dar. Dies wird weiter präzisiert durch die Dokumentationsforderung in Kapitel 1.4.2 ("... Die Dokumentation muß vollständig sein und ist möglichst überschneidungsfrei zu gestalten. ...").

Das V-Modell deckt jedoch nicht alle Forderungen des BRH ab. Konzipiert wurde es lediglich für die

−	Durchführung und

−	Pflege und Änderung

von IT-Vorhaben/Verfahren.

Daher kann das V-Modell lediglich auf die Kapitel

−	1.4	"Dokumentation",

−	2.1	"Gesamtplanung",

−	3	"IT-Vorhaben",

−	6	"Qualitätssicherung" und

−	7	"Sicherheit beim Einsatz der IT"

angewendet werden. In diesen Kapiteln deckt das V-Modell die Forderungen des BRH vollständig ab.

Im weiteren wird dargestellt, wie das V-Modell die Forderungen des BRH abdeckt und welche V-Modell-Aktivitäten und -Produkte den BRH-Forderungen entsprechen.

Zur Unterscheidung des BRH-Originaltextes und der Kommentierung wird im weiteren ein unterschiedlicher Schrifttyp verwendet. Die BRH-Forderungen sind durch diesen Schrifttyp gekennzeichnet.


Abgleich der BRH-Forderungen und der Regelungen des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

BRH.2	Abgleich der BRH-Forderungen und der Regelungen des V-Modells

Im folgenden werden die BRH-Forderungen mit den Regelungen des V-Modells abgeglichen.

(1) Kapitel 1.4.1	Die Planung und der Einsatz der IT sind zu dokumentieren. Die Dokumentation erstreckt sich auf:

−	die Gesamtplanung für den Einsatz der IT

−	die Durchführung von IT-Vorhaben

−	den Betrieb von IT-Verfahren

Die Gesamtplanung für den Einsatz der IT wird größtenteils durch das IT-Rahmenkonzept abgedeckt. Das V-Modell liefert nur für einzelne IT-Vorhaben Beiträge zum Gesamtplan (vgl. (6)). Die Dokumentation der Durchführung von IT-Vorhaben erfolgt durch die Produkte des V-Modells. Die Dokumentation des Betriebs von IT-Verfahren erfolgt im V-Modell durch die Produkte "Informationen zum Betriebshandbuch" und "Sonstige Einsatzinformationen".

(2) Kapitel 1.4.2	Die IT-Dokumentation muß vollständig sein und ist möglichst überschneidungsfrei zu gestalten. Die Dokumentation muß zeitnah, verständlich und richtig sein und den Nachweis aller Änderungen enthalten.

Dies stellt eine grundsätzliche Forderung nach einem Vorgehensmodell dar.

Das V-Modell gibt einerseits eine vollständige und überschneidungsfreie Dokumentation vor, erlaubt andererseits jedoch auch durch das Tailoring eine flexible Festlegung des angemessenen Umfangs der erforderlichen Dokumentation. Die Forderung nach Vollständigkeit der IT-Dokumentation hebt die Bedeutung des Tailoring-Verfahrens hervor.

(3) Kapitel 1.4.3	Die Erstellung, Pflege und Speicherung der Dokumentation soll aus Gründen der Wirtschaftlichkeit möglichst maschinell unterstützt werden. Es ist sicherzustellen, daß die Dokumentation nur durch hierzu berechtigtes Personal geändert werden kann.

Kapitel 1.4.3 stellt eine Forderung nach einem Konfigurationsmanagement dar. Dies wird durch das Submodell KM des V-Modells abgedeckt. Die entsprechenden Regelungen zum Konfigurationsmanagement finden sich im KM-Plan und können hier individuell auf die jeweiligen Organisationsstruktur abgebildet werden.

(4) Kapitel 1.4.4	Allen an der Durchführung von IT-Vorhaben und am Betrieb von IT-Verfahren beteiligten Stellen und Mitarbeitern müssen die für die Arbeitserledigung benötigten Teile der Dokumentation nach dem letzten Stand als Mehrausfertigung zur Verfügung stehen.

Diese Forderung ist vorhabensspezifisch durch organisatorische Regelungen zu erfüllen. Zur Erreichung von aktuellen Dokumentenversionen ist eine funktionierende Konfigurationsverwaltung (Submodell KM) erforderlich.

(5) Kapitel 1.4.5	Die Einzelheiten der Gestaltung, der Erstellung und des Inhalts sowie der Verteilung und der Aufbewahrung der Dokumentation sind - gegebenenfalls im Rahmen geltender Vorschriften - im einzelnen schriftlich zu regeln.

Erstellung und Inhalt der Dokumentation sind durch das V-Modell geregelt (Aktivitäten-, Produktbeschreibungen). Einzelheiten bezüglich der Gestaltung der Dokumentation (z. B. Dokumentationsstandard) sind im Projekthandbuch zu regeln.

Die Verteilung der Dokumentation wird im Projekthandbuch in den Kapiteln 7.3 "Externe Schnittstellen" und 7.4 "Berichtswesen" geregelt.

Einzelheiten bezüglich der Aufbewahrung der Dokumentation werden im KM-Plan in den Kapiteln 2.1 "Produktbibliothek" und 4 "Sicherung und Archivierung" festgelegt.

(6) Kapitel 2	Der Einsatz der IT ist auf der Grundlage einer Gesamtplanung vorzunehmen. Der Gesamtplan soll je nach Planungs- und Entwicklungsstand ausweisen:

−	Organisation, bestehende IT-Verfahren und technische Einrichtungen sowie eingesetztes IT-Fachpersonal,

−	allgemeine Darstellung und absehbare Entwicklung der Aufgaben, die mit Hilfe der IT erledigt werden sollen,

−	Berührungspunkte und Überschneidungen zwischen diesen und mit anderen Aufgaben und Aufgabenfeldern,

−	Ziele des geplanten IT-Einsatzes,

−	geplante und in der Durchführung befindliche IT-Vorhaben einschließlich ihrer Prioritäten sowie ihrer organisatorischen und personellen Auswirkungen,

−	Zeitbedarf für die Realisierung der IT-Vorhaben,

−	Einführungsstrategien und Schulungsmaßnahmen,

−	Planungen und Maßnahmen für die Sicherheit beim Einsatz der IT,

−	Aussagen zur Wirtschaftlichkeit,

−	Bedarf an Haushaltsmitteln.

Bei der Gesamtplanung sind Normen, Standards und geltende Festlegungen zu beachten. Die Gesamtplanung muß regelmäßig überprüft und fortgeschrieben werden.

Durch die Gesamtplanung und eine zweckmäßige Koordinierung ist insbesondere sicherzustellen, daß

−	die mehrfache Entwicklung von IT-Verfahren für gleichartige Aufgaben unterbleibt,

−	einheitliche Verfahren angewendet und Verbundlösungen angestrebt und

−	die Ressourcen im IT-Bereich wirtschaftlich genutzt werden.

Das V-Modell bezieht sich immer nur auf ein einzelnes IT-Vorhaben. Für ein einzelnes IT-Vorhaben liefert das V-Modell Beiträge zu den folgenden Punkten des Gesamtplans:

−	Organisation/eingesetztes IT-Fachpersonal (Projekthandbuch)

−	Ziele des geplanten IT-Einsatzes (Projekthandbuch)

−	Zeitbedarf für die Realisierung der IT-Vorhaben (Projektplan)

Projektübergreifende Forderungen werden durch das IT-Rahmenkonzept erfüllt.

(7) Kapitel 3.1.1	IT-Vorhaben beinhalten die Konzeption, die Entwicklung, die Einführung und wesentliche Änderungen von IT.

Diese Aussage deckt sich mit der Zielsetzung und Anwendung des V-Modells.

(8) Kapitel 3.1.2	Die Grundsätze zur Gewährleistung einer einheitlichen und systematischen Vorgehensweise bei der Durchführung von IT-Vorhaben, einschließlich der Bildung sachgerechter Abschnitte mit entsprechenden Teilzielen, sind schriftlich zu regeln. Dabei sind eine zweckmäßige Vorhabenssteuerung und -überwachung vorzusehen sowie Festlegungen über den Einsatz standardisierter Arbeitstechniken (Methoden und Werkzeuge) zu treffen.

Obige Forderungen stellen eine grundsätzliche Forderung nach dem Einsatz eines Vorgehensmodells dar. Die Forderung nach einer Vorhabenssteuerung und -überwachung wird speziell durch das Submodell Projektmanagement erfüllt. Der Einsatz standardisierter Arbeitstechniken ist im Rahmen der Hausstandards im IT-Rahmenkonzept zu regeln. Festlegungen über den projektspezifischen Einsatz standardisierter Arbeitstechniken (Methoden und Werkzeuge) werden im Projekthandbuch dokumentiert.

(9) Kapitel 3.2.1	Bei Beginn eines IT-Vorhabens sind die Zuständigkeiten und die Vorgehensweise festzulegen. Soweit mehrere Stellen zuständig sind, sind Beteiligung und Verantwortung im einzelnen zu regeln.

Die Festlegung der Zuständigkeiten und der Vorgehensweise erfolgt im Projekthandbuch. Die Festlegung der zeitlichen Zusammenhänge erfolgt im Projektplan. KM- und QS-spezifische Festlegungen werden darüberhinaus auch noch im KM-Plan bzw. im QS-Plan dokumentiert.

Das Zusammenwirken mit mehreren Auftragnehmern wird im Handbuch "UMF" in dem Abschnitt "Verwendungsformen des V-Modells" erläutert. Getroffene Regelungen werden in einem oder gegebenenfalls mehreren Projekthandbüchern dokumentiert.

(10) Kapitel 3.2.2	Grundlage für ein IT-Vorhaben ist der IT-Gesamtplan. Ein IT-Vorhaben soll grundsätzlich umfassen:

−	Vor- und Hauptuntersuchung und

−	Ausführung des Vorhabens.

Obige Forderung wird durch ein Phasenmodell erfüllt (z. B. Phasenmodell nach BVB [zukünftig EVB], AU 220).

(11) Kapitel 3.3.1	Vor der Ausführung eines IT-Vorhabens sind grundsätzlich eine Vor- und eine Hauptuntersuchung durchzuführen.

Obige Forderung wird durch ein Phasenmodell erfüllt (z. B. Phasenmodell nach BVB [zukünftig EVB], AU 220).

(12) Kapitel 3.3.2	Zweck der Voruntersuchung ist es, überschlägig festzustellen, ob und durch welche Lösungsvarianten der Einsatz von IT zur Erfüllung einer Aufgabe fachlich und technisch durchführbar, zweckmäßig und wirtschaftlich ist. Auf dieser Grundlage ist zu entscheiden, ob und für welche Lösungsvarianten eine Hauptuntersuchung gerechtfertigt ist.

Diese Forderung wird durch die Aktivitäten SE 1.7 "Forderungscontrolling durchführen" und SE 2.3 "Realisierbarkeit untersuchen" erfüllt.

(13) Kapitel 3.3.3	Zweck der Hauptuntersuchung ist es, aufbauend auf den Ergebnissen der Voruntersuchung, ins Einzelne gehende Untersuchungen durchzuführen.

Obige Forderung wird durch ein Phasenmodell erfüllt (z. B. Phasenmodell nach BVB [zukünftig EVB], AU 220).

(14) Kapitel 3.3.4	Vor- und Hauptuntersuchungsbericht sollen in entsprechend grober bzw. detaillierter Form insbesondere enthalten:

−	Bezeichnung des Vorhabens, Bearbeiter oder Arbeitsgruppe,

−	Zielsetzung, Inhalt und Umfang des Vorhabens,

−	Ist-Analyse mit einer Beschreibung und Bewertung der gegenwärtigen Aufbau- und Ablauforganisation aus technischer und organisatorischer Sicht,

−	Darstellung der Gestaltungsalternativen unter Berücksichtigung des Einsatzes vorhandener Verfahren oder Verfahrensteile sowie von Standard- oder Fremdsoftware und mögliche Übernahme von Datenbeständen,

−	Soll-Vorschlag mit einem Entwurf der neuen Aufbau- und Ablauforganisation, zu beachtender oder zu ändernder Vorschriften, Beschreibung des system-technischen Konzepts und der Anforderungen an die Hardware-Konfiguration und die System- und Anwendersoftware, Entwurf der Datenbasis (u. a. Datenorganisation, Mengengerüst), des Datenflusses und der Informationsbeziehungen,

−	Darlegung der aus einer Risikoanalyse abgeleiteten Maßnahmen zur Gewährleistung von Ordnungsmäßigkeit und Sicherheit des Verfahrens,

−	Zeit-, Personal- und Sachmittelbedarf für die Durchführung des Vorhabens einschließlich der Schulungsmaßnahmen, der räumlichen Ausstattung, etwaiger baulicher Maßnahmen und für den Verfahrensbetrieb,

−	Wirtschaftlichkeitsuntersuchung sowie in geeigneten Fällen eine Nutzen-Kosten-Untersuchung.

Beiträge zu diesen Berichten liefern insbesondere die Aktivitäten SE 1 "System-Anforderungsanalyse", SE 2 "System-Entwurf", PM 1 "Projektinitialisierung", PM 4 "Feinplanung" und PM 5 "Kosten-/Nutzenanalyse".

(15) Kapitel 3.3.5	Vor- und Hauptuntersuchung können − soweit dies sachlich gerechtfertigt ist − unter Darlegung der Gründe zusammengefaßt werden.

Diese Aussage stellt keine Forderung dar.

(16) Kapitel 3.3.6	Die Ergebnisse der Vor- und der Hauptuntersuchung sind jeweils in einem Bericht zu dokumentieren. Die Berichte enden mit einem Entscheidungsvorschlag. Die Entscheidung ist schriftlich festzuhalten.

Obige Forderung wird durch ein Phasenmodell erfüllt (z. B. Phasenmodell nach BVB [zukünftig EVB], AU 220).

(17) Kapitel 3.4.1.1	Aufgrund des Ergebnisses der Hauptuntersuchung ist über die Ausführung eines IT-Vorhabens zu entscheiden. Die Ausführung umfaßt insbesondere

−	Beschaffung von Hard- und Software,

(Regelung hierzu in Aktivität PM 2 "Vergabe/Beschaffung".)

−	Vergabe von Entwicklungsaufträgen und/oder Verfahrensentwicklung einschließlich Programmierung,

(Regelung hierzu in Aktivität PM 2 "Vergabe/Beschaffung".

Bei Beteiligung von externen Auftragnehmern an Entwicklungsteilen finden sich weitere Regelungen im QS-Plan in dem Kapitel 5.2 "Kontrolle von Unterauftragnehmern". Bei vollständiger Vergabe wird das Projekthandbuch zum Vertragsgegenstand.)

−	Test und Freigabe sowie

(Vereinbarungen hierzu werden im QS-Plan in den Kapiteln 4 "Entwicklungsbegleitende Qualitätssicherung" und 5.3 "Ausgangskontrolle der Softwarebausteine" festgelegt.)

−	Einführung des Verfahrens

(Regelung hierzu in Aktivität SE 9 "Überleitung in die Nutzung".)

(18) Kapitel 3.4.1.2	Die Einzelheiten der Ausführung eines IT-Vorhabens sind jeweils zu dokumentieren.

Die gesamte Dokumentation der Ausführung eines IT-Vorhabens wird durch das V-Modell geregelt. Die Information, welche Dokumente für ein bestimmtes Verfahren relevant sind, befindet sich im Projekthandbuch.

(19) Kapitel 3.4.2	Beschaffung von Hard- und Software

Bei der Hardware ist unter dem Gesichtspunkt der Wirtschaftlichkeit die günstigste Gerätekonfiguration und Beschaffungsart (Kauf, Miete, Leasing) auszuwählen. Das System aus Hard- und Software soll ausreichend dimensioniert und erweiterbar sein. Die Abhängigkeit von einzelnen Herstellern ist soweit wie möglich zu vermeiden. Die Bestandteile des Systems aus Hard- und Software sollen untereinander und mit bereits vorhandenen Komponenten und Verfahren verträglich (kompatibel) sein.

Obige Forderungen sind durch Aktivität PM 2 "Vergabe/Beschaffung" und das Szenario "Einsatz von Fertigprodukten" im Handbuch "SZ" abgedeckt.

(20) Kapitel 3.4.3	Vergabe von Entwicklungsaufträgen

Externe Stellen sollen nur dann eingesetzt werden, soweit eigene Mitarbeiter für die ordnungsgemäße Erfüllung des Vorhabens nicht zur Verfügung stehen oder die Einschaltung aus besonderen Gründen geboten ist. Werden IT-Vorhaben, insbesondere die Entwicklung von Software, an externe Stellen vergeben, so ist grundsätzlich die Beachtung dieser Mindestanforderungen sicherzustellen. Die Abwicklung solcher Vorhaben ist entsprechend zu überwachen.

Obige Forderungen betreffen nicht den Regelungsgehalt des V-Modells. Sie sind bei der Bearbeitung der Aktivitäten PM 1.5 "Grobplan erstellen" und PM 4 "Feinplanung" jedoch zu berücksichtigen.

Des weiteren beziehen sich obige Forderungen auf die im Handbuch "UMF" gemachten Aussagen zu den Verwendungsformen des V-Modells (Vertragsgrundlage, Arbeitsanleitung). Die Verwendungsform "Vertragsgrundlage" dient der Steuerung und Überwachung von IT-Vorhaben, die durch externe Stellen realisiert werden. Dadurch, daß das "getailorte" V-Modell zur Vertragsgrundlage gemacht wird, können die Vorgehensweise und der Lieferumfang sehr präzise geregelt werden. Damit wird auch den Mindestanforderungen Rechnung getragen.

(21) Kapitel 3.4.4.1	Es sind Regelungen zur Erstellung von Programmen und zur Verwendung von Programmiersprachen zu treffen, die der Vereinfachung, Vereinheitlichung und Standardisierung des Programmierens und der Programme dienen.

Die Anwendung des V-Modells dient der Standardisierung der Softwareentwicklung. Weitergehende Regelungen wie z. B. die Festlegung der Programmiersprache, der Methoden usw. sind im Rahmen der Hausstandards im IT-Rahmenkonzept und projektspezifisch im Projekthandbuch festzulegen. Obige Forderung ist somit bei der Erstellung eines Projekthandbuchs zu berücksichtigen.

(22) Kapitel 3.4.4.2	Programme sollen im Hinblick auf Ordnungsmäßigkeit, Sicherheit und Wirtschaftlichkeit der Entwicklung, der Pflege und des Betriebs aus eigenständig änder- und testbaren Programmbestandteilen mit definierten Berührungspunkten (Schnittstellen) aufgebaut werden. Die Programme sind nach den Vorgaben so zu entwickeln, daß sie von einem anderen Programmierer fortgeführt werden können.

Obige Forderung wird durch Anwendung des V-Modells erfüllt, das der Standardisierung der Vorgehensweise dient. Dadurch wird eine Unabhängigkeit von den Eigenheiten von Einzelpersonen erreicht und eventuelle Einarbeitung anderer Personen erleichtert.

(23) Kapitel 3.4.4.3	Der Benutzerfreundlichkeit der IT ist besondere Beachtung zu schenken. Es sind Festlegungen, insbesondere für

−	das Aufbauschema von Bildschirmmasken,

−	die allgemeingültigen Funktionstasten und Kommandos,

−	die Meldungen für die Benutzer und das Betriebspersonal,

−	die Fehlerbehandlung,

−	die Hilfefunktion und

−	das Aufbauschema von Druckausgaben

zu beachten oder zu treffen.

Die geforderten Festlegungen sind im Rahmen der Bearbeitung der Aktivitäten des V-Modells (Submodell SE) vorzunehmen. Die geforderten Eigenschaften sind in den Anwenderforderungen und den Technischen Anforderungen im einzelnen festzuhalten.

(24) Kapitel 3.4.4.4	Die Verfahrensdokumentation muß alle Verfahrensfunktionen, insbesondere die der Programme, nachvollziehbar belegen. Zur Verfahrensdokumentation gehören u. a.:

−	Auftrag und Aufgabenstellung,

−	Kennziffern-, Schlüssel-, Symbol- und Abkürzungsverzeichnisse,

−	Beschreibung der Dateien und ggf. der Datenbanken bis zur Tiefe der Datenfeldebene mit Angaben zum Aufbau sowie Beschreibung von Maßnahmen zum Schutz und zur Archivierung der Daten,

−	Verzeichnis der Programme bzw. der Programmteile in ihren jeweils gültigen Versionen,

−	eine Darstellung aller programmierten und organisierten Kontrollen,

−	Darstellung des Programmablaufs und des Datenflusses ggf. Auflistung der Primärprogramme mit Programmübersetzung,

−	Beschreibung der Bildschirmmasken, Listen und Formulare,

−	Darstellung der Einbindung in das technische Umfeld und der technischen Berührungspunkte zu anderen Verfahren und Beschreibung der Überleitung in andere technische Umgebungen,

−	Dienst-, Arbeits- und Bedienungsanweisungen sowie Änderungsaufträge und -nachweise.

Die geforderte Verfahrensdokumentation entspricht den gemäß V-Modell zu erstellenden Produkten.

(25) Kapitel 3.4.5.1	IT-Verfahren sind vor ihrer Freigabe für den Betrieb, bei komplexen Verfahren auch schrittweise während der Erstellung der Programme, in allen Funktionen zu testen. Dabei ist den Berührungspunkten zu anderen Verfahren und der späteren organisatorischen Einbindung in den Betrieb besondere Beachtung zu schenken. Mit Hilfe der Tests muß insbesondere auch sichergestellt werden, daß jedes Programm nur die erforderlichen, in Vorgaben festzulegenden Funktionen erfüllt und keine unerwünschten Nebenwirkungen beinhaltet. Tests müssen unter Berücksichtigung aller Hard- und Software-Komponenten so durchgeführt werden, daß der Verfahrensbetrieb nicht beeinträchtigt wird.

Obige Forderungen werden durch das Submodell Qualitätssicherung des V-Modells erfüllt. Das V-Modell ist jedoch methodenfrei und spricht somit nicht von der Methode "Test", sondern von "inhaltlicher Prüfung".

Die Regelungen des V-Modells gehen bezüglich der Qualitätssicherung weit über die IT-Mindestanforderungen hinaus. So betreffen obige Forderungen nur die Qualitätssicherung von Programmen, während das V-Modell auch eine Qualitätssicherung der gesamten Dokumentation eines Vorhabens, also z. B. auch der Anforderungsdokumente, vorsieht.

(26) Kapitel 3.4.5.2	Tests müssen aufgrund von Testfällen mit im voraus festgelegten Eingaben und erwarteten Ausgaben durchgeführt werden. Die Ergebnisse des abschließenden Tests sind unter gebotener Beteiligung des Bereichs Datenverarbeitung von den am Vorhaben beteiligten Fachbereichen zu kontrollieren, zu bewerten und abzunehmen. Die fachlich zuständigen Stellen haben hierfür Testfälle zu erstellen, die hinsichtlich des technischen Ablaufs vom Bereich Datenverarbeitung zu ergänzen sind. Die Testfälle sollen wiederverwendet werden können.

Obige Forderungen werden durch das Submodell Qualitätssicherung des V-Modells erfüllt.

Testfälle werden im Produkt "Prüfspezifikation" (Aktivität QS 2.3 "Prüffälle festlegen"), die Bewertung der Testergebnisse wird in "Prüfprotokollen" dokumentiert (Aktivität QS 4.2 "Produkt inhaltlich prüfen").

Für die Bearbeitung der Aktivitäten sieht das V-Modell Rollen vor. Inwieweit diese Rollen mit Personen aus dem Bereich Datenverarbeitung bzw. den beteiligten Fachbereichen belegt werden, ist projektspezifisch festzulegen.

(27) Kapitel 3.4.5.3	Die Testergebnisse sind zu dokumentieren. Die Dokumentation über den Abschlußtest als Teil der Verfahrensdokumentation soll enthalten:

−	den fachlichen und technischen Hintergrund für den Test (z. B. Einführung eines neuen Verfahrens, Fehlerkorrektur, wesentliche Änderung),

−	die Beschreibung der Testumgebung (getestete Programme mit Angabe der Versionen, getesteter Ablauf, die angeschlossenen Dateien und Datenbanken, die Hardware- und Softwareumgebung mit Angabe der Versionen),

−	die Testfälle mit Eingabe- und erwarteten Ausgabedaten,

−	die Testergebnisse einschließlich des Systemverhaltens und der Systemmeldungen mit der fachlichen und technischen Bewertung der Testergebnisse durch die am Test beteiligten Stellen sowie

−	die Abnahmeerklärung der beteiligten Stellen.

Obige Forderungen werden mit Ausnahme der Abnahmeerklärung durch das Submodell Qualitätssicherung des V-Modells erfüllt.

Testfälle werden im Produkt "Prüfspezifikation" dokumentiert. Die Beschreibung der Testumgebung erfolgt im Prüfplan. Versionsangaben werden im Konfigurations-Identifikationsdokument festgehalten. Die Dokumentation der Testergebnisse erfolgt in Prüfprotokollen.

(28) Kapitel 3.4.5.4	Die zuständige Stelle, in der Regel der federführende fachlich zuständige Bereich, gibt auf der Grundlage der Abnahmerklärungen zum Abschlußtest das Verfahren frei und übernimmt damit die Gesamtverantwortung für die Ordnungsmäßigkeit und die Sicherheit des Verfahrens.

Die Freigabe von Verfahren zählt nicht zum Regelungsgehalt des V-Modells.

(29) Kapitel 3.4.5.5	Die Freigabebescheinigung als Teil der Verfahrensdokumentation muß enthalten:

−	die Verfahrensbezeichnung,

−	den Anlaß für Test und Freigabe,

−	den Zeitpunkt für den erstmaligen Einsatz der betreffenden Verfahrensversion,

−	die genaue Bezeichnung der freigegebenen Programme mit Versionsnummern,

−	die Bestätigung, daß die vorgeschriebenen Prüfungen durchgeführt wurden sowie

−	die Freigabeerklärung.

Die Freigabe von Verfahren zählt nicht zum Regelungsgehalt des V-Modells.

(30) Kapitel 3.4.5.6	Ein Verfahren darf grundsätzlich nur freigegeben werden, wenn die Dokumentationsunterlagen vollständig vorliegen.

Die Freigabe von Verfahren zählt nicht zum Regelungsgehalt des V-Modells. Die Entscheidung, ob die Dokumentation vollständig ist, wird durch die korrekte Anwendung des Tailoring-Verfahrens gewährleistet.

Darüber hinaus sieht das Submodell Projektmanagement sogenannte Durchführungsentscheidungen (Aktivität PM 6 "Durchführungsentscheidung") vor, deren Aufgabe u. a. darin besteht, die Vollständigkeit der Dokumentationsunterlagen zu prüfen.

(31) Kapitel 3.4.5.7	Auch nicht selbst entwickelte Verfahren sind vor ihrem Einsatz entsprechend zu testen und förmlich freizugeben.

Diese Forderung wird durch Aktivität QS 4 "Produktprüfung" erfüllt. Die Anforderungen an Tests für nicht selbst entwickelte Verfahren werden in Kapitel 5.1 des QS-Plans "Eingangskontrolle von Fertigprodukten" festgehalten.

(32) Kapitel 3.4.5.8	Einzelheiten des Test- und Freigabeverfahrens sind schriftlich zu regeln.

Regelungen zum Testverfahren erfolgen im QS-Plan (Kapitel 4 "Entwicklungsbegleitende Qualitätssicherung" und 5.1 "Eingangskontrolle von Fertigprodukten") sowie in Prüfspezifikationen und Prüfprozeduren.

Die Freigabe von Verfahren zählt nicht zum Regelungsgehalt des V-Modells.

(33) Kapitel 3.4.5.9	Nach einer Freigabe ist sicherzustellen, daß bis zur Übernahme in die Produktion keine Änderungen mehr vorgenommen werden.

Die Erfüllung dieser Forderung wird durch das Konfigurationsmanagement sichergestellt.

(34) Kapitel 3.4.6.1	Nach der Übernahme von Verfahrenssoftware in die Produktionsumgebung dürfen unbefugte Änderungen nicht mehr möglich sein. Die Bereitstellung zum Verfahrensbetrieb soll maschinell protokolliert werden und darf nur von ausdrücklich hierzu berechtigtem Personal vorgenommen werden. Eine geordnete Verwaltung von Programmversionen ist sicherzustellen.

Die Erfüllung dieser Forderung wird durch die Regelungen des Konfigurationsmanagements sichergestellt. Die Prozeduren für Änderungen werden in Kapitel 3 "Änderungsmanagement" des KM-Plans festgehalten.

(35) Kapitel 3.4.6.2	Für die Einführung eines Verfahrens ist rechtzeitig insbesondere

−	die Einrichtung der Hard- und Softwareumgebung für den Verfahrensbetrieb,

(die Festlegungen erfolgen im Projekthandbuch)

−	soweit erforderlich die Übernahme von Datenbeständen eines abzulösenden Verfahrens sowie

(Regelung hierzu in Aktivität SE 9.3 "In Betrieb nehmen")

−	die Schulung des Personals

(Regelung hierzu in Aktivität SE 9.1 "Beitrag zur Einführungsunterstützung leisten")

sicherzustellen.

(36) Kapitel 3.4.6.3	Für eine fortlaufende Beratung und Schulung auch nach der Verfahrenseinführung muß Vorsorge getroffen werden.

Die Beratung und Schulung nach Verfahrenseinführung zählt nicht zum Regelungsgehalt des V-Modells. Es können jedoch die Betriebsinformationen aus Aktivität SE 8.3 "Produkt bereitstellen" dafür mit verwendet werden.

(37) Kapitel 3.5.1	Bei der Verfahrenspflege sollen der ordnungsgemäße Einsatz des Verfahrens sowie seine Anpassung an veränderte Anforderungen gewährleistet werden. Soweit wesentliche Änderungen erforderlich werden, ist wie bei einem neuen IT-Vorhaben vorzugehen. Für andere Änderungen sind entsprechende Regelungen zu treffen. Für jede Verfahrensänderung sind grundsätzlich ein erneuter Abschlußtest und in jedem Fall eine -freigabe durchzuführen.

Obige Forderungen entsprechen der Intention des V-Modells. Spezielle Regelungen zu Verfahrensänderungen finden sich im KM-Plan. Die Durchführung selbst wird in Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)" geregelt.

(38) Kapitel 3.5.2	Für abweichende Vorgehensweisen zur schnellen Behebung von Fehlern sind besondere schriftliche Regelungen zu treffen und die Beteiligung der zuständigen Fachbereiche sicherzustellen.

Abweichende Vorgehensweisen zur schnellen Behebung von Fehlern sind im KM-Plan festzulegen.

(39) Kapitel 3.5.3	Änderungen der Hardware und der nicht verfahrensspezifischen Software sind im Rahmen einer geordneten Vorgehensweise vorzunehmen. Dabei ist sicherzustellen, daß zusammengehörige Änderungen vollständig durchgeführt und Störungen sowie Unterbrechungen des Verfahrensbetriebes durch Folgeänderungen verhindert werden. Die bei der Durchführung eines IT-Vorhabens zu Test und Freigabe beschriebenen Grundsätze sollen sinngemäß angewendet werden. Alle Maßnahmen im Rahmen von Änderungen sind zu dokumentieren.

Die "geordnete Vorgehensweise bei Änderungen" wird durch das Konfigurationsmanagement sichergestellt (Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)"). Die projektspezifischen Vorgehensweisen sind im KM-Plan zu beschreiben.

(40) Kapitel 4 	Betrieb von IT-Verfahren

Der Betrieb von IT-Verfahren wird nicht durch das V-Modell geregelt.

(41) Kapitel 5	Erfolgskontrolle

Die Erfolgskontrolle von IT-Verfahren wird nicht durch das V-Modell geregelt.

(42) Kapitel 6.1	Die Verfahrensentwicklung und der -betrieb sind laufend im Hinblick auf die durchgängige Beachtung der festgelegten Vorgehensweisen und Arbeitstechniken (Methoden und Werkzeuge) zu überprüfen und zu bewerten.

Die Prüfung und Bewertung soll anhand von im voraus festgelegten Qualitätsnormen erfolgen. Bei Abweichungen sind entsprechend Maßnahmen zu treffen.

Die "Beachtung der festgelegten Vorgehensweisen" wird durch Aktivität QS 3 "Prozeßprüfung von Aktivitäten" sichergestellt.

(43) Kapitel 6.2	In angemessenen Zeitabständen ist zu überprüfen, ob Verfahren ordnungsgemäß angewandt werden und evlt. Schwachstellen zu beseitigen sind. Das Ergebnis der Prüfung und die eingeleiteten Maßnahmen sind zu dokumentieren.

Die Erfüllung dieser Forderung wird durch Aktivität PM 6 "Durchführungsentscheidung" sichergestellt. Die Ergebnisse werden in einem Protokoll niedergelegt.

(44) Kapitel 7.2.1	Die zur Aufrechterhaltung der Sicherheit geeigneten Maßnahmen sind aus einer (Bedrohungsanalyse und) Risikoanalyse abzuleiten und in einem Sicherheitskonzept darzustellen.

In Aktivität SE 1.6 "Bedrohung und Risiko analysieren" wird eine Bedrohungsanalyse zur Ermittlung aller zu schützenden Objekte und eine Risikoanalyse zur Ermittlung der Eintrittswahrscheinlichkeiten der möglichen Bedrohungen gefordert. Das IT-Sicherheitskonzept wird im Rahmen der Aktivität SE 2.1 "System technisch entwerfen" erstellt und, falls gefordert, auch ein formales IT-Sicherheitsmodell.

(45) Kapitel 7.2.2	Aufbauend auf der Risikoanalyse und dem Sicherheitskonzept sind im erforderlichen Umfang technische und organisatorische Sicherheitsmaßnahmen festzulegen, die aufeinander abgestimmt sind.

Das V-Modell gibt technische Anweisungen zur Erfüllung einer geforderten Sicherheitsstufe. Organisatorischen Maßnahmen sind auch dem IT-Rahmenkonzept zu entnehmen.


Zuordnung der V-Modell-Produkte und -Aktivitäten zu den BRH-Forderungen
Teil 3	Vorgehensmodell / Handbuchsammlung

BRH	Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell

BRH.3	Zuordnung der V-Modell-Produkte und -Aktivitäten zu den BRH-Forderungen

Kap.	Kurzbezeichnung der Forderung	Erfüllung durch
1.4.1	Planung und Einsatz der IT	IT-Rahmenkonzept, Produkte des V-Modells
1.4.2	IT-Dokumentation vollständig und überschneidungsfrei	V-Modell allgemein
1.4.3	Dokumentation maschinell unterstützen	Submodell KM
1.4.4	Verfügbarkeit der Dokumentation	projektspezifische organisatorische Regelungen, KM
1.4.5	Gestaltung, Erstellung und Inhalt der Dokumentation sowie Verteilung und Aufbewahrung	V-Modell allgemein, speziell Projekthandbuch, KM-Plan
2	Gesamtplanung und Koordinierung	IT-Rahmenkonzept, Beiträge des V-Modells zu einzelnen IT-Vorhaben
3.1.1	IT-Vorhaben	Zielsetzung des V-Modells
3.1.2	Einheitliche Vorgehensweise schriftlich regeln	V-Modell allgemein, speziell Projekthandbuch
3.2.1	Zuständigkeiten und Vorgehensweise	Projekthandbuch, Projektplan, KM-Plan, QS-Plan
3.2.2	IT-Gesamtplan	Phasenmodell (außerhalb V-Modell)
3.3.1	Vor- und Hauptuntersuchung	Phasenmodell (außerhalb V-Modell)
3.3.5	Zusammenfassung der Vor- und Hauptuntersuchung	keine Forderung
3.3.6	Dokumentation der Ergebnisse der Vor- und Hauptuntersuchung	Phasenmodell (außerhalb V-Modell)
3.4.1.1	Ausführung eines IT-Vorhabens	V-Modell allgemein
3.4.1.2	Dokumentation der Ausführung eines IT-Vorhabens	V-Modell allgemein
3.4.2	Beschaffung von Hard- und Software	PM 2, Szenario "Einsatz von Fertig- produkten"
3.4.3	Vergabe von Entwicklungsaufträgen	PM 1.5, PM 4, Anwendung als Vertragsgrundlage (Handbuch "UMF")
3.4.4.1	Regelungen zur Erstellung von Programmen	V-Modell allgemein, speziell Projekthandbuch
3.4.4.2	Aufbau der Programme	V-Modell allgemein
3.4.4.3	Benutzerfreundlichkeit	Beachtung bei der Bearbeitung des Submodells SE
3.4.4.4	Verfahrensdokumentation	Produkte des V-Modells
3.4.5.1	Test der IT-Verfahren	Submodell QS
3.4.5.2	Testdurchführung	Submodell QS
3.4.5.3	Dokumentation der Testergebnisse	Submodell QS
3.4.5.4	Freigabe (Zuständigkeit)	nicht durch V-Modell geregelt
3.4.5.5	Freigabebescheinigung	nicht durch V-Modell geregelt
3.4.5.6	Freigabe (Voraussetzung)	nicht durch V-Modell geregelt, aber Beachtung bei PM 6
3.4.5.7	Freigabe nicht selbst entwickelter Verfahren	Submodell QS
3.4.5.8	Freigabe schriftlich regeln	nicht durch V-Modell geregelt
3.4.5.9	keine Änderung nach Freigabe	Submodell KM
3.4.6.1	keine unbefugten Änderungen nach Übernahme in Produktion	Submodell KM
3.4.6.2	Einführung eines IT-Verfahrens	SE 9
3.4.6.3	Beratung und Schulung nach der Verfahrenseinführung	Betriebsinformationen
3.5.1	Verfahrenspflege	V-Modell allgemein
3.5.2	schriftliche Regelungen zur schnellen Behebung von Fehlern	KM-Plan
3.5.3	Dokumentation von Änderungen	KM 3
4	Betrieb von IT-Verfahren	nicht durch V-Modell geregelt
5	Erfolgskontrolle	nicht durch V-Modell geregelt
6.1	Überprüfen der Verfahrensentwicklung	QS 3
6.2	Prüfung auf ordnungsgemäße Anwendung von Verfahren	PM 6
7.2.1	Bedrohungs- und Risikoanalyse	SE 1.6, SE 2.1
7.2.2	technische und organisatorische Maßnahmen	SE 1, SE 2 zusätzlich IT-Rahmenkonzept


Literaturverzeichnis AU250/3 - BRH
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - BRH)

A.1	Literaturverzeichnis

/BRH/	Bundesrechnungshof: Mindestanforderungen der Rechnungshöfe des Bundes und der Länder zum Einsatz der Informationstechnik  IT-Mindestanforderungen. Mai 1991.

/ITSEC/	BSI: Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (ITSEC). Vorläufige Form der harmonisierten Kriterien. Juni 1991.

/ITSIHB/	BSI: Handbuch für die sichere Anwendung der Informationstechnik (IT-Sicherheitshandbuch). 2. Entwurf vom 29. Mai 1991.


Geschäftsprozesse und IT-Systeme
Teil 3	Vorgehensmodell / Handbuchsammlung

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

GPO.1	Geschäftsprozesse und IT-Systeme

Die Informationstechnik (IT), die vom Verständnis her alle technischen Mittel zur Verarbeitung oder Übertragung von Informationen umfaßt, kann als die Basisinnovation des ausgehenden Jahrhunderts bezeichnet werden. Information wird in diesem Zusammenhang oft als der grundlegende "Rohstoff" einer postindustriellen Gesellschaft ("Informationsgesellschaft") bezeichnet, in der Informationsverarbeitung und Kommunikationsunterstützung integrierte Bestandteile der Geschäftsprozesse im Rahmen der Leistungserstellung sind. In diesem Sinne dient die IT-Unterstützung der zeit- und sachgerechten Durchführung von Geschäftsprozessen und damit der Verschlankung der Verwaltung und der größtmöglichen Bürgernähe.

Abbildung GPO.1: Geschäftsprozesse, IT-Systeme und V-Modell

Geschäftsprozesse sind strategisch umso bedeutender, je mehr sie aus heutiger (und aus künftiger Sicht) zur Wertschöpfung beitragen. Die Bedeutung der Geschäftsprozesse für das Erreichen der Geschäftsziele einer Organisation weist gleichzeitig auch den sie unterstützenden IT-Systemen ihre Wertigkeit im unternehmerischen Kontext zu. Effizienz und Effektivität von Unternehmen und Behörden wird daher unmittelbar durch den zielgerichteten Einsatz von IT beeinflußt, zumal sich aus den Geschäftsprozessen Anforderungen an die unterstützenden IT-Systeme ableiten lassen.

Erstellung und Beschaffung der IT-Systeme zur optimalen Unterstützung der Abwicklung von Geschäftsprozessen ist insofern ein wichtiger kritischer Erfolgsfaktor, dem das Informationsmanagement in der Leitungsebene von Unternehmen und Behörden als Bestandteil einer übergeordneten Unternehmens- bzw. Behördenstrategie besondere Aufmerksamkeit schenken sollte. Die technische Abwicklung der Erstellung und Beschaffung der notwendigen IT-Systeme wird durch das V-Modell geregelt.


Organisationsentwicklung und ”Business Process Reengineering”
Teil 3	Vorgehensmodell / Handbuchsammlung

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

GPO.2	Organisationsentwicklung und "Business Process Reengineering"

Bei den Vorgehensweisen zur Optimierung von Geschäftsprozessen lassen sich prinzipiell zwei extreme Ansätze unterscheiden, die sich als "Endpunkte eines ganzen Kontinuums" von möglichen Zwischenformen gegenüberstehen:

1.	Organisationsentwicklung

2.	"Business Process Reengineering" (BPR)

Bei der Organisationsentwicklung handelt es sich um inkrementelle Verbesserungen von Geschäftsprozessen, wobei diese verbesserten Prozesse mit moderner IT zu unterstützen sind. Im Vordergrund des Ansatzes steht die Grundfrage: Was kann besser gemacht werden? Die vorhandenen Geschäftsprozesse werden prinzipiell akzeptiert. Es wird nur nach Wegen zur Verbesserungen der vorhandenen Prozesse gesucht. Zwar werden einzelne Systembausteine verändert, radikale Änderungen und Brüche werden dabei jedoch vermieden.

Abbildung GPO.2: Organisationsentwicklung vs. "Business Process Reengineering"

Demgegenüber setzt sich BPR das Ziel, die vorhandenen Prozesse radikal zu ändern. Die Ausgangsfrage lautet hier: Was kann anders gemacht werden? Vorhandene Prozesse werden prinzipiell in Frage gestellt. Es wird grundlegend nach neuen Ansätzen für Geschäftsprozesse gesucht. Das System als ganzes wird dramatisch geändert, um Verbesserungen in signifikanter Größenordnung zu erreichen. Für die IT bedeutet dies, schließlich völlig andere Prozesse als bisher unterstützen zu müssen.

Zwischen beiden Extrempunkten liegt der Bereich, in dem gemäß herkömmlicher Ansätze lediglich versucht wurde, die vorhandenen Prozesse verbessert mit moderner IT zu unterstützen. Dieser Bereich birgt jedoch die Gefahr, existierende, aber ineffizient organisierte Geschäftsprozesse mit hohem Aufwand zu automatisieren. Bei der Erstellung und Beschaffung (aber auch bei der Änderung) von Informationssystemen sollte daher von der Leitungsebene immer mit berücksichtigt werden, inwieweit die Gestaltung der zu unterstützenden Geschäftsprozesse noch den Anforderungen der Zeit entspricht. Nach welchem Ansatz - "inkrementelle Verbesserungen" oder "radikale Änderung" - schließlich vorgegangen werden sollte, ist eine Frage der Opportunität und muß in jedem Einzelfall durch das Management entschieden werden. Im Rahmen eines weitgreifenden kontinuierlichen Verbesserungsprogramms läßt sich auch vorstellen, beide Vorgehensweisen organisch miteinander zu verbinden. Dabei werden nach Ablauf längerer Zeitabschnitte die vorhandenen Geschäftsprozesse zuweilen grundlegend hinterfragt. Während dieser Zeitabschnitte wird dagegen versucht, die Vorgänge kontinuierlich durch schrittweise verbesserte Prozeßabwicklung zu optimieren.


Systemanforderungsanalyse und Geschäftsprozeßoptimierung
Teil 3	Vorgehensmodell / Handbuchsammlung

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

GPO.3	Systemanforderungsanalyse und Geschäftsprozeßoptimierung

Ausgangspunkt der Regelungen im Submodell SE des V-Modells sind die Anwenderforderungen. Diese Anwenderforderungen ergeben sich unter anderem aus einer Geschäftsprozeßanalyse oder auch Optimierung. Im folgenden soll dargelegt werden, inwieweit hier konkrete Zusammenhänge existieren. Die Aktivität SE 1 "System-Anforderungsanalyse" ist dabei Ausgangspunkt. Grundlage der Geschäftsprozeßanalyse ist hier die Methode GPO (Geschäfts-Prozeß Optimierung).

Bei einer Geschäftsprozeßanalyse fallen eine Vielzahl von Daten an, die bei der späteren Systemerstellung genutzt werden können. Zwar geht eine Geschäftsprozeßanalyse in erster Linie von dem Vorgang selbst aus, doch wird bei GPO bereits zu diesem Zeitpunkt eine spätere Umsetzung in ein zu realisierendes System berücksichtigt. Ferner spielt die Integration von Fertigprodukten eine gewichtige Rolle. So ist eine der zentralen Untersuchungspunkte der GPO, mit welchen Hilfsmitteln wer welchen Vorgang bearbeitet.

Hilfsmittel können dabei die unterschiedlichste Ausprägung haben. Ziel der auf die Analyse aufsetzenden Optimierung ist es zu eruieren, in wieweit diese Hilfsmittel computergestützt die Vorgangsbearbeitung erleichtern können. Deuten die anfallenden Kennzahlen auf eine IT-Systementwicklung hin, so fließen die Ergebnisse der GPO in die einzelnen Produkte des Submodells SE ein. Besonders die organisatorische Einbettung des zu erstellenden Systems findet dabei Berücksichtigung.


Relevante Aktivitäten und Produkte
Teil 3	Vorgehensmodell / Handbuchsammlung

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

GPO.4	Relevante Aktivitäten und Produkte

Einfließende Produkte in die Aktivitäten SE 1 "System-Anforderungsanalyse" und SE 2 "System-Entwurf" sind

−	externe Vorgaben und

−	Produktinformationen.

Beide Produkte sind Ergebnisse einer GPO. Die externen Vorgaben enthalten zum Beispiel folgende Angaben:

−	Wer mit dem späteren System arbeiten soll, welche Anforderungen somit an die Bedienbarkeit sowie die notwendige Netzwerkstruktur existieren.

−	Auf welcher existierenden oder zu beschaffenden Hardware das System laufen soll.

−	Zentraler Punkt sind die fachlichen Anforderungen, die hier bereits vorliegen. Damit ist auch ein wesentlicher Teil des während Aktivität SE 1 zu erstellenden Produktes "Anwenderforderungen" bereits vorhanden. Dabei liegt die Betonung auf fachlichen Anforderungen, technische Aspekte fließen hier nicht mit ein.

−	Bei der IST-Aufnahme innerhalb der GPO wird ebenfalls ermittelt, welche Software bereits im Einsatz ist und weiterverwendet werden soll.

−	Ebenfalls ein Ergebnis der GPO ist, welche hausinternen Standards existieren und bei der Entwicklung bzw. dem Ankauf zukünftiger Systeme berücksichtigt werden müssen.

−	Da eine GPO immer einen Geschäftsprozeß als ganze Einheit betrachtet, werden auch die Schnittstellen deutlich, die innerhalb eines Vorgangs auftauchen. Somit liegen auch erste Informationen für die Produkte "Schnittstellenübersicht" und "Schnittstellenbeschreibung" vor.

Bei den Produktinformationen kann es sich bereits um die Ergebnisse einer Marktrecherche handeln, die häufig am Ende einer GPO durchgeführt wird. Besonders bei der Integration von Fertigprodukten handelt es sich hier um klar definierte Vorgaben, die zu berücksichtigen sind.


Allgemeines zur GPO
Teil 3	Vorgehensmodell / Handbuchsammlung

GPO	Zusammenhang zwischen Geschäftsprozeßoptimierung und dem V-Modell

GPO.5	Allgemeines zur GPO

Bei der Durchführung der GPO ist zielorientiert vorzugehen, und zwar bei der Analyse des Geschäftsprozesses beginnend beim Vorgang bis herunter zur Leistung, die erbracht werden soll, und beim Aufbau des Geschäftsprozesses beginnend bei der Leistung bis hin zum Geschäftsprozeß. Dieser Weg ist dargestellt in Abbildung GPO.3.

Durch diese Vorgehensweise erhält man eine klare Trennung davon, welche Informationen für das V-Modell wichtig sind, und welche Ergebnisse lediglich Randinformationen darstellen. Randinformationen treten auf bei der Betrachtung des Aufbau des Geschäftsprozesses, hingegen für das V-Modell relevante Informationen kommen bei der Analyse des Geschäftsprozesses zu Tage.

Abbildung GPO.3: Aufbau und Analyse von Geschäftsprozessen


Abbildungsverzeichnis AU250/3 - GPO
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - GPO)

A.1	Abbildungsverzeichnis

Abbildung GPO.1:	Geschäftsprozesse, IT-Systeme und V-Modell

Abbildung GPO.2:	Organisationsentwicklung vs. "Business Process Reengineering"

Abbildung GPO.3:	Aufbau und Analyse von Geschäftsprozessen


Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

Eine im Rahmen des V-Modells durchzuführende HW-Entwicklung stützt sich neben den Aktivitäten auf Systemebene und Segmentebene auf folgende Aktivitäten, die für jede HW-Einheit maßgebend sind:

−	SE 4-HW:	HW-Grobentwurf

−	SE 5-HW:	HW-Feinentwurf

−	SE 6-HW:	HW-Realisierung

−	SE 7-HW:	HW-Integration


SE 4-HW: HW-Grobentwurf
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW	HW-Grobentwurf

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
—	—		HW-Architektur		SE 5-HW	in Bearb.
SE 2	in Bearb.		Schnittstellenübersicht		SE 5-HW, KM 4	vorgelegt
SE 2	in Bearb.		Schnittstellenbeschreibung		SE 5-HW, KM 4	vorgelegt
SE 2	in Bearb.		Integrationsplan		SE 7-HW, SE 8, QS 2	in Bearb.
SE 3	in Bearb.		Betriebsinformationen		SE 5-HW	in Bearb.
Abwicklung

Der HW-Grobentwurf hat die Aufgabe, die in Aktivität SE 3 spezifizierte Funktion in einzelne Funktionsblöcke zu zerlegen und eine HW-Architektur zu definieren. Ferner wird das Zusammenspiel der HW-Komponenten spezifiziert.


SE 4.1-HW: Lösungsvorschläge erarbeiten und bewerten
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW	HW-Grobentwurf

SE 4.1-HW	Lösungsvorschläge erarbeiten und bewerten

Vorschläge für mögliche Grobentwürfe einer HW-Einheit werden erarbeitet, u. U. auch durch Simulation oder Versuchsmuster, und systematisch nach technischen Aspekten und Kosten-Aspekten bewertet.


SE 4.2-HW: Grobentwurf einer HW-Einheit erarbeiten
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW	HW-Grobentwurf

SE 4.2-HW	Grobentwurf einer HW-Einheit erarbeiten

Die Erstellung der HW-Architektur beinhaltet die Erstellung von Entwürfen, Blockschaltbildern, Funktionsskizzen u. a. für Mechanik-, Elektronik- oder andere Bestandteile, soweit relevant.

Auf der Basis der HW-Architektur kann eine Untersuchung auf verwendbare Kaufteile oder Wiederholteile erfolgen. Diese werden daraufhin geprüft, ob die vorgegebene Qualität und Liefersicherheit den Anforderungen entsprechen; gegebenenfalls werden Einzelheiten spezifiziert.

Weiter wird untersucht, ob und welche HW-Module oder HW-Komponenten selbst oder extern entwickelt bzw. konstruiert werden ("make or buy").

Im Zusammenhang mit dem HW-Grobentwurf kann eine erste Festlegung von Bauteilen und Materialien nötig sein, die die HW-Architektur maßgeblich beeinflussen.


SE 4.3-HW: HW-interne Schnittstellen spezifizieren
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW	HW-Grobentwurf

SE 4.3-HW	HW-interne Schnittstellen spezifizieren

Soweit erforderlich, werden interne Schnittstellen zwischen HW-Komponenten und HW-Modulen der HW-Einheit spezifiziert.


SE 4.4-HW: HW-Integration spezifizieren
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 4-HW	HW-Grobentwurf

SE 4.4-HW	HW-Integration spezifizieren

Der Ablauf der Integration der HW-Komponenten und HW-Modulen zu einer HW-Einheit wird bezüglich der Abfolge und schrittweisen Prüfung von Teilfunktionen festgelegt.


SE 5-HW: HW-Feinentwurf
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 5-HW	HW-Feinentwurf

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 1	akzeptiert		Anwenderforderungen		—	—
SE 2	akzeptiert		Systemarchitektur		—	—
SE 3	akzeptiert		Technische Anforderungen		—	—
SE 4-HW	akzeptiert		Schnittstellenübersicht		—	—
SE 4-HW	akzeptiert		Schnittstellenbeschreibung		—	—
—	—		Zeichnungssatz		SE 6-HW, SE 7-HW	vorgelegt
—	—		Analysebericht		QS 4	vorgelegt
SE 4-HW	in Bearb.		HW-Architektur		SE 6-HW	vorgelegt
SE 4-HW	in Bearb.		Betriebsinformationen		SE 8	in Bearb.
Abwicklung

Im HW-Feinentwurf erfolgt

−	die endgültige Festlegung der Bauteile und Materialien,

−	die Erarbeitung der Detailentwürfe für die einzelnen HW-Komponenten und HW-Module,

−	die Festlegung von Abmessungen, Auslegung von Schaltungen oder Logikkomponenten, Berechnung von Toleranzen,

−	die Erstellung der Konstruktionsunterlagen und Funktionsbeschreibungen für die einzelnen Bestandteile,

−	Durchführung von Analysen und Nachweisberechnungen.


SE 5.1-HW: Detailentwürfe für HW-Komponenten/HW-Module erstellen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 5-HW	HW-Feinentwurf

SE 5.1-HW	Detailentwürfe für HW-Komponenten/HW-Module erstellen

Für jede HW-Komponente bzw. jedes HW-Modul werden die endgültigen Bauteile und Materialien festgelegt. Die Entwürfe werden bis zur Bauteile-Ebene verfeinert und die für die Realisierung notwendigen Informationen dokumentiert. Eine detaillierte Funktionsbeschreibung der HW-Komponente bzw. des HW-Moduls wird erstellt.


SE 5.2-HW: Zeichnungssatz erstellen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 5-HW	HW-Feinentwurf

SE 5.2-HW	Zeichnungssatz erstellen

Der Zeichnungssatz für die gesamte HW-Einheit enthält alle für den Nachbau dieser Einheit notwendigen Unterlagen, z. B. Aufbauübersicht, Zeichnungen, Stücklisten, Stromlaufpläne, Verdrahtungspläne, Layout, Liefervorschriften, usw.

Erläuterung

Die Prüfvorschriften gehören inhaltlich gesehen zur jeweiligen HW-Einheit und werden oft als Bestandteil des Zeichnungssatzes mitgeführt. Sie werden jedoch nicht in den HW-Erstellungsaktivitäten erstellt, sondern im Submodell QS.


SE 5.3-HW: Analysen und Nachweise durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 5-HW	HW-Feinentwurf

SE 5.3-HW	Analysen und Nachweise durchführen

Bei besonderen Anforderungen an die Sicherheit oder Zuverlässigkeit der HW-Einheit wird gesondert untersucht und nachgewiesen, daß die Anforderungen an das Produkt u. a. betreffend

−	Zuverlässigkeit,

−	Toleranzen,

−	Festigkeit,

−	Sicherheit,

−	andere

von der jeweiligen HW-Einheit erfüllt werden. Die Nachweise erfolgen in der Regel durch vorgegebene Analyse- und Berechnungsverfahren.


SE 6-HW: HW-Realisierung
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 6-HW	HW-Realisierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-HW	akzeptiert		HW-Architektur		—	—
SE 5-HW	akzeptiert		Zeichnungssatz		—	—
—	—		Realisierungsdokumente (HW- Komponente)/HW-Komponente		SE 7-HW	vorgelegt
—	—		Realisierungsdokumente (HW- Modul)/HW-Modul		SE 7-HW	vorgelegt
Abwicklung

In der Realisierung werden gemäß den Unterlagen aus den Entwurfsaktivitäten die entsprechenden HW-Komponenten bzw. HW-Module angefertigt bzw. komplettiert.


SE 6.1-HW: HW-Komponente/HW-Modul anfertigen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 6-HW	HW-Realisierung

SE 6.1-HW	HW-Komponente/HW-Modul anfertigen

Die HW-Komponente bzw. das HW-Modul wird gemäß den Bauplänen und Entwicklungsunterlagen angefertigt. Kaufteile werden gegebenenfalls entsprechend angepaßt und eingebaut. Hierbei getroffene Festlegungen sowie Erkenntnisse, die während der Realisierung der HW-Einheit entstehen, sind zum Zweck der späteren Verwendung, z. B. bei Installations- oder Integrationsarbeiten, zu dokumentieren.

Die Beschaffung von im eigenen Betrieb gefertigten oder zugekauften Teilen erfolgt in enger Zusammenarbeit von Entwicklung, Fertigung und weiteren betroffenen Stellen (z. B. Einkauf, Controlling, Qualitätsmanagement).

Für Fremdteile erfolgt eine Wareneingangsprüfung. Hierfür sind geeignete Unterlagen bereitzustellen.

Erläuterung

Diese Aktivität regelt die Realisierung von z. B. Funktions- und Erprobungsmustern. Sie betrifft nicht die Realisierung im Sinne einer Produktion (d. h. Serienfertigung), die nicht im Betrachtungsbereich des V-Modells liegt.


SE 6.2-HW: Selbstprüfung durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 6-HW	HW-Realisierung

SE 6.2-HW	Selbstprüfung durchführen

Die HW-Komponente bzw. das HW-Modul werden einer Selbstprüfung durch den Entwickler unterzogen.


SE 7-HW: HW-Integration
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 7-HW	HW-Integration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
SE 5-HW	akzeptiert		Zeichnungssatz		—	—
SE 6-HW	akzeptiert		Realisierungsdokumente (HW- Komponente)/HW-Komponente		—	—
SE 6-HW	akzeptiert		Realisierungsdokumente (HW- Modul)/HW-Modul		—	—
SE 4-HW	akzeptiert		Integrationsplan		—	—
—	—		HW-Einheit		SE 8	vorgelegt
Abwicklung

Im Rahmen der Integration wird die HW-Einheit aus einzelnen HW-Komponenten, HW-Modulen und sonstigen Bauteilen zusammengeführt. Soweit möglich, wird die spezifizierte Funktion erprobt und mindestens einer Selbstprüfung unterzogen. Der Änderungszustand der HW-Einheit wird sichtbar gekennzeichnet, entweder an der HW-Einheit selbst oder am Transportbehälter.


SE 7.1-HW: Zur HW-Teilstruktur integrieren
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 7-HW	HW-Integration

SE 7.1-HW	Zur HW-Teilstruktur integrieren

Entsprechend den Vorgaben des Integrationsplans werden HW-Komponenten und Teilstrukturen zusammengefügt.


SE 7.2-HW: HW-Teilstrukturen-Selbstprüfung durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 7-HW	HW-Integration

SE 7.2-HW	HW-Teilstrukturen-Selbstprüfung durchführen

Bei funktionell komplexen Strukturen werden Teilstrukturen geprüft. So werden u. a. mechanische Teile auf Toleranzen an Funktionsmaßen, elektronische Logikbausteine (PALs − Programmable Array Logic, ASICs − Application Specific Integrated Circuit) funktionell gegen die Vorgaben geprüft, usw..


SE 7.3-HW: Zur HW-Einheit integrieren
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 7-HW	HW-Integration

SE 7.3-HW	Zur HW-Einheit integrieren

Entsprechend den Vorgaben des Integrationsplans werden einzelne Bauteile, HW-Module und die verschiedenen HW-Komponenten zur HW-Einheit zusammengefügt.


SE 7.4-HW: HW-Einheiten-Selbstprüfung
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.1	Aktivitäten der Hardwareerstellung (SE 4-HW bis SE 7-HW)

SE 7-HW	HW-Integration

SE 7.4-HW	HW-Einheiten-Selbstprüfung

Bei schrittweiser Inbetriebnahme von komplexen HW-Einheiten sind Integration und Prüfung eng verknüpft. Teilfunktionen werden schrittweise erweitert und jeweils einem Selbsttest durch den Entwickler unterzogen. Die Erfüllung der Anforderungen oder Abweichungen werden protokolliert.


Produkte der Hardwareerstellung
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

Unter den HW-Produkten werden die HW-Architektur, der Zeichnungssatz, die Realisierungsdokumente und der Analysebericht zusammengefaßt. Weiterhin werden dazu noch die Hardware-Anforderungen gezählt, die ein Bestandteil der Technischen Anforderungen darstellen.

Die Produktmuster zu diesen Produkten mit den Erläuterungen werden in Abschnitt HW.6 aufgeführt.


Hardware-Anforderungen (als Teil der Technischen Anforderungen)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

HW.2.1	Hardware-Anforderungen (als Teil der Technischen Anforderungen)

Die Hardware-Anforderungen decken alle Anforderungen an die HW-Einheit ab, die für den Entwurf, die Realisierung und den späteren Einsatz relevant sind. Hinsichtlich des letzten Aspektes werden insbesondere auch die Anforderungen an die Prüfbarkeit und die Wartbarkeitsanforderungen formuliert.


HW-Architektur
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

HW.2.2	HW-Architektur

In der Hardware-Architektur wird die Zerlegung der HW-Einheit in einzelne logische Blöcke, die einzelnen HW-Komponenten und HW-Module sowie die Funktionsweise und das Zusammenspiel dieser Bestandteile beschrieben. In der Anforderungszuordnung wird dargelegt, welche Entwurfselemente welche Anforderungen abdecken.

Die Hardware-Architektur enthält sowohl die Ergebnisse des Grob- wie auch des Feinentwurfs der HW-Einheit.


Zeichnungssatz
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

HW.2.3	Zeichnungssatz

Der Zeichnungssatz spiegelt die konkrete Realisierung der HW-Einheit wider. Er enthält alle Angaben und Unterlagen, die für den Nachbau der HW-Einheit notwendig sind. Insbesondere sind hier neben den Zeichnungen, Stücklisten, Verdrahtungsplänen, usw. auch Angaben zu Parametereinstellungen, Justagearbeiten, usw. zu machen.


Realisierungsdokumente
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

HW.2.4	Realisierungsdokumente

Die Realisierungsdokumente enthalten Angaben zur Installation, Integration, zur sicherheitstechnischen Behandlung, usw. der HW-Einheit, die im Rahmen der Realisierung erarbeitet bzw. festgelegt wurden.


Analysebericht
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.2	Produkte der Hardwareerstellung

HW.2.5	Analysebericht

Falls erforderlich, werden bei besonders hohen Anforderungen an die HW-Einheit bestimmte Analysen und Nachweisberechnungen durchgeführt und in dem/den Analysebericht(en) festgehalten.


Submodell Qualitätssicherung (QS)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.3	Submodell Qualitätssicherung (QS)

Nachfolgend werden Erläuterungen zur Anwendung des Submodells QS gegeben.


QS-Produkte
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.3	Submodell Qualitätssicherung (QS)

HW.3.1	QS-Produkte

Die Regelungen des Submodells QS sind für Hardware entsprechend anzuwenden.


QS-Prüfungen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.3	Submodell Qualitätssicherung (QS)

HW.3.2	QS-Prüfungen

Im Sinne von Aktivität QS 4.2 "Produkt inhaltlich prüfen" ergeben sich für Hardware spezielle Prüfungen. (Hierauf muß bereits auf der System-Ebene eingegangen werden.) Die Überlegungen gelten hier analog für die HW-Einheiten.

In den "Produkt"-Checklisten der Prüfspezifikation sind folgende Punkte zu ergänzen:

−	HW-Architektur

•	Erfüllt die HW-Architektur die Anwenderforderungen und die Technischen Anforderungen?

•	Sind die Schnittstellen zwischen Software und Hardware konsistent?

•	Enthält die HW-Architektur ausreichend detailliert den Grob- und Feinentwurf der HW-Bausteine?

−	Zeichnungssatz

•	Ist der Zeichnungssatz konsistent zur HW-Architektur?

•	Ist der Zeichnungssatz als Realisierungsvorgabe bzw. Bauplan ausreichend detailliert?

−	Realisierungsdokumente

•	Sind die Realisierungsdokumente konsistent zum Zeichnungssatz und zur HW-Architektur?


Entwurf von Prüfmitteln
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.3	Submodell Qualitätssicherung (QS)

HW.3.3	Entwurf von Prüfmitteln

Die Realisierung entsprechend aufwendiger Prüfmittel sollte in vereinfachter Form als eigenes Projekt nach dem V-Modell erfolgen.


Submodell Konfigurationsmanagement (KM)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.4	Submodell Konfigurationsmanagement (KM)

Nachfolgend werden Erläuterungen zur Anwendung des Konfigurationsmanagements gegeben.

−	Das Konfigurationsmanagement beschreibt Regelungen, die Submodell-übergreifend und für den gesamten Lebenszyklus, also unter Einbeziehung der Entwicklungs-, Fertigungs-, Nutzungs- und Wartungsphase festzulegen ist.

−	Je nach Fortschritt der Entwicklung werden der Umfang und die Verfahren des KM unterschiedlich sein, um einen sinnvollen Kompromiß zwischen Aufwand, Zeitbedarf und Nachvollziehbarkeit von Änderungen zu finden. Die Möglichkeit, Änderungen in den Anforderungen des Kunden während der Entwicklung zu berücksichtigen und konsequent nachvollziehbar zu machen, ist durch geeignete Maßnahmen, z. B. Dokumentation von Bezugskonfigurationen sicherzustellen.


Submodell Projektmanagement (PM)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.5	Submodell Projektmanagement (PM)

Die Aktivitäten des Projektmanagements sind auch auf die Entwicklung von Hardware übertragbar.

Im Projektplan, Kapitel 3.1.4 "Baselines", sind Baselines auch im Hinblick auf "Bezugskonfigurationen" (vgl. Submodell KM) zu definieren, sofern dies durch übergeordnete Vorschriften (z. B. STANAG 4159) entsprechend vorgegeben ist.


Produktmuster
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

In diesem Kapitel werden Erläuterungen zu den Produkten des operativen Moduls HW-Entwicklung gegeben.


Hardware-Anforderungen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.1	Hardware-Anforderungen

Die Hardware-Anforderungen an eine HW-Einheit werden im Kapitel 5 "Technische Anforderungen an SW-Einheiten/HW-Einheiten" im Produkt Technische Anforderungen genannt. Näheres ist Teil 1 "Regelungsteil" im Abschnitt 8.2.3 "Technische Anforderungen" zu entnehmen.


HW-Architektur (HwArc_)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.2	HW-Architektur (HwArc_)

In der HW-Architektur (Grobentwurf) werden Vorschläge für mögliche HW-Architekturen (Kapitel 2) und den ausgewählten Aufbau der HW-Einheit in HW-Komponenten und HW-Module (Kapitel 3) angegeben. Die Zusammenhänge zwischen HW-Komponenten und HW-Modulen werden dargestellt. Abschließend wird die Zuordnung zu den Anforderungen hergestellt (Kapitel 4).

HwArc_2  Lösungsvorschläge

Dieser Abschnitt nimmt eine Beschreibung und anschließende Bewertung möglicher Architekturen der HW-Einheit auf. Lösungsvorschläge für die Architektur der HW-Einheit werden skizziert. Sie beschreiben auf grobem Niveau die Zerlegung der HW-Einheit in Prozesse sowie in HW-Komponenten und HW-Module. Für jeden Lösungsvorschlag werden einzeln die Vor- und Nachteile (z. B. bzgl. Leistungsaufnahme und -abgabe, Wiederverwendbarkeit usw.) und die Realisierbarkeit dargestellt. Die Auswahl eines Lösungsvorschlags wird dokumentiert und begründet.

HwArc_3  Struktur der HW-Einheit

Die Modularisierung gibt die Zerlegung einer HW-Einheit in HW-Komponenten und HW-Module an. Ferner enthält dieser Abschnitt einen Grobentwurf (Blockschaltbild) der HW-Einheit. Timingdiagramme oder Stromlaufplanausschnitte werden zur Verdeutlichung der Texte ergänzt.

HwArc_3.1  Übersicht der HW-Komponenten/HW-Module der HW-Einheit

Alle HW-Module/HW-Komponenten werden mit ihren Identifikatoren und einer Langbezeichnung aufgelistet. Daneben sollte ergänzend eine grafische Darstellung (Blockschaltbild) gewählt werden, aus der die "Besteht-aus"-Hierarchie deutlich wird.

HwArc_3.2  Kritikalität der HW-Komponenten/HW-Module

In Tabellenform wird jeder HW-Komponente/jedem HW-Modul eine Kritikalitätsstufe zugeordnet. Die Kritikalitätsstufe leitet sich aus der Kritikalität der Funktion ab, die die HW-Komponente/das HW-Modul realisiert.

HwArc_3.3  Brückenplan

Hier erfolgt die Beschreibung der Brückenvarianten (z. B. Jumper).

HwArc_3.4  Adreßmap

Die Belegung des Adreßraumes der HW-Einheit mit einzelnen Funktionen wird dargestellt.

HwArc_3.5  Inhalt programmierbarer Bausteine

Logische Gleichungen der einzelnen programmierbaren Bausteine werden in Unterpunkten gegliedert.

HwArc_3.6  Nutzerhinweise

Besonderheiten beim Einsatz dieser HW-Einheit in einem Gerät, oder im Zusammenspiel mit anderen, bereits vorhandenen HW-Einheiten. Eine Beschreibung von Bestückungsvarianten und Verdrahtungshinweisen erfolgt hier ebenfalls.

HwArc_3.7  Einzelbeschreibungen

Jede HW-Komponente und jedes HW-Modul wird einzeln beschrieben. Ergänzt werden Timingdiagramme oder Stromlaufplanausschnitte zur Verdeutlichung der Texte.

HwArc_3.7.m  HW-Komponente bzw. HW-Modul (m)

Hinweis: "m" wird verwendet für eine fortlaufende Numerierung der HW-Komponenten bzw. HW-Module.

HwArc_3.7.m.1  Beschreibung der HW-Komponente/des HW-Moduls

Die HW-Komponente/das HW-Modul wird durch eine kurze Leistungsbeschreibung und die in Anspruch genommenen Ressourcen definiert.

HwArc_3.7.m.2  Kenndaten

HwArc_3.7.m.2.1  Mechanische Kenndaten

Auflistung der wichtigsten mechanischen Daten der (z. B. Maße, Steckverbindungen).

HwArc_3.7.m.2.2  Elektrische Kenndaten

Auflistung der wichtigsten elektrischen Daten (Leistungsbedarf, Temperatur).

HwArc_4  Anforderungszuordnung

Die Bezüge zu den Hardware-Anforderungen werden hergestellt. Es ist zu dokumentieren, ob alle Anforderungen abgedeckt werden und wie die Anforderungen auf HW-Komponenten/HW-Module heruntergebrochen wurden.

HwArc_Anhang

Literaturverzeichnis und Verweis auf Datenbücher, Beschreibungen und andere Dokumente.


Zeichnungssatz (ZeiS_)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.3	Zeichnungssatz (ZeiS_)

Der Zeichnungssatz enthält alle Informationen für die Fertigung der HW-Einheit. Insbesondere sind hier neben den Zeichnungen, Stücklisten, Verdrahtungsplänen, usw. auch Angaben zu Parametereinstellungen, Justagearbeiten, usw. zu machen.

Für jede HW-Einheit existiert ein solches Produkt.

ZeiS_2  Mechanik

ZeiS_2.1  Gesamtzeichnung

Die Gesamtzeichnung dokumentiert, wie z. B. der Baugruppenträger an welchen Positionen mit Steckplatten bestückt wird.

ZeiS_2.2  Leitungsliste

Die Leitungsliste dokumentiert die Verbindungen zwischen den HW-Einheiten.

ZeiS_2.3  Bearbeitungszeichnung für Lötseite

Sie dokumentiert die Leiterplatte über Leiterplattenausführung, Basismaterial, Metallisierung, Bestückungsdruck, Fotolayer, usw.

ZeiS_3  Elektronik

ZeiS_3.1  Stromlaufplan

Der Stromlaufplan beschreibt die gesamte Schaltung der HW-Einheit. Er bildet die Grundlage für die Platinenfertigung.

ZeiS_3.2  Stückliste

In der Stückliste sind sämtliche Bauteile der HW-Einheit aufgeführt. Ihre Verwaltung erfolgt erfolgt in der Regel rechnergestützt.

ZeiS_3.3  Bestückungsplan

Der Bestückungsplan dokumentiert, wie die Leiterplatte einer HW-Einheit zu bestücken ist, so daß daraus dann die eigentliche Steckplatte wird.


Realisierungsdokumente (RealD_)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.4	Realisierungsdokumente (RealD_)

Die Realisierungsdokumente enthalten Angaben zur Installation, Integration, zur sicherheitstechnischen Behandlung usw. der HW-Einheit, die im Rahmen der Realisierung erarbeitet bzw. festgelegt wurden.


Analysebericht (AnaB_)
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.5	Analysebericht (AnaB_)

Falls erforderlich, werden bei besonders hohen Anforderungen an die HW-Einheit bestimmte Analysen und Nachweisberechnungen durchgeführt und in dem/den Analysebericht(en) festgehalten.


Sonstige HW-relevante Unterlagen
Teil 3	Vorgehensmodell / Handbuchsammlung

HW	Hardwareerstellung

HW.6	Produktmuster

HW.6.6	Sonstige HW-relevante Unterlagen

Die Dokumente HW-Integrationsplan, HW-Prüfplan, HW-Prüfspezifikation, HW-Prüfprozedur, HW-Prüfprotokoll sind inhaltlich mit den Software-Dokumenten identisch und werden nicht separat aufgeführt.


Literaturverzeichnis AU250/3 - HW
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - HW)

A.1	Literaturverzeichnis

/STANAG 4159/	STANAG 4159 − NATO Materiel Configuration Management Policy and Procedures for Multinational Joint Projects. September 1991.


Einleitung
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.1	Einleitung

Zur Sicherstellung hoher Prozeß- und Produktqualität wird vom AG die Erfüllung von Qualitätsnormen gefordert. Im einzelnen können dies sein

−	DIN EN ISO 9001 oder

−	AQAP-110/AQAP-150.

Im folgenden wird erläutert, welche Teile dieser Forderungen durch Anwendung des V-Modells erfüllt werden können und wie damit Mehrfachaufwand sowohl beim Aufbau von Qualitätsmanagement-Systemen (AN-Seite) als auch bei der Zertifizierung (AG- und AN-Seite) vermieden werden kann. Daraus ist zu entnehmen, wie bei Anwendung des V-Modells das Erlangen entsprechender Zertifikate oder Bestätigungen erleichtert werden kann.

Weiter wird durch eine Zuordnungstabelle dargestellt, wie die Prozesse der ISO 12207 (Software Life Cycle Processes) durch die Aktivitäten des V-Modells abgedeckt werden. Diese Zuordung zeigt, daß das V-Modell bis auf wenige Ausnahmen, die alle außerhalb des Anwendungsbereichs des V-Modells liegen, die ISO 12207 erfüllt.


Zusammenhang der Qualitätsnormen
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.1	Zusammenhang der Qualitätsnormen

Für alle nationalen und internationalen Vorhaben, die keine NATO-Vorhaben sind, ist die ISO 9001 als der internationale und weltweit gültige Standard verbindlich anzuwenden. Für NATO-Vorhaben sind die AQAP-Normen gültig.

Abbildung ISO.1 zeigt das V-Modell als Basis eines Qualitätsmanagement-Systems zur Erfüllung der ISO und AQAP-Normen:

Abbildung ISO.1: Zusammenhang der Qualitätsstandards

Die AQAP-110 ist mit der ISO 9001 strukturgleich und integriert diese vollständig. Die meisten ISO-Forderungen werden in der AQAP-110 um einen NATO-spezifischen Zusatz (die sog. "NATO-Zusatzforderungen") erweitert.

Die AQAP-150 baut weder auf der AQAP-110 noch auf der ISO 9001 direkt auf.

Im folgenden werden die in Abbildung ISO.1 dargestellten Beziehungen erläutert.


ISO 9001-Konformität auf der Basis des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.2	ISO 9001-Konformität auf der Basis des V-Modells

AN, die ein Zertifikat gemäß DIN/ISO 9001 oder EN 29001 (im folgenden kurz ISO 9001) erlangen wollen, müssen ein Qualitätsmanagement-System betreiben und pflegen. Dabei ist zu beachten, daß ein derartiges Zertifikat auch für einzelne Unternehmensteile vergeben werden kann. Verlangt ein Auftrag ein Zertifikat als Vorbedingung, ist daher sicherzustellen, daß alle am Projekt beteiligten Unternehmensteile des AN in den Zertifizierungsbereich fallen.

Um ein ISO 9001-Zertifikat zu erlangen, sind u. a. alle Prozesse im Zertifizierungsbereich durch Verfahrensanweisungen zu regeln. Das V-Modell ist eine solche Verfahrensanweisung im Sinne der ISO 9001 (interpretiert durch die ISO 9000 Teil 3) für den Prozeß "Softwareentwicklung". Im Gegensatz zu anderen Verfahrensanweisungen stellt das V-Modell eine sehr umfassende Verfahrensanweisung dar, die viele Teilprozesse integriert. Im QM-Handbuch des AN muß daher (zumindest für Aufträge aus dem Verteidigungsbereich) das V-Modell verbindlich als Verfahrensanweisung eingebunden sein. Die Notwendigkeit der projektspezifischen Operationalisierung des V-Modells in der Form eines Projekthandbuchs steht damit in Einklang und bleibt bestehen.

Das V-Modell erfüllt die Anforderungen der ISO 9001 an den technischen Ablauf der Softwareentwicklung. Die organisatorischen Forderungen der ISO 9001 gehen darüber hinaus und müssen zusätzlich vom AN erfüllt werden. Das V-Modell ist somit ein Baustein zur Erfüllung der ISO 9001, der die Erlangung eines Zertifikats wesentlich vereinfacht, jedoch um organisatorische, AN-spezifische Regelungen ergänzt werden und in den AN-Kontext eingebettet werden muß (vgl. Rollenfestlegungen, usw.).

Aufgrund seiner Zielsetzung als funktionale Beschreibung des Vorgehens enthält sich das V-Modell jeglicher unternehmens- und einzelfallspezifischer Konkretisierung. Alles, was auf der Einbettung in das Unternehmen oder mit projektspezifischem Kontext zu tun hat, wird darin bewußt weggelassen.

Die folgende Tabelle beinhaltet ausgehend von den Gliederungspunkten der ISO 9000, Teil 3 (Leitfaden für die Anwendung der ISO 9001), die Zuordnung von V-Modell-Regelungen (Aktivitäten und Produkte) zu den ISO-Forderungen. Sie soll

−	die Abdeckung der einzelnen ISO-Forderungen durch das V-Modell aufzeigen und

−	die Umsetzung der ISO-Forderungen mittels Verweisen auf die V-Modell-Inhalte erleichtern.

Hierbei wird zwischen unmittelbarer und mittelbarer Erfüllung der ISO-Forderungen durch das V-Modell unterschieden ("direkt"/"indirekt"). Mittelbar bedeutet hierbei, daß das V-Modell Dokumente (z. B. PHb, QS-Plan) vorsieht, in denen die seitens ISO 9001 geforderten Konkretisierungen festgeschrieben werden.

Im folgenden wird aufgezeigt, welche organisatorischen Forderungen für eine ISO 9001-Zertifizierung im einzelnen zusätzlich erfüllt sein müssen:

1.	Die oberste Leitung des AN muß ihre Politik sowie ihre Zielsetzungen und ihre Verpflichtung zur Qualität festlegen und dokumentieren. Es ist sicherzustellen, daß diese Politik auf allen Ebenen der Organisation verstanden, verwirklicht und beachtet wird (ISO 9000, Teil 3, Kap. 4.1.1.1).

2.	Die Verantwortungen, Befugnisse und die gegenseitigen Beziehungen aller Mitarbeiter, die leitende, ausführende und überwachende Tätigkeiten ausüben, welche die Qualität beeinflussen, müssen festgelegt werden (ISO 9000, Teil 3, Kap. 4.1.1.2.1).

3.	Der AN muß die Forderungen an die interne Verifizierung festlegen, angemessene Mittel bereitstellen und ausgebildetes Personal für die Tätigkeiten der Verifizierung bestellen (ISO 9000, Teil 3, Kap. 4.1.1.2.2).

4.	Der AN muß einen Beauftragten der obersten Leitung ernennen, der die festgelegte Befugnis und Verantwortung besitzen muß, um sicherzustellen, daß die Forderungen der ISO 9001 erfüllt und ständig beachtet werden (ISO 9000, Teil 3, Kap. 4.1.1.2.3).

5.	Das QM-System muß in geeigneten Intervallen durch die oberste Leitung bewertet werden, um seine ständige Eignung und Wirksamkeit sicherzustellen. Aufzeichnungen über solche Reviews müssen aufbewahrt werden (ISO 9000, Teil 3, Kap. 4.1.1.3).

6.	Alle Elemente, Forderungen und Vorkehrungen für das QM-System sollten in einer systematischen und geordneten Weise in einem QM-Handbuch dokumentiert sein (ISO 9000, Teil 3, Kap. 4.2.2).

7.	Der AN muß ein umfassendes System geplanter und dokumentierter interner Qualitätsaudits einführen, um zu verifizieren, daß alle qualitätsrelevanten Tätigkeiten den geplanten Vorkehrungen entsprechen, und um die Wirksamkeit des QM-Systems festzustellen (ISO 9000, Teil 3, Kap. 4.3).

8.	Der AN muß Verfahren für die projektübergreifende Verbesserung (Korrekturmaßnahmen) einführen, dokumentieren und warten (ISO 9000, Teil 3, Kap. 4.4).

9.	Der AN sollte Verfahren zur Vertragsüberprüfung und für die Koordinierung dieser Tätigkeiten einführen und aufrechterhalten (ISO 9000, Teil 3, Kap. 5.2).

10.	Der AN sollte Verfahren für die Durchführung von Wartungstätigkeiten einrichten und aufrechterhalten (ISO 9000, Teil 3, Kap. 5.10).

11.	Der AN sollte quantitative Meßverfahren für die Qualität des Entwicklungs- und Lieferprozesses anwenden (ISO 9000, Teil 3, Kap. 6.4.2).

12.	Der AN sollte Verfahren zur Ermittlung des Schulungsbedarfs einführen und aufrechterhalten und für die Schulung der Mitarbeiter sorgen, die mit qualitätsrelevanten Tätigkeiten betraut sind (ISO 9000, Teil 3, Kap. 6.9).

Wenn der AG ein QM-System gemäß ISO 9001 fordert, so kann dies seitens des AN durch die Vorlage des zugehörigen, gültigen Zertifikats einer akkreditierten Zertifizierungsstelle nachgewiesen werden.

ISO 9000, Teil 3	V-Modell
	direkt		indirekt
	Regelung/ Aktivität	Produkt	Regelung/ Aktivität	Produkt
4 Qualitätssicherungs- system − Rahmen
4.1 Verantwortung der obersten Leitung
4.1.1 Verantwortung der obersten Leitung des  Lieferanten
4.1.1.1 Qualitätspolitik				QS-Plan
4.1.1.2 Organisation			Rollen/Aktivitäten Zuordnungen	Phb 7.1, 7.2
4.1.1.3 Review des Qualitäts- sicherungssystems durch die oberste Leitung
4.1.2 Verantwortung der obersten Leitung des Auftraggebers
4.1.3 Gemeinsame Reviews	PM 6	Berichts- dokumente		Projektplan 3.1.5
4.2 Qualitätssicherungs- system
4.2.1 Allgemeines
4.2.2 Dokumentation des Qualitätssicherungs- systems				V-Modell als eine der Ver- fahrensan- weisungen
4.2.3 Qualitätssicherungsplan	QS 1	QS-Plan, Prüfplan
4.3 Interne Qualitätsaudits			QS 5
4.4 Korrekturmaßnahmen	PM 6
a) Untersuchung der Ursache	PM 7	Berichts- dokumente	KM 4.7	Projekthistorie
b) Analyse der Prozesse		QS-Plan	QS 3
c) Fehlerverhütungs- maßnahmen	KM 3
d) Überwachungs- maßnahmen	KM 3, V-Modell  Änderungs- verfahren
e) Verfahrensänderungen	V-Modell Ände- rungsverfahren
5 Qualitätssicherungs- system − Lebenszyklus- tätigkeiten
5.1 Allgemeines	V-Modell
5.2 Vertragsüberprüfung
5.2.1 Allgemeines	PM 2		PM 1	Phb, geht in  Vertrag ein
5.2.2 Qualitätsrelevante Vertragspunkte	KM 3	Phb
5.3 Spezifikation des Auftraggebers
5.3.1 Allgemeines	SE 1.2−SE 1.6	Anwenderfor- derungen	QS 1.1	QS-Plan
5.3.2 Zusammenarbeit	SE 1.7	Protokoll		Phb 7.4
5.4 Planung der Entwicklung
5.4.1 Allgemeines	PM 1.1−1.3, 1.5	Phb, Projektplan
5.4.2 Entwicklungsplan
5.4.2.1 Phasen	SE, QS	Phb
5.4.2.2 Management	PM	Phb, Projektplan
5.4.2.3 Entwicklungsmethoden und Werkzeuge	PM 1.4	Phb 6
5.4.3 Entwicklungslenkung	PM 6, PM 8, QS 1.2	Prüfplan
5.4.4 Vorgaben für Entwicklungsphasen	PM 4	PHb
5.4.5 Ergebnisse der Entwicklungsphasen	QS 2, 4	Phb, Prüfspe- zifikation (Verifikation)
5.4.6 Verifizierung jeder Phase	PM 6	Projektplan (zur Termin- planung)
5.5 Planung der Qualitätssicherung
5.5.1 Allgemeines	QS 1.1, 1.2	QS-Plan, Prüfplan
5.5.2 Inhalt des Qualitäts- sicherungsplans
a) Qualitätsziele	QS 1.1	QS-Plan
b) Kriterien	QS 2.1, 2.2	QS-Plan
c) Arten	QS 1.1	QS-Plan
d) Planung	QS 2	Prüfplan
e) Verantwortungen	QS 1	QS-Plan
5.6 Design und Implementierung
5.6.1 Allgemeines
5.6.2 Design
a) Designgesichtspunkte	PM 1.3, SE 1 bis SE 5-SW	Phb
b) Designmethodik	PM 1.4, SE 1 bis SE 5-SW	Phb 6
c) Designerfahrungen	KM 4.5
d) nachfolgende Prozesse		Technische  Anforderungen
5.6.3 Implementierung
a) Regeln	SE 6-SW	PHb 8
b) Implementierungs- methoden		PHb 6
5.6.4 Reviews	QS 4, PM 6, Produktfluß gemäß V-Modell	Prüfprotokoll → KM
5.7 Testen und Validierung
5.7.1 Allgemeines
5.7.2 Testplanung
a) Testpläne	QS 2	Prüfpläne
b) Testfälle	QS 2.3	Prüfspezifi- kation
c) Testarten	QS 1.1, 2.1	QS-Plan 5
d) Testumgebung	QS 2.2	Prüfplan 5.1
e) Kriterien		Prüfspezifi- kation
f) Anwender- dokumentation
g) Personal	PM 1.1, QS 1.2	Phb 7, Prüfplan 3
5.7.3 Testen
a) Testergebnisse		Prüfprotokoll
b) Probleme	QS 5
c) durch Änderungen betroffene Bereiche	KM 3
d) Angemessenheit	QS 4	Prüfplan 2
e) HW- und SW- Konfiguration	KM 2	KID
5.7.4 Validierung	QS 4 (für das System)
5.7.5 Feldversuch	QS 4 (mit bes. Prüfkriterien)
5.8 Annahme
5.8.1 Allgemeines	QS 4			Phb
5.8.2 Planung der Abnahme- prüfungen	QS 2			Vertrag
5.9 Vervielfältigung, Liefe- rung und Installierung
5.9.1 Vervielfältigung			Vertrag
a) Kopien		Phb
b) Art des Datenträgers		Phb
c) Dokumentation		Phb
d) Copyright
e) Verwahrung	KM 4.4
f) Lieferverpflichtung
5.9.2 Lieferung	SE 8.3	QS-Plan 5.3
5.9.3 Installierung	SE 9.2		Vertrag
5.10 Wartung
5.10.1 Allgemeines	KM 3
5.10.2 Wartungsplan	SE 1.8	SWPÄ-Kon- zept
5.10.3 Identifikation des Aus- gangszustands des Produkts	KM 4.4
5.10.4 Unterstützende Organisation	SE 1.8	SWPÄ-Kon- zept	Vertrag
5.10.5 Arten von Wartungs- tätigkeiten		KM-Plan
5.10.6 Wartungsaufzeichnungen und -Berichte	KM 3
5.10.7 Freigabeverfahren	gemäß Produktfluß V-Modell	KM-Plan
a) Freigabe			Teil 1, Kapitel 2.3
b) Freigabearten
c) zukünftige Änderungen			KM
d) Änderungsverfahren
e) Änderungs- aufzeichnungen	KM 3

6	Qualitätssicherungssystem-unterstützende Tätigkeiten (phasenunabhängig)

6.1 Konfigurations- management
6.1.1 Allgemeines	KM
6.1.2 Konfigurations- managementplan	KM 1, PM 1	KM-Plan
a) Organisation		Projektplan
b) Tätigkeiten		Phb 5
c) Werkzeuge		Phb 6
d) Stadium der Elemente		KM-Plan 3
6.1.3 Konfigurations- management-Tätigkeiten
6.1.3.1 Identifikation und Rück- verfolgbarkeit der Konfiguration	KM 2	KM-Plan KID
6.1.3.2 Lenkung von Änderungen	KM 3
6.1.3.3 Konfigurations- Statusbericht	KM 2	KID
6.2 Lenkung der  Dokumente
6.2.1 Allgemeines	Produktflüsse gemäß V-Modell
a) Dokumente
b) Genehmigung	V-Modell Ände- rungsverfahren
c) Änderungsabläufe	PM 1 (Tailoring)
6.2.2 Arten von Dokumenten
a) Verfahrens- anweisungen
b) Planungsdokumente	Produktflüsse  gemäß V-Modell
c) Produktdokumente	Produktflüsse  gemäß V-Modell
6.2.3 Genehmigung und Her- ausgabe von Dokumen- ten
a)  Verfügbarkeit			KM
b) überholte Dokumente			V-Modell Erlaß
6.2.4 Änderung von Dokumenten		KM-Plan	KM 2	Phb 4.3
6.3 Qualitätsaufzeichungen		QS-Plan 5.2	V-Modell (KM)
6.4 Messungen
6.4.1 Messungen am Produkt	QS 5
6.4.2 Prozeßmessung			QS 3, PM 8, KM 4.7
6.5 Regeln, Praktiken und Übereinkommen
6.6 Werkzeuge und Techniken			Phb 4.3 6
6.7 Beschaffung
6.7.1 Allgemeines	PM 2; SE 1, SE 2	Prüfspezifi- kation
6.7.2 Beurteilung von Unter- lieferanten				QS-Plan 5.2
6.7.3 Validierung von be- schafften Produkten	QS 2, QS 4	Prüfspezifi- kation
6.8 Beigestelltes Softwareprodukt	PM 2, QS 2, QS 4	Prüfspezifi- kation
6.9 Schulung	PM 10
Tabelle ISO.1:	Abdeckung der ISO 9001 durch das V-Modell


AQAP-150-Konformität auf der Basis des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.3	AQAP-150-Konformität auf der Basis des V-Modells

Die AQAP-150 ergänzt projektspezifisch die Regelungen der organisationsspezifischen AQAP-110 in bezug auf die Anwendung bei der Softwareentwicklung. Wie die ISO 9000 Teil 3 fordert die AQAP-150 unter anderem ein Prozeßmodell für die Softwareentwicklung. Diese Forderung kann durch das Anwenden des V-Modells erfüllt werden.

Die AQAP-150 sieht zusätzlich als Basisdokument des Qualitäts-Management-Systems (QM-Systems) einen umfassenden QS-Plan (SPQP-Plan) vor. Die für diesen Plan geforderten Inhalte werden durch folgende V-Modell-Dokumente abgedeckt (siehe Tabelle ISO.2):

1.	Projekthandbuch (PHb)

2.	Projektplan

3.	QS-Plan

4.	KM-Plan

5.	Prüfplan

AQAP-150 (Version März 1993)	AU 250
Kapitel des QS-Plans	Kapitel
		QS-Plan	PHb	Projekt- plan	KM-Plan	Prüfplan
0	Deckblatt
1	Einleitung
1.1 1.2 1.3 1.4 1.5	Zweck Anwendungsbereich Fortschreibung des SPQP Bezugsdokumente Beziehung zu anderen Dokumenten	1 1 − 1 1
2	Projektbeschreibung
2.1 2.2 2.3	Überblick über das Projekt Annahmen Auszuliefernde Produkte	1	2 2; 3 3
3	Management
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8	SW-Entwicklungsprozeß Organisation Korrekturmaßnahmen Maßnahmen bzgl. Unteraufträgen Konfigurationsmanagement Bereits entwickelte SW Aufbewahrung von Aufzeichnungen Handhabung und Aufbewahrung von Datenträgern	(5.3) 5.2 (5.6) (5.1) 5.6	4; 5 7 7 4	2; 4	3   gesamt 2.2 4 4
4	Softwaretechnik
4.1 4.2 4.3	SW-Entwicklungsumgebung Methoden/Verfahren/Normen Entwicklungdokumentation		6 6; 8 5
5	Bewertung und Verifizierung (E/V)	3	5			gesamt
Geklammerte Angaben weisen eine teilweise Abdeckung aus.

Tabelle ISO.2:	Entsprechungen des V-Modells zum QS-Plan des AQAP-150

Zur vollständigen Abdeckung der AQAP-150 müssen zusätzlich folgende, über das V-Modell hinausgehende Anforderungen an ein QM-System erfüllt werden. Die nachfolgende Liste ist eine Orientierungshilfe. Verbindlich ist allein der Originaltext der AQAP-150.

1.	SW-Qualitätsmanagement-System (QM-System)

1.1	Der AN soll ein dokumentiertes, wirksames und leistungsfähiges QM-System für das Vertragsobjekt einsetzen, das ein Teil eines umfassenden integrierten Qualitätsmanagementsystems ist.

1.2	Periodische und systematische Reviews durch den AN sollen vorbereitet sein, die die Wirksamkeit des QM-Systems sicherstellen.

1.3	Es müssen Vorkehrungen getroffen sein, damit das QM-System durch den AN regelmäßig und systematisch überprüft wird.

Folgende Forderungen der AQAP-150 sind als ergänzende Vorgaben in das PHb aufzunehmen:

2.	Qualität der Fertigprodukte

Auch für SW-Produkte, die nicht ausgeliefert werden, muß die Qualität nachweisbar sein.

3.	Definition und Review der Software-Anforderungen

Der AG ist so früh wie möglich über eventuelle Unsicherheiten bei der Auslegung und Realisierung von vertraglich geforderten Software-Leistungs- und Qualitätsmerkmalen zu unterrichten.

4.	Ermittlung und Überprüfung von Software-Anforderungen

4.1	Die SW-Anforderungsdokumentation muß eine klare und präzise Beschreibung der Entwurfsbeschränkungen enthalten und getrennt von den Produkteigenschaften/-charakteristiken ausgewiesen werden.

4.2	Im PHb muß festgelegt werden, welche Standards oder Leitlinien für Format und Inhalt der Spezifikation anzuwenden sind.

4.3	Nach erfolgreichem Abschluß der Überprüfung von Software-Anforderungen sind die Software-Anforderungsspezifikationen von den zuständigen Stellen offiziell zu genehmigen und dem Konfigurationsmanagement zu unterziehen. Es ist eine entsprechende Durchführungsentscheidung unter Beteiligung des AG im PHb dafür einzuplanen.

4.4	Jede Forderung muß so definiert sein, daß ihre Erfüllung mit Hilfe einer vorgeschriebenen Methode objektiv verifiziert werden kann.

4.5	Im QS-Plan ist anzugeben, welche Normen oder Richtlinien für Form und Inhalt der Spezifikationen gelten.

5.	SW-Entwicklungsprozeß

Alle konstruktiven und analytischen Qualitätsmaßnahmen müssen bewährt und geeignet sein. (Diese Forderung wird durch Anwendung der Methodenzuordnung erfüllt).

6.	Organisation

Die Organisationseinheiten oder Personen, die mit der Prüfung beauftragt sind, müssen ausreichend mit Hilfsmitteln, Verantwortung und Vollmachten ausgestattet sein.

7.	Fertigprodukte

7.1	Die Dokumentation von Fertigprodukten hat so zu geschehen, daß sie mit den Forderungen des Vertrages und der AQAP-150 übereinstimmt.

7.2	Wenn im Rahmen des Entwicklungsprozesses bereits entwickelte Software modifiziert wird, ist sie als Entwicklungssoftware zu behandeln.

8.	Handhabung und Aufbewahrung von Datenträgern

8.1	Der AN hat ein Sicherheitssystem zum Einsatz zu bringen, das den Zugriff auf Software nur über einen Autorisierungsprozeß ermöglicht und die Software nur den Personen zugänglich macht, die darauf Zugriff haben müssen.

8.2	Der AN hat sicherzustellen, daß die SW lesbar ist und bleibt.

8.3	Der AN hat sicherzustellen, daß SW und Baseline-SW (Bezugskonfigurationen) eine zusätzliche ausgelagerte Speicherung erfahren und wieder auffindbar sind.

8.4	Der AN hat dafür zu sorgen, daß Freigabe und Auslieferung von SW ausreichend dokumentiert, nachvollziehbar und kontrolliert erfolgt.

8.5	Der AN hat sicherzustellen, daß eine Überwachung und Lenkung des Replikationsprozesses zur Erzeugung mehrerer kundenindividuell angepaßter Softwareversionen erfolgt.

9.	Softwaretechnik

9.1	Der AN soll alle Notationen (auch die grafischen) standardisieren.

9.2	Die Entwicklung soll so unterstützt werden, daß alle SW-Qualitätsmerkmale über alle Entwurfs- und Implementierungsebenen verfolgt werden können.

10.	Maßnahmen bezüglich Unteraufträgen

Der AN soll Verfahren zur Auswahl von UAN einsetzen und Verfahrensregelungen einführen zur Beherrschung der Schnittstelle zum UAN.

11.	Zugang und Beteiligung des AGs

Der AN hat dem AG Zugang zu seinen eigenen Einrichtungen bzw. denen seiner UAN zu verschaffen und ihm jede − gemäß den vertraglichen Forderungen notwendige − Unterstützung bei der Bewertung des Software-Qualitätsmanagementprogramms und der Prüfung der Softwareprodukte zu leisten.

12.	Bewertung und Verifizierung

Quantitative/qualitative Bewertungskriterien sind ebenfalls anzuwenden für das Management und die Lenkung des Entwicklungsprozesses für das vertraglich geforderte Softwareprodukt. Sie müssen die Feststellung des aktuellen Leistungsniveaus, die Einleitung von Abhilfemaßnahmen und die Festlegung von Verbesserungszielen ermöglichen.

Fordert der AG ein QM-System nach AQAP, so kann dies seitens des AN durch die Vorlage einer "Formellen Bestätigung" von BWB-AT nachgewiesen werden. Diese Bescheinigung impliziert das Vorliegen eines ISO-Zertifikats.


Formelle nicht vertragsbezogene Bestätigung
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.4	AQAP-110/150-Konformität auf der Basis eines ISO-9001-Zertifikats

ISO.2.4.1	Formelle nicht vertragsbezogene Bestätigung

Benötigt ein Unternehmen eine formelle, nicht vertragsbezogene Bestätigung nach AQAP-110/150, wird BWB-AT auf Antrag bei Vorliegen eines Zertifikats eines akkreditierten Zertifizierers nach ISO 9001 und nach erfolgreicher eigener Prüfung bezogen auf die NATO-Zusatzbestimmungen aufgrund eines bestehenden Entwicklungsvertrags, der der Güteprüfung durch BWB-AT unterliegt, formell bestätigen, daß das QM-System des AN die Forderungen der AQAP-110/150 erfüllt.

Diese "Formelle Bestätigung" bekommt eine Gültigkeit entsprechend der Laufzeit des ISO-Zertifikats und kann unter bestimmten Voraussetzungen verlängert werden.


Formlose vertragsbezogene Bestätigung
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.4	AQAP-110/150-Konformität auf der Basis eines ISO-9001-Zertifikats

ISO.2.4.2	Formlose vertragsbezogene Bestätigung

BWB-AT wird bei Verträgen mit AQAP-110/150 eine eingehende Prüfung des QM-Systems, bezogen auf die Entwicklung von Wehrmaterial vornehmen, um festzustellen, ob die Forderungen der vereinbarten AQAP erfüllt sind. Nach erfolgreichem Abschluß einer solchen Prüfung wird dem AN formlos mitgeteilt, daß das QM-System für den vorliegenden Vertrag die Forderungen der AQAP 110/150 abdeckt.

Das Vorliegen einer formlosen, vertragsbezogenen Bestätigung ist eine Voraussetzung für die Verlängerung der "Formellen Bestätigung".

Hinweis: Der AN kann eine projektspezifische Erfüllung der AQAP-150 durch den Einsatz des V-Modells wesentlich einfacher erreichen. Die Bestätigung der AQAP-Konformität (durch eine Prüfung seitens BWB-AT) geschieht jedoch grundsätzlich auf der Basis der originären AQAP-Forderungen.


Zusammenhang von V-Modell, ISO 900x und AQAP
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.2	Erfüllung der Qualitätsnormen

ISO.2.5	Zusammenhang von V-Modell, ISO 900x und AQAP

Alle Standards (V-Modell, ISO 9001, AQAP-110, AQAP-150) erfahren vor ihrer Anwendung eine Ausprägung.

V-Modell:	Das Projekthandbuch (PHb) durch Ausschreibungsrelevantes Tailoring

ISO 9001:	Durch Einführung eines QM-Systems beim AN, repräsentiert durch das QM-Handbuch.

AQAP-150:	Durch Anwendung eines QM-Systems.

Abbildung ISO.2 zeigt den Zusammenhang der Standards und die Repräsentation in den Ausprägungsebenen.

Abbildung ISO.2: Beziehungen der Standards und ihrer Ausprägung

Legende zu Abbildung ISO.2 (Erläuterungen der Pfeile):

1.	Der ISO 9000-3 ist abgeleitet aus dem ISO 9001, besitzt aber eine andere Struktur; er ist ein Leitfaden zur Anwendung des ISO 9001.

2.	AQAP-150 ist abgeleitet aus der AQAP-110, besitzt aber eine andere Struktur.

3.	Das Projekthandbuch wird aus dem generischen V-Modell durch projekt- oder bereichsspezifisches Tailoring erzeugt.

4.	Im Hinblick auf die Zertifizierung ist das QM-System des AN gestaltet unter Berücksichtigung der Forderungen der ISO 9001.

5.	Die NATO-Zusatzbestimmungen der AQAP-110 enthalten die Bedingungen der Güteprüfung.

6.	Das QM-System des AN garantiert seine Nachweisfähigkeit. Es wird gefordert durch ISO 9001 (AQAP-110) und AQAP-150.

7.	Das PHb ist bestimmend für die relevante V-Modell-Teilmenge. Es existiert in einer vertragsrelevanten Form und ist Grundlage für das Technische Tailoring, dessen Regeln ebenfalls vertragsrelevant im PHb festgelegt sind.

8.	Ein QM-System nach ISO-9001 (und damit auch AQAP-110) verlangt nach einem Entwicklungsmodell, repräsentiert durch das V-Modell.

9.	AQAP-150 kann sowohl für sich als auch in Verbindung mit AQAP-110 (empfohlen von AQAP-150 für allgemeine Projekte mit einer SW-Ergänzung) als SW-spezifische und projektorientierte Ergänzung verwendet werden. AQAP-150 verlangt ein wirksames QM-System, das projektspezifisch oder Teil eines allgemeinen QM-Systems sein kann.

10.	Der ISO 9001 kommt für SW-Projekte in der Interpretation des ISO 9000-3 zur Anwendung. Bei zertifizierten Unternehmen ist er mittels QM-System verwirklicht.


Korrespondenz des V-Modells zur ISO 12207
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

Der Internationale Standard ISO 12207 ist ein weltweit akzeptierter Standard für Software-Lifecycle-Prozesse. Er ist zwar ungeeignet für den direkten Einsatz in einem konkreten Projekt, gibt jedoch einen Rahmen vor, der es erlaubt, nationale Standards einzuordnen oder entsprechende Detaillierungen der Prozesse vorzunehmen, um zu einem in der Praxis anwendbaren Standard zu kommen. Weiter beinhaltet die ISO 12207 Definitionen, die als Basis für eine gemeinsame Terminologie auch für nationale Standards dienen kann.

In folgenden wird ein Überblick über die ISO 12207 gegeben, und es wird dargestellt, wie die Prozesse der ISO 12207 durch das V-Modell realisiert werden.


Überblick über die ISO 12207
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.1	Überblick über die ISO 12207

Nachfolgend werden der Anwendungsbereich des Standards ISO 12207, der Ablauf eines Projektes, die Auftragsvergabe und die Beteiligung verschiedener Stellen bei einer Durchführung nach ISO 12207 erläutert.

Die ISO 12207 kann für die Beschaffung, die Lieferung, die Entwicklung, den Betrieb und die Wartung von Systemen/Software angewendet, unabhängig davon, ob die Entwicklung organisationsintern durchgeführt oder extern vergeben wird. Sie gilt sowohl für Software als eigenständiges Produkt als auch für Software als Bestandteil eines Gesamtsystems.

Der typische Anwendungsfall liegt in einem AG-AN-Verhältnis, wobei diese beiden Rollen jedoch auch innerhalb eines Unternehmens besetzt sein können. Neben der Softwareentwicklung regelt der Standard auch den Betrieb und die Wartung des Systems und betrachtet auch Aspekte wie Qualitätssicherung und Projektmanagement.

Der Standard muß für den Einsatz in einem konkreten Projekt auf die jeweiligen Erfordernisse zugeschnitten werden (Tailoring), dabei werden nicht relevante Aufgaben gestrichen.

Die ISO 12207 schreibt kein Entwicklungsmodell (LC-Modell) vor, sondern liefert einen Software Life-Cycle, in welchen im Projektfall ein ausgewähltes Entwicklungs-/Vorgehensmodell einzubinden bzw. darauf abzubilden ist. Mit Hilfe von Prozessen, die weiter in Aktivitäten zerlegt werden, beschreibt die ISO 12207 den SW-Life-Cycle. Die Aktivitäten werden weiter in Aufgaben (tasks) zerlegt, die aber − nachdem kein konkretes Vorgehensmodell spezifiziert werden soll − weder vollständig noch im Detail ausgeführt werden. Die ISO 12207 enthält auch keine Regelungen bzgl. anzuwendender Methoden oder zu erstellender Produkte. Diese Festlegungen bleiben dem Anwender des Standards vorbehalten.

Die Abbildung ISO.3 gibt einen Überblick über die in der ISO 12207 geregelten Prozesse: fünf "primary" Prozesse (Acquisition, Supply, Development, Operation, Maintenance), acht "supporting" Prozesse (Documentation, Configuration Management, Quality Assurance, Verification, Validation, Joint Review, Audit, Problem Resolution) und vier "organizational" Prozesse (Management, Infrastructure, Improvement, Training).

Dabei werden die "organizational" Prozesse von allen "primary" Prozessen angesteuert, die "primary" Prozesse initiieren auch die "supporting" Prozesse, und sie aktivieren sich z. T. auch gegenseitig.

Abbildung ISO.3: Die Prozesse der ISO 12207

Die ISO 12207 gliedert den Software-Lebenszyklus anhand von fünf verschiedenen Rollen (genannt: "major parties"), welche in den Lebenszyklus der Software, abhängig vom jeweils aktuellen Prozeß, eingebunden sind. Diese Rollen führen einen Prozeß entweder selbst durch oder aber sind verantwortlich für die Durchführung und initiieren und überwachen den Prozeß.

Acquirer: Dieser Rolle obliegt der Beschaffungsprozeß ("acquisition process") von der Bedarfsdefinition und Initiierung, Ausschreibung und Vertragsgestaltung über die Kontrolle des Auftragnehmers bis zur Abnahme.

Supplier: Dieser Rolle obliegt der Lieferprozeß ("supply process") von der Angebotsabgabe und Vertragsunterzeichnung bis zur Auslieferung.

Developer: Dieser Rolle obliegt der eigentliche Entwicklungsprozeß ("development process") der unter Umständen bereits die System-Anforderungsanalyse beinhaltet und bis zur Installation und Einführung reicht.

Operator: Dieser Rolle obliegt der Betriebsprozeß ("operation process"), welcher die Überprüfung, Durchführung und Unterstützung des Betriebes umfaßt.

Maintainer: Dieser Rolle obliegt der Wartungsprozeß ("maintenance process") von der Modifikation über Migration bis zur Ausmusterung.


Abdeckung der Prozesse der ISO 12207 durch das V-Modell
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.2	Abdeckung der Prozesse der ISO 12207 durch das V-Modell

Die Gliederung der nachfolgenden Zuordnungen orientiert sich an der Struktur der ISO 12207. Zuordnung bedeutet dabei nicht Gleichheit, da die Inhalte von ISO-Prozessen und Aktivitäten des V-Modells in den beiden Entwicklungsstandards unterschiedlich aufgeteilt sind.

Produkte werden nicht zugeordnet, nachdem die ISO 12207 produktbezogene Regelungen nicht enthält.


Zuordnung von Aktivitäten des V-Modells zu den Primary Processes
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.2	Abdeckung der Prozesse der ISO 12207 durch das V-Modell

ISO.3.2.1	Zuordnung von Aktivitäten des V-Modells zu den Primary Processes

Die Prozesse Acquisition und Supply können vom V-Modell nur teilweise abgedeckt werden.

Der Prozeß Development kann vollständig über das V-Modell realisiert werden. Dabei werden im Development Prozeß des ISO 12207 nicht nur SE-Aktivitäten des V-Modells angesprochen, sondern auch QS- und z. T. auch PM- und KM-Aktivitäten. In den Aufgaben der ISO 12207 werden zu den SE-Entwicklungsaktivitäten die zugehörigen Prüftätigkeiten innerhalb des Development Prozesses mit aufgeführt. Obwohl die ISO 12207 eigenständige Qualitätssicherungs-Prozesse definiert hat (siehe "Supporting Processes"), werden diese hier nicht referenziert. Aus diesem Grunde umfaßt der Development Prozeß das Submodell SE (ausgenommen die Hardware) und Teile des Submodells QS des V-Modells.

Der Prozeß Maintenance wird insofern über das V-Modell abgedeckt, soweit allgemeine SW-Pflege- und -Änderungsaktivitäten betroffen sind. Den Aspekt "Software Retirement" betrachtet das V-Modell jedoch nicht.

Nachdem das V-Modell ein Entwicklungsstandard ist, wird der Prozeß Operation nicht geregelt, jedoch sind einige QS-, KM- und PM-Aktivitäten durchaus auch auf den Betrieb übertragbar.

Acquisition Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Initiation	SE 1.1	"Ist-Aufnahme/-Analyse durchführen"
	SE 1.2	"Anwendungssystem beschreiben"
	SE 1.3	"Kritikalität und Anforderungen an die Qualität definieren"
	SE 1.4	"Randbedingungen definieren"
	SE 1.5	"System fachlich strukturieren"
	SE 2.3	"Realisierbarkeit untersuchen"
	PM 1.1	"Projekt einrichten"
	PM 1.2	"Projektkriterien und Entwicklungsstrategie festlegen"
Request-for-Proposal Preparation	PM 1.3	"Projektspezifisches V-Modell erstellen"
	PM 2	"Vergabe/Beschaffung"
Contract Preparation and Update	PM 2	"Vergabe/Beschaffung"
	KM 3	"Änderungsmanagement (Konfigurationssteuerung)"
Supplier Monitoring	PM 3	"Auftragnehmer-Management"
	PM 6	"Durchführungsentscheidung"
Acceptance and Completion
Supply Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Initiation
Preparation of Response	PM 1.3	"Projektspezifisches V-Modell erstellen"
Contract
Planning	PM 1.4	"Toolset-Management durchführen"
	PM 1.5	"Grobplan erstellen"
	QS 1	"QS-Initialisierung"
Execution and Control	PM 3	"Auftragnehmer-Management"
	PM 4	"Feinplanung"
	PM 7	"Risikomanagement"
	PM 8	"Projektkontrolle und -steuerung"
	PM 9	"Informationsdienst/Berichtswesen"
Review and Evaluation	PM 6	"Durchführungsentscheidung"
	QS 4	"Produktprüfung"
	QS 5	"QS-Berichtswesen"
Delivery and Completion	PM 14	"Projektabschluß"
Development Process (1)

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	PM 1.3	"Projektspezifisches V-Modell erstellen"
	PM 1.5	"Grobplan erstellen"
	PM 1.4	"Toolset-Management durchführen"
	PM 4	"Feinplanung"
System Requirements Analysis	SE 1.2	"Anwendungssystem beschreiben"
	SE 1.5	"System fachlich strukturieren"
	QS 4	"Produktprüfung"
System Architectural Design	SE 2.1	"System technisch entwerfen"
	SE 2.4	"Anwenderforderungen zuordnen"
	SE 2.5	"Schnittstellen beschreiben"
	SE 2.3	"Realisierbarkeit untersuchen"
	QS 4	"Produktprüfung"
Software Requirements Analysis	SE 3	"SW-/HW-Anforderungsanalyse"
	QS 4	"Produktprüfung"
	PM 6	"Durchführungsentscheidung"
Software Architectural Design	SE 4.1-SW	"SW-Architektur entwerfen"
	SE 4.2-SW	"SW-interne und -externe Schnittstellen entwerfen"
	QS 2.1	"Prüfmethoden und -kriterien festlegen"
	QS 4	"Produktprüfung"
	PM 6	"Durchführungsentscheidung"
Software Detailed Design	SE 5.1-SW	"SW-Komponente/-Modul/Datenbank beschreiben"
	QS 1.2	"Prüfplan erstellen"
	QS 2.1	"Prüfmethoden und -kriterien festlegen"
	QS 4	"Produktprüfung"
	PM 6	"Durchführungsentscheidung"
Software Coding and Testing	SE 6.1-SW	"SW-Module codieren"
	SE 6.2-SW	"Datenbank realisieren"
	QS 2.3	"Prüffälle festlegen"
	QS 2.4	"Prüfprozedur erstellen"
	SE 6.3-SW	"Selbstprüfung des SW-Moduls/der Datenbank durchf."
	QS 4	"Produktprüfung"
Development Process (2)

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Software Integration	SE 4.3-SW	"SW-Integration spezifizieren"
	SE 7-SW	"SW-Integration"
	QS 2.3	"Prüffälle festlegen"
	QS 2.4	"Prüfprozedur erstellen"
	QS 4	"Produktprüfung"
	PM 6	"Durchführungsentscheidung"
Software Qualification Testing	QS 4	"Produktprüfung"
	KM 2	"Produkt- und Konfigurationsverwaltung"
	KM 4.4	"Ergebnisse sichern"
	PM 6	"Durchführungsentscheidung"
System Integration	SE 8	"System-Integration"
	QS 2.3	"Prüffälle festlegen"
	QS 2.4	"Prüfprozedur erstellen"
	QS 4	"Produktprüfung"
System Qualification Testing	QS 4	"Produktprüfung"
	KM 2	"Produkt- und Konfigurationsverwaltung"
	KM 4.4	"Ergebnisse sichern"
	PM 6	"Durchführungsentscheidung"
Software Installation	SE 9	"Überleitung in die Nutzung"
Software Acceptance Support	SE 9	"Überleitung in die Nutzung"
	PM 6	"Durchführungsentscheidung"
Operation Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
	KM 3	"Änderungsmanagement (Konfigurationssteuerung)"
Operational Testing	QS 4	"Produktprüfung"
System Operation
User Support
Maintenance Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	SE 1.8	"Software-Pflege- und Änderungs-Konzept erstellen"
	KM 3	"Änderungsmanagement (Konfigurationssteuerung)"
Problem and Modification Analysis	KM 3.1	"Änderung bewerten"
Modification Implementation	KM 3.2	"Änderungsvorgehen entscheiden und Änderung einl."
Maintenance Review / Acceptance	KM 3.3	"Änderung abschließen"
	QS 4	"Produktprüfung"
Migration
Software Retirement
Tabelle ISO.3:	Zuordnung der Primary Processes zu Aktivitäten des V-Modells


Supporting Processes
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.2	Abdeckung der Prozesse der ISO 12207 durch das V-Modell

ISO.3.2.2	Supporting Processes

Das V-Modell kennt keine separate Dokumentationsaktivität. Documentation ist grundsätzlich in der Aktivitätendurchführung mit enthalten. Eine Zuordnung der V-Modell-Aktivitäten ist aus diesem Grund nicht möglich, wenngleich der Dokumentationsprozeß gesehen über das gesamte V-Modell selbstverständlich vollständig erfüllt wird.

Der Configuration Management Prozeß der ISO 12207 behandelt neben der Konfigurationsverwaltung und dem Änderungsmanagement des V-Modells auch "Configuration Evaluation". Auf Seiten des V-Modells kann hier keine unmittelbare Parallele gefunden werden.

Nach ISO 12207 werden Joint Review, Audit, Verification und Validation als Techniken des Prozesses Quality Assurance angesehen. Nachdem jedoch der Quality Assurance Prozeß nur grob angerissen wird, fehlt eine explizite Einordnung dieser Techniken. Wenngleich das V-Modell alle die aufgeführten QA-Aspekte abdeckt, ist aufgrund der in ISO 12207 allgemein gehaltenen Aussagen und der Mischung zwischen Aktivitäten (hier: "tasks") und Methoden (hier: "techniques") eine 1:1-Zuordnung zwischen V-Modell und ISO 12207 nicht immer möglich.

Das V-Modell trennt strikt zwischen den Aktivitäten Prozeßprüfung, Produktprüfung und Durchführungsentscheidung sowie auf Seiten der Methodenzuordnung zwischen Audit, Review (technischer Review und Durchführungsreview) und Testen, wobei sich der Einsatz der jeweiligen Methode an den "Prüfobjekten" (Software, Produkt, Aktivität, Projektverlauf) orientiert.

Documentation Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	PM 1.3	"Projektspezifisches V-Modell erstellen"
	PM 1.5	"Grobplan erstellen"
	PM 4	"Feinplanung"
	KM 2.1	"Produkt initialisieren"
Design and Development		Produktmuster
	QS 4	"Produktprüfung"
Production
Maintenance	KM 3	"Änderungsmanagement (Konfigurationssteuerung)"
Configuration Management Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	KM 1.1	"KM-Plan erstellen"
Configuration Identification	KM 1.2	"KM einrichten"
	KM 2	"Produkt- und Konfigurationsverwaltung"
Configuration Control	KM 3	"Änderungsmanagement (Konfigurationssteuerung)"
Configuration Status Accounting	KM 4.5	"KM-Dokumentation führen"
	KM 4.7	"Projekthistorie führen"
Configuration Evaluation	KM 4.4	"Ergebnisse sichern"
Release Management and Delivery	KM 4.6	"Release-Management durchführen"
Quality Assurance Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
	QS 1.2	"Prüfplan erstellen"
Product Assurance	QS 4.1	"Prüfbarkeit feststellen"
	QS 4.2	"Produkt inhaltlich prüfen"
Process Assurance	QS 3	"Prozeßprüfung von Aktivitäten"
Assurance of Quality Systems
Verification Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
	QS 1.2	"Prüfplan erstellen"
	QS 2.2	"Prüfumgebung definieren"
Verification	QS 2.1	"Prüfmethoden und -kriterien festlegen"
	QS 2.3	"Prüffälle festlegen"
	QS 2.4	"Prüfprozedur erstellen"
	QS 3	"Prozeßprüfung von Aktivitäten"
	QS 4.1	"Prüfbarkeit feststellen"
	QS 4.2	"Produkt inhaltlich prüfen"
Validation Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
	QS 1.2	"Prüfplan erstellen"
	QS 2.2	"Prüfumgebung definieren"
Validation	QS 2.1	"Prüfmethoden und -kriterien festlegen"
	QS 2.3	"Prüffälle festlegen"
	QS 2.4	"Prüfprozedur erstellen"
	QS 4.1	"Prüfbarkeit feststellen"
	QS 4.2	"Produkt inhaltlich prüfen"
Joint Review Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
Project Management Review	PM 6	"Durchführungsentscheidung"
Technical Review	PM 6	"Durchführungsentscheidung"
Audit Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 1.1	"QS-Plan erstellen"
Audit	QS 3	"Prozeßprüfung von Aktivitäten"
	QS 4	"Produktprüfung"
Problem Resolution Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	QS 5	"QS-Berichtswesen"
Problem Resolution	QS 5	"QS-Berichtswesen"
	KM 4.7	"Projekthistorie führen"
Tabelle ISO.4:	Zuordnung der Supporting Processes zu Aktivitäten des V-Modells


Organizational Processes
Teil 3	Vorgehensmodell / Handbuchsammlung

ISO	Das V-Modell in einer ISO- und AQAP-Umgebung

ISO.3	Korrespondenz des V-Modells zur ISO 12207

ISO.3.2	Abdeckung der Prozesse der ISO 12207 durch das V-Modell

ISO.3.2.3	Organizational Processes

Die beiden Prozesse Management und Infrastructure sind durch das V-Modell, Submodell PM, abgedeckt.

Ein Improvement-Prozeß als solcher findet sich im V-Modell nicht, jedoch kann der Weg über Prozeßprüfungen und das Hilfsmittel Projekthistorie beschritten werden, wodurch sich Ergebnisse für den Improvement Prozeß ableiten ließen.

Für den Training-Prozeß sind im V-Modell die Schulung/Einarbeitung und Einweisung der Mitarbeiter enthalten.

Management Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Initiation and Scope Definition	PM 1.1	"Projekt einrichten"
	PM 1.2	"Projektkriterien und Entwicklungsstrategie festlegen"
Planning	PM 1.3	"Projektspezifisches V-Modell erstellen"
	PM 1.5	"Grobplan erstellen"
	PM 4	"Feinplanung"
	PM 7	"Risikomanagement"
Execution and Control	PM 5	"Kosten-/Nutzenanalyse"
	PM 8	"Projektkontrolle und -steuerung"
	PM 9	"Informationsdienst/Berichtswesen"
	KM 4.7	"Projekthistorie führen"
	PM 11	"Bereitstellung der Ressourcen"
	PM 12	"Vergabe von Arbeitsaufträgen"
Review and Evaluation	PM 6	"Durchführungsentscheidung"
Closure	PM 14	"Projektabschluß"
Infrastructure Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	PM 1.4	"Toolset-Management durchführen"
	PM 1.5	"Grobplan erstellen"
Establishment of the Infrastructure	PM 4	"Feinplanung"
	PM 11	"Bereitstellung der Ressourcen"
Maintenance of the Infrastructure	PM 8	"Projektkontrolle und -steuerung"
Improvement Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Establishment
Process Assessment	QS 3	"Prozeßprüfung von Aktivitäten"
Process Improvement	KM 4.7	"Projekthistorie führen"
Training Process

Aktivitäten nach ISO 12207	Aktivitäten nach V-Modell
Process Implementation	PM 1.5	"Grobplan erstellen"
	PM 4	"Feinplanung"
Training Material Development
Training Plan Implementation	PM 10	"Schulung/Einarbeitung"
	PM 13	"Einweisung der Mitarbeiter"
Tabelle ISO.5:	Zuordnung der Organizational Processes zu Aktivitäten des V-Modells


Abbildungsverzeichnis AU250/3 - ISO
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - ISO)

A.1	Abbildungsverzeichnis

Abbildung ISO.1:	Zusammenhang der Qualitätsstandards

Abbildung ISO.2:	Beziehungen der Standards und ihrer Ausprägung

Abbildung ISO.3:	Die Prozesse der ISO 12207


Tabellenverzeichnis AU250/3 - ISO
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - ISO)

A.2	Tabellenverzeichnis

Tabelle ISO.1:	Abdeckung der ISO 9001 durch das V-Modell

Tabelle ISO.2:	Entsprechungen des V-Modells zum QS-Plan des AQAP-150

Tabelle ISO.3:	Zuordnung der Primary Processes zu Aktivitäten des V-Modells

−	Acquisition Process

−	Supply Process

−	Development Process (1)

−	Development Process (2)

−	Operation Process

−	Maintenance Process

Tabelle ISO.4:	Zuordnung der Supporting Processes zu Aktivitäten des V-Modells

−	Documentation Process

−	Configuration Management Process

−	Quality Assurance Process

−	Verification Process

−	Validation Process

−	Joint Review Process

−	Audit Process

−	Problem Resolution Process

Tabelle ISO.5:	Zuordnung der Organizational Processes zu Aktivitäten des V-Modells

−	Management Process

−	Infrastructure Process

−	Improvement Process

−	Training Process


Literaturverzeichnis AU250/3 - ISO
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - ISO)

A.3	Literaturverzeichnis

/AQAP-110/	AQAP-110 − NATO-Qualitätssicherungsforderungen für Entwicklung, Konstruktion und Produktion. März 1993.

/AQAP-150/	AQAP-150 − NATO-Qualitätssicherungsforderungen für Software-Entwicklung. März 1993.

/DIN EN ISO 9001/	DIN EN ISO 9001 − Qualitätsmanagementsysteme − Modell zur Darlegung des Qualitätsmanagementsystems in Design/Entwicklung, Produktion, Montage und Kundendienst. Juni 1993.

/ISO IEC 12207/	ISO IEC 12207 − Information Technology − Software Life Cycle Processes. 1995.


Überblick
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.1	Überblick

Nach einer grundsätzlichen Betrachtung der Auswirkungen des Einsatzes objektorientierter Sprachen im V-Modell wird exemplarisch besonders auf die Sprachen Ada 95 und C++ 1) eingegangen. Es wird dargestellt, wie die Arbeits- und Unterstützungshilfen des V-Modells beim Einsatz objektorientierter Sprachen umgesetzt werden sollen. Insbesondere wird gezeigt, wie die Erzeugnisstruktur des V-Modells als Strukturierungshilfe für objektorientierte System- und SW-Entwürfe eingesetzt werden kann.

1)	Ergänzend werden die Sprachen OO-COBOL und FORTRAN 90 berücksichtigt.


Grundsätzliche Sichtweise des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.2	Auswirkung objektorientierter Vorgehensweisen

OOS.2.1	Grundsätzliche Sichtweise des V-Modells

Die Prinzipien, die objektorientierte Vorgehensweisen erlauben, sind bereits im Regelungsteil des V-Modells verankert. 2) Die dabei zum Einsatz kommenden Elementarmethoden sind im Grundsatz sprachunabhängig und können daher in Verbindung mit jeder der nachfolgend behandelten Sprachen eingesetzt werden.

2)	Außerdem wird ein eigenes Szenario zur Darstellung objektorientierter Vorgehensweisen im Handbuch "Szenarien" (ebenfalls in dieser Handbuchsammlung) geschildert, das unabhängig von der eingesetzten Sprache die Auswirkungen des Einsatzes objektorientierter Technologien klärt.

Sowohl die Methodenkonzepte als auch die syntaktischen Strukturierungsmittel der jeweiligen Sprache orientieren sich beim Einsatz des V-Modells an der Erzeugnisstruktur als Gliederungsgerüst. Die Zuordnung der Methoden zu diesem Gerüst dokumentiert die Methodenzuordnung.

Grundsätzlich sind die Elemente der Erzeugnisstruktur Gliederungs- und Verwaltungshilfen für die Elemente des Systems. Sie sind dadurch universell tauglich, daß sie sprachunabhängig genutzt werden können.

Die Regelungen des V-Modells − und insbesondere die Erzeugnisstruktur − sind unabhängig von der eingesetzten Methode und Programmiersprache anwendbar.


Regeln und Kriterien für die praktische Umsetzung
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.2	Auswirkung objektorientierter Vorgehensweisen

OOS.2.2	Regeln und Kriterien für die praktische Umsetzung

Für den Einsatz einer Programmiersprache relevante Elemente der Erzeugnisstruktur sind SW-Einheiten, SW-Komponenten und SW-Module. Unabhängig von der eingesetzten Sprache gilt, daß in keinem Fall eine direkte, vom V-Modell als Standard festgeschriebene Kopplung von Syntaxelementen zur Erzeugnisstruktur erfolgt (z. B. "Jede Klasse ist ein SW-Modul").

Eine starre, schematisierte Zuordnung von Elementen der Erzeugnisstruktur zu Ausdrucksmitteln einer Programmiersprache ist nicht möglich. Wesentliche Faktoren bei der Zuordnung sind z. B. der Grad der Komplexität des Systems und der Abstraktionsgrad der Zerlegungsebene.

Das Ergebnis der Zuordnung wird deshalb eine Skala mit überlappenden Zuordnungen von Strukturen des V-Modells zu Strukturen der Programmiersprache sein.

SW-Einheit

Das V-Modell gibt keine Aufteilung in SW-Einheiten vor. Es kann daher nicht nach einer "korrekten Aufteilung gemäß V-Modell" gefragt werden. Im Sinne des V-Modells ist jede Aufteilung korrekt. Es ist eine Entwurfsaufgabe, die unter Designgesichtspunkten bei den gegebenen Randbedingungen am besten geeignete Architektur zu finden.

Die SW-Einheit ist ein Strukturierungsmittel zur Beschreibung der Architekturentscheidungen im V-Modell. Dabei spielen neben SW-technischen auch organisatorische Gesichtspunkte eine Rolle. So können z. B. SW-Anteile, die einem Team zugeordnet werden, zu einer SW-Einheit zusammengefaßt werden. Auch die Integrationsstrategie (und damit die Prüfplanung) kann Argumente zur Aufteilung von Systemen oder Segmenten in SW-Einheiten liefern.

Es ist nicht gefordert, daß eine SW-Einheit lauffähig im Sinne eines eigenständigen Programms oder Prozesses ist. Eine SW-Einheit wird in jedem Fall als eigenständige Einheit vom KM verwaltet. (KM kann aber auch kleinere Einheiten verwalten.)

Sinnvoll kann z. B. die Gliederung eines Anwendungssystems in drei SW-Einheiten sein, die die Schichten

1.	Präsentationsschicht (Windowsoberfläche, GUI, Behandlung von User-Interrupts usw.),

2.	Anwendungsschicht (meist auf fachliche Anforderungen zurückzuführende SW-Anteile) und

3.	Datenschicht (Dateien, Zugriffsroutinen, Datenablage usw.).

SW-Modul

SW-Module sind gekennzeichnet durch die Umsetzung der typischen Modularisierungskriterien wie Abgeschlossenheit, schwache Kopplung zwischen Modulen (schmale Schnittstellen) und enge interne Bindung zwischen Funktionen.  SW-Module sind von außen als abgeschlossene, testbare und wartbare Einheiten sichtbar. Gutes Moduldesign zeichnet sich auch durch gute Abstraktionsschichten aus: Ein SW-Modul bietet nach außen eine konsistente, verständliche und wartbare Schnittstelle an, die unabhängig von der internen Modulstruktur ist.

Ein typisches SW-Modul ist z. B. eines zur Berechnung von Steuerzuschlägen. Sein Datengeheimnis sind die aktuell gültigen Steuersätze. Seine Algorithmen kapseln die gesetzlich abgesicherten Berechnungsvorgänge inklusive der Rundungsregeln.

SW-Komponente

Komponenten sind i. d. R. Sammlungen von SW-Modulen, die z. B. gemeinsam einen Funktionskreis implementieren. Typische SW-Komponenten sind Bibliotheken (auch die Standardbibliotheken der eingesetzten Software-Entwicklungsumgebung), Mengen zusammengehöriger, wiederverwendbarer SW-Module, Modulmengen, die von mehreren anderen SW-Einheiten benutzt werden, usw.

Eine typische SW-Komponente ist die C- oder Ada-Standardbibliothek.

Im folgenden werden sprachabhängig typische Situationen geschildert und in Form von beispielhaften Lösungsvorschlägen beschrieben.


Die Strukturierungsmittel von Ada 95
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.3	Anwendung von Ada 95

OOS.3.1	Die Strukturierungsmittel von Ada 95

Basis für die Erstellung von Ada-Software ist die Bibliothek. Der Ada-Standard (/DIN ISO/IEC 8652/) schreibt im Detail nicht vor, wie eine Bibliothek auszusehen hat. Grundgedanke des Bibliothekskonzepts bei Ada ist es, daß die Bibliothek übersetzte Programmeinheiten aufnimmt, die Beiträge zu einem späteren lauffähigen System sind. Übersetzen von Programmeinheiten und Binden eines Programms finden immer im Kontext einer Bibliothek statt, wobei Konsistenzprüfungen über die Grenzen von Bibliothekseinheiten hinweg vorgenommen werden. Eine Ada-Implementierung kann die Verknüpfung von mehreren Bibliotheken zu einer Bibliothekshierachie unterstützen. Ada 95 schreibt die Struktur und Funktion einer Programmbibliothek nicht mehr so detailliert vor wie Ada 83.

Ada 95 trägt der Entwicklung Rechnung, daß ein "Programm" nicht mehr zwangsläufig auf einen einzigen Prozessor bzw. auf einen einzigen Adreßraum festgelegt ist. Vielmehr wird unter einem Programm eine Menge von Bausteinen verstanden, die zusammen ein System implementieren und die gleichzeitig auf im allgemeinen mehreren Hardwarekomponenten ablaufen. Diese Bausteine werden bei Ada Partitionen genannt. Im konventionellen Fall ist ein Programm identisch mit einer Partition. Falls ein Programm aus mehreren Partitionen besteht, dann wird von einem verteilten System gesprochen.

Ada 95 führt neu die Unter-Bibliothekseinheit ("child library unit") ein. Die Unter-Bibliothekseinheit ist eine Bibliothekseinheit, die eine Erweiterung einer bereits bestehenden Bibliothekseinheit darstellt. Unter-Bibliothekseinheiten können beliebig tief geschachtelt sein. Die Unter-Bibliothekseinheiten sind als Sprachmittel die entscheidende Voraussetzung, daß in Ada unter Berücksichtigung der Aufwärtskompatibilität von Ada 83 die Konzepte der Objektorientierung ("tagged types", "programming by extension") eingeführt werden können. Eine komplette Hierarchie bestehend aus Bibliotheks-, Unter-Bibliothekseinheiten und Untereinheiten wird Ada-Subsystem genannt. Der Begriff "Ada-Subsystem" deckt somit einen weiten Bereich ab.

Zusätzlich zu den Kontextklauseln von Ada 83 bieten die Unter-Bibliothekseinheiten dem Programmierer wesentlich mehr Möglichkeiten zur Programm-Strukturierung und zur störungsfreien Erweiterung bereits bestehender Systeme.


Abbildung auf die Erzeugnisstruktur
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.3	Anwendung von Ada 95

OOS.3.2	Abbildung auf die Erzeugnisstruktur

SW-Modul

Ein SW-Modul ist die kleinste Software-Einheit, die vom Konfigurationsmanagement identifiziert wird. Dieses Verständnis hat seine Analogie in der Bibliothekseinheit (library unit) bzw. Unter-Bibliothekseinheit (child library unit) bei Ada. Eine (Unter-) Bibliothekseinheit im Sinne der Erzeugnisstruktur ist

−	ein Unterprogramm (Prozedur oder Funktion) und

−	ein Paket (package).

Generische Einheiten dienen dazu, aus einer Programmschablone durch den Vorgang der generischen Ausprägung ausführbare Programmeinheiten zu erzeugen. Eine generische Einheit ist kein Beitrag zu einem laufenden System, deshalb ist eine generische Einheit auch nicht Teil der Erzeugnisstruktur.

Bibliothekseinheiten enthalten als Bausteine Programmeinheiten (program units). Aus programmiertechnischen Gründen ist eine Programmeinheit nicht identisch mit einer Bibliothekseinheit.

Der Sprachstandard kennt des weiteren die Untereinheit (program subunit). Diese dient der besseren Strukturierbarkeit von Programmeinheiten. Eine Untereinheit ist immer auf eine Programmeinheit bezogen und von dieser stark abhängig.

SW-Komponente

Im Sinne des V-Modells ist eine SW-Komponente die Zusammenfassung mehrerer SW-Module zur Lösung einer Teilaufgabe. Dies hat seine Analogie in einer Struktur von zusammengehörigen Ada-Bibliothekseinheiten. Der Zusammenhang wird durch das Ada-Sprachmittel der Kontextklausel ("with"-clause) hergestellt. Eine SW-Komponente ist eine Kollektion von zusammengehörigen Subsystemen, die die Implementierung der SW-Komponente beinhalten. Falls die SW-Komponente ein ausführbares Programm ist, dann ist das Ada-Äquivalent die Partition. Falls es sich um ein nicht-ausführbares System handelt, dann ist das Äquivalent eine Partition oder ein oder mehrere Ada-Subsysteme.

SW-Einheit

Eine SW-Einheit im Sinne des V-Modells ist eine weitgehend selbständige Software-Einheit, die eine definierte Funktion des Systems implementiert. Eine SW-Einheit ist eine Programmeinheit, die separat testbar und in der Regel auch ausführbar ist. Dies deckt sich mit der (in Ada 95 sehr weit gefaßten) Definition des Programms. Ein Ada-Programm ist eine Menge von kommunizierenden Partitionen. Im allgemeinen Fall wird eine SW-Einheit also durch eine oder mehrere Ada-Partitionen realisiert. Diese Definition umfaßt sowohl verteilte Systeme wie Ein-Prozessor-Systeme.


Übersicht
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.3	Anwendung von Ada 95

OOS.3.3	Übersicht

Tabelle OOS.1 zeigt im Überblick die Zuordnung von Ada-Sprachelementen zu den Elementen der Erzeugnisstruktur. Dabei können jeweils mehrere Ausprägungen der Ada-Elemente einer Ausprägung des Elements der Erzeugnisstruktur zugeordnet werden.

Ada-Sprachelement	SW-Einheit	SW-Komponente	SW-Modul
Ada-Program	x
Partition	x	x
Verteiltes System	x
Subsystem	x	x	x
Bibliothekseinheit			x
Unter-Bibliothekseinheit			x
Untereinheit			x
Tabelle OOS.1:	Zuordnung von Ada-Sprachelementen zur Erzeugnisstruktur


Die Strukturierungsmittel von C++
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.4	Anwendung von C++

OOS.4.1	Die Strukturierungsmittel von C++

C++ (/Ellis, Stroustrup/, /ANSI Com. X3J16/) bietet neben den objektorientierten Sprachelementen auch die für prozedurale Sprachen bekannten Elemente. (Da C++ nicht zur Verwendung der objektorientierten Elemente zwingt, spricht man auch von einer "hybriden" objektorientierten Sprache.) Die Abbildung auf die Erzeugnisstruktur des V-Modells beschränkt sich daher nicht nur auf die reinen objektorientierten Sprachmittel, sondern umfaßt auch die prozeduralen Anteile.

Zentrales Strukturierungsmittel in C++ ist die Klasse. Ein objektorientiertes Programm besteht aus einer Menge von Kassendefinitionen, einer Funktion "main" und optional weiteren Funktionen. Die Sprache selbst kennt außer der Verknüpfung von Klassen über Benutzt- oder Vererbt-Beziehungen keine Zusammenfassung von Klassen zu einer Bibliothek. Dies liegt in der Verantwortung der verwendeten Entwicklungsumgebung und wird oft direkt auf das Dateisystem abgebildet. Klassenbibliotheken sind also kein Sprachkonstrukt, sondern eine verwaltungsmäßige Zusammenfassung von Klassen.

Bestimmend für die Strukturierung von C++-Programmsystemen ist der Gedanke der Übersetzungseinheit. (Dies ist eine Folge der Abwärtskompatibilität zu C.) Der Sichtbarkeitsbereich von lokalen Variablen und Funktionen kann auf eine übersetzbare Datei eingeschränkt oder für die Verwendung in Funktionen aus anderen Übersetzungseinheiten nach außen bekannt (exportiert) werden.

Die Abhängigkeiten von Übersetzungseinheiten werden nicht von der Sprache selbst, sondern von zusätzlichen Werkzeugen verwaltet. (Meist werden dazu Werkzeuge wie "make" eingesetzt.)


Abbildung auf die Erzeugnisstruktur
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.4	Anwendung von C++

OOS.4.2	Abbildung auf die Erzeugnisstruktur

SW-Einheit

Eine ausgewählte SW-Einheit ist in C++ diejenige, die die main-Funktion enthält. Jedes Anwendungssystem muß eine solche Funktion beinhalten. Diese SW-Einheit ist in dem Sinne lauffähig, daß sie − bei entsprechender Absättigung der statischen Referenzen auf andere SW-Anteile − nach dem Übersetzungs- und Bindevorgang geladen und gestartet werden kann.

Eine solche SW-Einheit enthält üblicherweise

−	Funktionen (die ausgewählte Funktion "main", gewöhnliche Funktionen, friend-Funktionen, Operator-Funktionen),

−	Daten (const und static Datenelemente) und

−	Klassen (bestehend aus Daten und Funktionen; eigenständige Klassen oder durch Vererbungsbeziehungen verbundene),

die nur für diese eine SW-Einheit gebraucht werden. (Elemente, die auch von anderen SW-Einheiten verwendet werden, werden sinnvollerweise in eigene, wiederverwendbare SW-Einheiten oder SW-Komponenten integriert.)

Beim Einsatz einer Schichtenarchitektur können von dieser SW-Einheit die Dienste einer oder mehrerer darunterliegenden SW-Einheiten genutzt werden. Für solche SW-Einheiten ergeben sich mit Ausnahme der Ausführungen zur Funktion "main" dieselben Vorgaben.

Eine SW-Einheit besteht im allgemeinen aus mehreren SW-Modulen und damit aus mehreren Dateien (s. u.). Das KID einer SW-Einheit enthält die Identifikatoren ihrer SW-Module.

SW-Modul

Innerhalb einer SW-Einheit wird nach den üblichen Modularisierungskriterien (Abgeschlossenheit, Änderbarkeit, geringe Kopplung, usw.) weiter strukturiert. Es entstehen SW-Module, die üblicherweise folgende Bestandteile enthalten:

−	Klassen (eigenständige oder durch Vererbungsbeziehungen verbundene),

−	Funktionen (Funktionen, friend-Funktionen, Operator-Funktionen),

−	Daten (const und static Datenelemente).

Zu jedem SW-Modul sollte es eine Spezifikationsdatei (nach Konvention eine Datei mit der Endung ".h" 3)) geben, die die Außenschnittstelle bekannt gibt. Die Implementierungsdatei (Endung ".cxx", ".cpp" o. ä.) enthält die Umsetzung der Spezifikation mittels C++-Syntax (sie ist die eigentliche Quelldatei).

3)	Diese "h-Dateien" werden durch eine #include-Anweisung importiert.

Es wird nicht vorgegeben, wie viele Klassen und Funktionen ein SW-Modul enthalten soll. Sinnvollerweise sollte ein SW-Modul jedoch an seiner Schnittstelle (h-Datei) möglich wenige Klassen einführen (möglichst schmale Schnittstelle). (Ob die Publikation einer Klasse pro SW-Modul eine Ideallösung darstellt, ist abhängig von der Anwendung.)

Nebeneinanderliegende SW-Module können einander nutzen (aufrufen), ohne daß dafür eine Schichtenbildung über SW-Komponenten (s. u.) erfolgen muß.

SW-Komponenten

SW-Komponenten fassen üblicherweise SW-Module zusammen, die von mehreren SW-Einheiten verwendet werden oder generell zur Wiederverwendung zur Verfügung gestellt werden. Aus Gründen der effizienten Strukturierung von SW-Einheiten können auch SW-Module innerhalb einer SW-Einheit zu SW-Komponenten zusammengefaßt werden. Dies gilt sinngemäß auch für geschachtelte SW-Komponenten.


Übersicht
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.4	Anwendung von C++

OOS.4.3	Übersicht

Tabelle OOS.2 zeigt im Überblick die Zuordnung von C++-Sprachelementen zu den Elementen der Erzeugnisstruktur. Eine SW-Einheit oder ein SW-Modul kann dabei mehrere Elemente der zugeordneten C++-Sprachelemente enthalten.

C++-Sprachelement	SW-Einheit	SW-Komponente	SW-Modul
Funktion	x		x
Datenelement	x		x
Klasse	x		x
(Klassen-) Bibliothek		x
Tabelle OOS.2:	Zuordnung von C++-Sprachelementen zur Erzeugnisstruktur


Anwendung anderer objektorientierter oder objektbasierter Sprachen
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.5	Anwendung anderer objektorientierter oder objektbasierter Sprachen

Für andere klassische Programmiersprachen wie COBOL und FORTRAN existieren inzwischen objektorientierte (oder objektbasierte) Erweiterungen 4), die sich aufgrund der historischen Entwicklung an Smalltalk, C++ oder Ada 95 orientieren. Für diese Sprachen gelten die oben aufgeführten Regeln und Anleitungen daher analog. Im folgenden werden daher nur die Zuordnungen zu den Sprachelementen in der Form einer Übersicht präzisiert.

4)	objektorientiert = objektbasiert + Vererbung; objektbasiert = modular + Abstraktion + Instantiierung


Übersicht der Sprachzuordnung für OO-COBOL
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.5	Anwendung anderer objektorientierter oder objektbasierter Sprachen

OOS.5.1	Übersicht der Sprachzuordnung für OO-COBOL

Tabelle OOS.3 zeigt im Überblick die Zuordnung von OO-COBOL-Sprachelementen (/ANSI Com. X3J4/) zu den Elementen der Erzeugnisstruktur. Eine SW-Einheit oder ein SW-Modul kann dabei mehrere Elemente der zugeordneten COBOL-Sprachelemente enthalten.

Die Ausführungen zu Übersetzungseinheiten und zur Einbindung von Klassenbibliotheken in die Sprache sind wie für C++ gültig. Ebenso wie für C++ existiert derzeit ein ANSI-Draft-Standard für OO-COBOL.

OO-COBOL-Sprachelement	SW-Einheit	SW-Komponente	SW-Modul
Program	x		x
Subprogram	x		x
Klasse (syntaktisch "program")			x
(Klassen-) Bibliothek		x	x
Tabelle OOS.3:	Zuordnung von OO-COBOL-Sprachelementen zur Erzeugnisstruktur


Übersicht der Sprachzuordnung für FORTRAN 90
Teil 3	Vorgehensmodell / Handbuchsammlung

OOS	Berücksichtigung objektorientierter Sprachen

OOS.5	Anwendung anderer objektorientierter oder objektbasierter Sprachen

OOS.5.2	Übersicht der Sprachzuordnung für FORTRAN 90

Tabelle OOS.4 zeigt im Überblick die Zuordnung von OO-FORTRAN-Sprachelementen (/ANSI X3.198/) zu den Elementen der Erzeugnisstruktur. Dabei können jeweils mehrere Ausprägungen der OO-FORTRAN-Elemente einer Ausprägung des Elements der Erzeugnisstruktur zugeordnet werden.

FORTRAN 90 ist keine objektorientierte, sondern lediglich eine objektbasierte Sprache, da die Konzepte der Vererbung und in der Folge des Polymorphismus nicht unterstützt werden. Von der Sprachphilosophie läßt sich FORTRAN 90 in etwa mit dem Stand von Ada 83 vergleichen. Zur Diskussion der Strukturierungsmittel und der Abbildung auf die Erzeugnisstruktur wird deshalb auch auf Obengesagtes zu Ada verwiesen.

Nachstehend werden die Sprachelemente von FORTRAN 90 der Erzeugnisstruktur des V-Modells zugeordnet:

FORTRAN-Sprachelement	SW-Einheit	SW-Komponente	SW-Modul
Program	x		x
Subroutine/Function	x		x
Benutzerdefinierte Datentypen	x		x
Bibliotheken		x
Tabelle OOS.4: Zuordnung von FORTRAN-Sprachelementen zur Erzeugnisstruktur


Tabellenverzeichnis AU250/3 - OOS
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - OOS)

A.1	Tabellenverzeichnis

Tabelle OOS.1:	Zuordnung von Ada-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.2:	Zuordnung von C++-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.3:	Zuordnung von OO-COBOL-Sprachelementen zur Erzeugnisstruktur

Tabelle OOS.4:	Zuordnung von FORTRAN-Sprachelementen zur Erzeugnisstruktur


Literaturverzeichnis AU250/3 - OOS
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - OOS)

A.2	Literaturverzeichnis

/DIN ISO/IEC 8652/	DIN ISO/IEC 8652 − Ada 95 Reference Manual. September 1996.

/Ellis, Stroustrup/	Margaret A. Ellis, Bjarne Stroustrup: The Annotated C++ Reference Manual; Addison-Wesley 1990.

/ANSI Com. X3J16/	ANSI Committee X3J16: C++ Draft Standard.

/ANSI Com. X3J4/	ANSI Committee X3J4: OO-COBOL Draft Standard.

/ANSI X3.198/	ANSI X3.198 − 1992: FORTRAN.


Allgemeines
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.1	Allgemeines

Die Zuordnung von Aufgaben (Aktivitäten) zu Personen wird im V-Modell über Rollen vorgenommen. Dabei beschreiben Rollen geforderte Kenntnisse und Fähigkeiten, die ein Rolleninhaber für die Erfüllung der ihm zugeordneten Aufgaben besitzen muß. Das V-Modell bleibt dadurch grundsätzlich organisationsneutral. Für die Projektabwicklung bedeutet dies, daß mit der Einrichtung eines Projekts (Aktivität PM 1 "Projektinitialisierung") die Rollen des V-Modells einzelnen Personen zugeordnet werden müssen. Personen haben innerhalb von Behörden und Firmen Stellen als die kleinsten Organisationseinheiten inne.

Die Zuordnung von Personen zu Rollen hat damit zusätzlich die Organisationsstruktur und den Organisationsablauf zu berücksichtigen. Rollen identifizieren Tätigkeiten, die gegebenenfalls nur einen Teil, gegebenenfalls aber auch das Mehrfache der Arbeitszeit eines Mitarbeiters beanspruchen. Deshalb kann ein Mitarbeiter durchaus mehrere Rollen innehaben bzw. eine Rolle von mehreren Mitarbeitern wahrgenommen werden.

Wichtig bei dieser Zuordnung ist, daß die Rolleninhalte nicht in einem Interessenkonflikt zueinander liegen und damit für die jeweilige Person zu einem unlösbaren Problem werden können (wie z. B. bei konstruktiven SE-Rollen einerseits und den Prüfern andererseits). So darf beispielsweise die Rolle des Projektleiters nicht mit der Rolle des QS-Verantwortlichen in einer Person vereint werden, da der Projektleiter schwerpunktmäßig für Zeit und Budget, der QS-Verantwortliche hingegen für die Qualität verantwortlich ist. Die Rolle des QS-Verantwortlichen ist beispielsweise mit der Rolle des KM-Verantwortlichen verträglich.

Kriterien für die Zuordnung sind dabei Interessenskonfliktfreiheit, Verantwortlichkeitsstrukturen und Erfahrungen, Kenntnisse, Eignung, Verfügbarkeit (Auslastung) der Projektmitarbeiter.

Es können Rollen im Projekt wegfallen, wenn ihnen durch den Projektzuschnitt (Tailoring) keine Aktivitäten mehr zugeordnet sind. Bei kleinen Projekten müssen zwangsläufig mehrere Rollen durch eine Person abgedeckt werden. Bei großen Projekten wird i. d. R. jede Rolle durch verschiedene Personen wahrgenommen.

Einige Rollen, die für das Projekt relevant sind, können auch über die Dauer des Projektes an eine Organisationseinheit gebunden sein. Dies ist vor allem dann sinnvoll, wenn die Aufgabeninhalte der Rollen sehr anspruchsvoll sind, und über eine kontinuierliche Beschäftigung mit einer Materie ein ständiger Know-how-Zuwachs erwartet werden kann. Sie decken darüber hinaus Aufgaben ab, die Querschnittscharakter haben und Voraussetzung und Grundlage für alle Projekte sind. Sie sind insofern von einzelnen Projekten unabhängig, weil ihre Dienste von allen Projekten in Anspruch genommen werden. Beispiele hierfür sind PM-Manager, Q-Manager, KM-Manager und IT-Beauftragter. Eine beispielhafte Zuordnung von Rollen zu Personen/Organisationseinheiten innerhalb einer Aufbauorganisation befindet sich in der Handbuchsammlung.

Das V-Modell geht von einer beauftragten Systementwicklung bzw. -pflege und -änderung aus. Der Auftraggeber ist in der Regel eine Organisationseinheit, die die Systementwicklung an eine andere Organisationseinheit entweder außerhalb oder innerhalb der Behörde/Firma vergibt. Mit der Betrachtung des AG- und AN-Bezug ergibt sich nicht zwangsweise die Duplizierung der V-Modell-Rollen (RollenAG und RollenAN). Zusätzliche Kommunikations- und Koordinationsaufgaben sind zu bestimmen, die i. a. zur Einrichtung weiterer Abstimmungs- und Lenkungsgremien führen.


Die Rollen im V-Modell
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

Die Rollen sind nach den Submodellen geordnet: In jedem Submodell gibt es

−	einen Manager, der die Rahmenbedingungen für die Aktivitäten des Submodells festlegt und als oberste Entscheidungsinstanz fungiert,

−	einen Verantwortlichen, der die Aufgaben des Submodells plant, steuert und kontrolliert,

−	einen bzw. mehrere Durchführende, die die geplanten Aufgaben des Submodells bearbeiten.

Tabelle R.1 stellt die Rollen des V-Modells im Überblick dar.

	Manager	Verantwortliche	Durchführende
Submodell PM	Projektmanager	Projektleiter Rechtsverantwortlicher Controller	Projektadministrator
Submodell QS	Q-Manager	QS-Verantwortlicher	Prüfer
Submodell KM	KM-Manager	KM-Verantwortlicher	KM-Administrator
Submodell SE	Projektmanager IT-Beauftragter Anwender	Projektleiter	Systemanalytiker Systemdesigner SW-Entwickler HW-Entwickler Technischer Autor SEU-Betreuer Datenadministrator IT-Sicherheitsbeauftragter Datenschutzbeauftragter Systembetreuer
Tabelle R.1:	Rollen im V-Modell

Für die Beschreibung der Rollen wird nachstehendes Beschreibungsschema verwendet:

−	Rollenname, Zugehörigkeit zum Submodell

−	Aufgaben

−	Geforderte Kenntnisse und Fähigkeiten


Projektmanager, PM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.1	Projektmanager, PM

Aufgaben:

−	Festlegung der Rahmenbedingungen für die Projektorganisation

−	Initialisierung und Koordination des Projekts, gegebenenfalls Koordination mehrerer Projekte

−	Initialisierung und Mitgestaltung der Vergabe

−	Kontrolle und Einhaltung der vertraglichen Abmachungen

−	Kommunikation mit dem AN

−	Beauftragung der Kosten-Nutzenanalyse und ihre Bewertung

−	Problem- und Konfliktlösung bei der Projektplanung, bei der Projektabwicklung und beim Projektabschluß

−	Kooperation mit dem QS- und KM-Manager

−	Mitarbeit bei Durchführungsentscheidungen und Umsetzung der getroffenen Entscheidungen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis auf betriebswirtschaftlichem Gebiet, aber auch technisches Verständnis

−	Erfahrung in der Projektorganisation

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Führungsqualitäten

−	Fähigkeit zu Organisation und Delegation

−	Fähigkeit zu positiver Sichtweise


Projektleiter, PM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.2	Projektleiter, PM

Aufgaben:

−	Planung, Steuerung und Kontrolle des Projekts

−	Erstellung des Projekthandbuchs und -plans (Aufwand, Termine und Einsatzmittel) basierend auf den Projektzielen und den organisatorischen Rahmenbedingungen

−	Vorbereitung und Durchführung von Ausschreibungen

−	Überwachung der Vertragserfüllung

−	Durchführung von Kosten-Nutzenanalysen

−	Vorbereitung und Begleitung von Durchführungsentscheidungen

−	Erkennung möglicher Risiken im Projekt und Einleitung geeigneter Maßnahmen

−	Beauftragung der Projektmitarbeiter

−	Berichterstattung gegenüber dem Projektmanager und gegebenenfalls weiteren Lenkungsgremien.

Geforderte Kenntnisse und Fähigkeiten:

−	Erfahrung in der Projektabwicklung

−	Verständnis von betriebswirtschaftlichen Zusammenhängen

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Kenntnis über die Entwicklungsumgebung

−	Kenntnis über Methoden und Werkzeuge

−	Durchsetzungsvermögen und Akzeptanz bei den Projektmitarbeitern

−	Fähigkeit zur Führung, Motivation und Moderation

−	Fähigkeit zu Organisation und Kommunikation


Rechtsverantwortlicher, PM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.3	Rechtsverantwortlicher, PM

Aufgaben:

−	Betreuung des Projektmanagers und Projektleiters in juristischen Angelegenheiten

−	Mitwirkung bei der Vergabe von Aufträgen

−	Führung von Vertragsverhandlungen bis hin zum Vertragsabschluß

−	Überwachung der Vertragserfüllung

Geforderte Kenntnisse und Fähigkeiten:

−	Juristische Kenntnis in der Vergabe und Haftung

−	Verhandlungsgeschick


Projektadministrator, PM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.4	Projektadministrator, PM

Aufgaben:

−	Unterstützung des Projektleiters

−	Koordination und Verwaltung von Arbeitsaufträgen

−	Erstellung und Verwaltung von Berichtsdokumenten

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis und Erfahrung in Methoden und Werkzeugen des Projektmanagements

−	Fähigkeit zu Organisation und Kommunikation


Controller, PM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.5	Controller, PM

Aufgaben:

−	Kontrolle der Projektabwicklung

−	Termin- und Kostenverfolgung

−	Entwicklung von Handlungsalternativen für das Projekt

−	Aufbereitung der Projektdaten

Geforderte Kenntnisse und Fähigkeiten:

−	Betriebswirtschaftliche Kenntnisse

−	Ausgeprägtes, wirtschaftliches Bewußtsein für Kosten und Risiken

−	Fähigkeit zu selbständiger Arbeit


Q-Manager, QS
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.6	Q-Manager, QS

Aufgaben:

−	Festlegung der Rahmenbedingungen/Regelungen für die Organisation der QS-Maßnahmen

−	Koordination der QS-Maßnahmen des Projekts, gegebenenfalls Koordination mehrerer Projekte

−	Festlegung geeigneter Qualitätsmerkmale und deren Gewichtung für die Erstellung von Software und Dokumentationen

−	Festlegen der konstruktiven und analytischen QS-Maßnahmen

−	Erstellung und Pflege von Standardchecklisten

−	Beratung der Mitarbeiter bei der Umsetzung der geltenden QS-Regelungen

−	Mitarbeit bei der Festlegung der projektspezifischen QS-Maßnahmen

−	Problem- und Konfliktlösung bei der Projektplanung, bei der Projektabwicklung und beim Projektabschluß aus Sicht der Qualitätssicherung

−	Kooperation mit dem PM- und KM-Manager

−	Mitarbeit bei Durchführungsentscheidungen

Geforderte Kenntnisse und Fähigkeiten:

−	Erfahrung in der Projektorganisation

−	Kenntnis über Anwendung, Realisierung und Einsatz des Systems

−	Führungsqualitäten

−	Fähigkeit zu Organisation und Delegation

−	Fähigkeit zu positiver Sichtweise


QS-Verantwortlicher, QS
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.7	QS-Verantwortlicher, QS

Aufgaben:

−	Planung, Steuerung und Kontrolle der QS-Maßnahmen des Projekts

−	Erstellung von QS-Plan, Prüfplan und Prüfspezifikationen

−	Beauftragung der Prüfer

−	Berichterstattung gegenüber dem Q-Manager

Geforderte Kenntnisse und Fähigkeiten:

−	Erfahrung in der Projektabwicklung

−	Kenntnis über Prüfmethoden und -werkzeuge

−	Durchsetzungsvermögen und Akzeptanz bei der Projektgruppe

−	Fähigkeit, Schwachstellen und Risiken zu identifizieren

−	Fähigkeit zu objektiver und konstruktiver Beurteilung

−	Fähigkeit zu Organisation und Kommunikation


Prüfer, QS
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.8	Prüfer, QS

Aufgaben:

−	Durchführung von QS-Maßnahmen

−	Bewertung eines Prüfgegenstands anhand der vorgegebenen Prüfspezifikation

−	Erstellung von Prüfprotokollen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Methoden und Werkzeuge

−	Kenntnis über Anwendung, Realisierung und Einsatz des Systems

−	Fähigkeit, Schwachstellen und Risiken zu identifizieren

−	Fähigkeit zu objektiver und konstruktiver Beurteilung


KM-Manager, KM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.9	KM-Manager, KM

Aufgaben:

−	Festlegung der Rahmenbedingungen/Regelungen für die Konfigurations- und Produktverwaltung (einheitliche Identifizierungssystematik)

−	Koordination der KM-Maßnahmen des Projekts, gegebenenfalls Koordination mehrerer Projekte

−	Mitarbeit bei der Festlegung der projektspezifischen KM-Maßnahmen

−	Problem- und Konfliktlösung bei der Projektplanung, bei der Projektabwicklung und beim Projektabschluß aus Sicht des Konfigurationsmanagements

−	Kooperation mit dem Projektmanager und Q-Manager

−	Mitarbeit bei Durchführungsentscheidungen

Geforderte Kenntnisse und Fähigkeiten:

−	Erfahrung in der Projektorganisation

−	Kenntnis über Anwendung, Realisierung und Einsatz des Systems

−	Führungsqualitäten

−	Fähigkeit zu Organisation und Delegation

−	Fähigkeit zu positiver Sichtweise


KM-Verantwortlicher, KM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.10	KM-Verantwortlicher, KM

Aufgaben:

−	Planung, Steuerung und Kontrolle der KM-Maßnahmen, insbesondere des Änderungsmanagements

−	Erstellung des KM-Plans

−	Beauftragung des KM-Administrators

−	Berichterstattung an den KM-Manager und den Projektleiter

Geforderte Kenntnisse und Fähigkeiten:

−	Erfahrung in der Projektabwicklung

−	Kenntnis über Methoden und Werkzeuge des Konfigurationsmanagements

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Kenntnis über Versionsvielfalt des Systems

−	Fähigkeit zu Organisation und Kommunikation


KM-Administrator, KM
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.11	KM-Administrator, KM

Aufgaben:

−	Archivierung der während der Projektabwicklung erstellten Produkte

−	Erstellung und Fortschreibung des Konfigurationsidentifikationsdokuments

−	Einrichtung und Betreibung der Projektbibliothek

−	Verwaltung der Zugriffsberechtigungen

−	Entgegennahme und Verwaltung von Änderungsanträgen

−	Unterstützung der Wiederverwendbarkeit von Produkten

−	Kontrolle und Koordination von Schnittstellenänderungen

−	Sicherung der Daten

−	Erstellung von KM-Berichten

−	Zusammenstellung und Auslieferung von Produkten

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Methoden und Werkzeuge des Konfigurationsmanagements

−	Fähigkeit zur Kommunikation


Systemanalytiker, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.12	Systemanalytiker, SE

Aufgaben:

−	Durchführung der Ist-Aufnahme/-Analyse

−	Modellierung des Systems aus fachlicher Sicht (Funktionen und Daten)

−	Definition der Qualitätsanforderungen an das System

−	Mitwirkung bei der Erarbeitung der Architektur des Systems

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Fähigkeit zu abstrahieren und zu vereinfachen

−	Fähigkeit, Abhängigkeiten zu erkennen

−	Erfahrung in der Bewertung von Architekturen

−	Kommunikationsfähigkeit mit Auftraggeber, Anwender und Systemdesigner


Systemdesigner, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.13	Systemdesigner, SE

Aufgaben:

−	Entwicklung der Architektur des Systems

−	Definition der technischen Anforderungen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Kenntnis über die Schnittstellen des Systems

−	Kenntnis über Standardsoftware

−	Kenntnis über Methoden und Werkzeuge

−	Fähigkeit, Schwachstellen und Risiken zu erkennen

−	Fähigkeit, Probleme unter adäquater Berücksichtigung der SW/HW zu analysieren und entsprechende Lösungsvorschläge auszuarbeiten

−	Fähigkeit zu abstrahieren und zu vereinfachen

−	Fähigkeit, Abhängigkeiten zu erkennen


SW-Entwickler, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.14	SW-Entwickler, SE

Aufgaben:

−	Festlegung der SW-Architektur

−	Realisierung der Module/Datenbanken

−	Integration der Module/Datenbanken zu SW-Einheiten

−	Einbindung der SW-Einheiten ins System

−	Durchführung von Selbstprüfungen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis der Entwicklungsumgebung

−	Kenntnis der Standardsoftware und der Programmiersprache, der Datendefinitionssprache und der Datenmanipulationssprache

−	Kenntnis der SW/HW-Schnittstellen

−	Fähigkeit zur strukturierten Programmierung

−	Fähigkeit, Abhängigkeiten zu erkennen

−	Kommunikationsfähigkeit mit HW-Entwicklern sowie Anwendern


HW-Entwickler, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.15	HW-Entwickler, SE

Aufgaben:

−	Festlegung der HW-Architektur

−	Realisierung der HW-Komponenten

−	Integration der HW-Komponenten zu HW-Einheiten

−	Durchführung von Selbstprüfungen

−	Einbindung der HW-Einheiten ins System

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis der Entwicklungsumgebung

−	Kenntnis über die HW und mögliche Alternativen

−	Kenntnis der SW/HW-Schnittstellen

−	Kommunikationsfähigkeit mit SW-Entwicklern sowie Anwendern


Technischer Autor, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.16	Technischer Autor, SE

Aufgaben:

−	Sammlung der technischen Informationen aus der Software- oder Hardware-Entwicklung, die für die spätere Nutzung und den Betrieb erforderlich sind

−	Aufbereitung der gesammelten Information für verschiedene Zielgruppen

−	Erstellung der Betriebsinformationen (Anwender- und Betriebshandbuch) für Anwender und Systembetreuer

−	Mitarbeit bei der Erstellung von Schulungsunterlagen

Geforderte Kenntnisse und Fähigkeiten:

−	Technisches Verständnis

−	Ausdrucksfähigkeit in Text und Grafik

−	Fähigkeit, essentielle Aussagen zu filtrieren


IT-Beauftragter, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.17	IT-Beauftragter, SE

Aufgaben:

−	Festlegung der IT-Standardisierung, d. h. Evaluierung, Auswahl, Festlegung und Einhaltung der anwender- und entwicklungsorientierten IT-Standards

−	Unterstützung bei der Auswahl von Methoden und Werkzeugen

−	Mitarbeit bei der Auswahl von Fertigprodukten

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über das System und die IT-Infrastruktur

−	Kenntnis über Standardsoftware

−	Kommunikationsfähigkeit mit Systemanalytiker, Systemdesigner und SEU-Betreuer


SEU-Betreuer, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.18	SEU-Betreuer, SE

Aufgaben:

−	Auswahl der Systementwicklungs-, Prüf- und Produktionsumgebung

−	Sicherstellung und Aufrechterhaltung der Umgebung für die Softwareentwicklung als auch für den Softwareeinsatz

−	Erarbeitung von Vorgaben für die Netzkonfiguration

−	Steuerung und Überwachung der Zugriffsrechte

−	Freigabe der Software im Netz

−	Betriebsüberwachung von Programmen und vom Netzwerk

−	Fehleranalyse und Behebung/Veranlassung

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Methoden und Werkzeuge für die Systementwicklungsumgebung

−	Kenntnis über unterschiedliche SW/HW

−	Kommunikationsfähigkeit mit Entwickler und Systembetreuer


Datenadministrator, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.19	Datenadministrator, SE

Aufgaben:

−	Erstellung, Verwaltung und Pflege des Datenmodells

−	Abstimmung des Datenmodells mit anderen Projekten

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Methoden und Werkzeuge zur Datenmodellierung

−	Kommunikationsfähigkeit mit Systemanalytiker, Systemdesigner und Anwender


Datenschutzbeauftragter, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.20	Datenschutzbeauftragter, SE

Aufgaben:

−	Festlegung, Bekanntmachung und Einhaltung von Datenschutzrichtlinien

−	Festlegung der Geheimhaltungsgrade (Schutzstufen) und der Schutzbedürftigkeit von Informationen

−	Bestimmung der Regelungen zum Umgang (Erfassung, Weitergabe und Verarbeitung) mit eingestuftem Material

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über das System

−	Fähigkeit, Datenschutzverletzungen zu erkennen und zu bewerten

−	Kenntnis über organisatorische und technische Schutzmöglichkeiten


IT-Sicherheitsbeauftragter, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.21	IT-Sicherheitsbeauftragter, SE

Aufgaben:

−	Erstellung, Pflege und Einhaltung des IT-Sicherheitskonzepts

−	Durchführung von Risiko- und Bedrohungsanalysen

−	Mitwirkung bei der Erstellung von Sicherheitsanforderungen (Zutrittssicherung, Handhaben von Datenträgern, usw.)

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über das System

−	Fähigkeit, Bedrohungen und Risiken zu erkennen und zu bewerten

−	Kenntnis über organisatorische und technische Schutzmöglichkeiten


Anwender, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.22	Anwender, SE

Aufgaben:

−	Beteiligung bei der Erstellung der fachlichen Anforderungen

−	Identifikation der DV-technisch zu realisierenden Funktionen

−	Festlegung der organisatorischen Regelungen für die Nutzung des Systems

−	Mitarbeit bei Prüfungen und Abnahmen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Anwendung und Einsatzgebiete des Systems

−	Kommunikationsfähigkeit mit dem Systemanalytiker, Systemdesigner und Systembetreuer


Systembetreuer, SE
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.2	Die Rollen im V-Modell

R.2.23	Systembetreuer, SE

Aufgaben:

−	Installation und Betreuung des entwickelten Systems

−	Ermittlung des Schulungsbedarfs

−	Mitarbeit bei der Erstellung von Schulungsunterlagen

−	Koordination und Durchführung von Schulungsmaßnahmen bei der Systemeinführung

−	Hilfestellung bei Problemen des Anwenders

−	Koordination der Änderungsanträge/Problemmeldungen

Geforderte Kenntnisse und Fähigkeiten:

−	Kenntnis über Maßnahmen der Entwicklung, Integration und Installation

−	umfassende Kenntnis über die Anwendung des Systems

−	Fähigkeit, auf bestehenden Konzepten aufzubauen und sich in fremde Denkweisen einzuarbeiten

−	Fähigkeit zur konstruktiven Kritik

−	Kommunikationsfähigkeit mit Entwicklern und Anwendern

−	Schulungserfahrung, pädagogische Fähigkeiten


Rollen/Aktivitäten-Zuordnung
Teil 3	Vorgehensmodell / Handbuchsammlung

R	Rollenkonzept im V-Modell

R.3	Rollen/Aktivitäten-Zuordnung

Die Zuordnung von Rollen zu Aktivitäten wird für jedes Submodell des V-Modells durch eine Matrix beschrieben. Dabei können einer Aktivität mehrere Rollen zugeordnet sein. Die Einträge in einer Matrix zeigen an, ob die einer Aktivität zugeordnete Rolle

−	verantwortlich (v),

−	mitwirkend (m) oder

−	beratend (b)

tätig ist.

Diesen Beteiligungsarten liegt das in Tabelle R.2 dargestellte Verständnis zugrunde.

Beteiligungsarten	Elementare Aufgaben
verantwortlich	− Verantwortlich für die Durchführung  − Koordination der beteiligten Rollen
mitwirkend	− Beteiligung an der Erstellung von Produkten  − Beteiligung an der Festlegung der Produktinhalte  − Beteiligung an Abstimmungen
beratend	− Einbringung von Kenntnissen und Erfahrungen
Tabelle R.2:	Beteiligungsarten

Die folgenden Tabellen beschreiben die Rollen/Aktivitäten-Zuordnung bzgl. PM, QS, KM und SE:

−	Aktivitäten/Rollen-Matrix für PM (Tabelle R.3)

−	Aktivitäten/Rollen-Matrix für QS (Tabelle R.4)

−	Aktivitäten/Rollen-Matrix für KM (Tabelle R.5)

−	Aktivitäten/Rollen-Matrix für SE (Tabelle R.6)

Rolle   ⇒                  ⇓   Aktivität
PM 1.1 Projekt einrichten	b	v	m			b		b
PM 1.2 Projektkriterien und Entwicklungsstrategie  festlegen		v	m				b			b
PM 1.3 Projektspezifisches V-Modell erstellen		v	m				m
PM 1.4 Toolset-Management durchführen		v	m						m	b
PM 1.5 Grobplan erstellen		v	m
PM 2 Vergabe/Beschaffung	b	v	m	m
PM 3 Auftragnehmer-Management		v
PM 4 Feinplanung		v	m
PM 5 Kosten-/Nutzenanalyse		v	m		m
PM 6 Durchführungsentscheidung	m	v		m	b	m	m	m
PM 7 Risikomanagement		v	m
PM 8 Projektkontrolle und -steuerung		v	m		m
PM 9 Informationsdienst/Berichtswesen		v	m
PM 10 Schulung/Einarbeitung		v	m
PM 11 Bereitstellung der Ressourcen			v
PM 12 Vergabe von Arbeitsaufträgen		v	m						m
PM 13 Einweisung der Mitarbeiter		v	m
PM 14 Projektabschluß		v	m
Tabelle R.3:	Aktivitäten/Rollen-Matrix für PM

Rolle   ⇒                  ⇓   Aktivität
QS 1.1 QS-Plan erstellen	b	v		m
QS 1.2 Prüfplan erstellen	b	v		m
QS 2.1 Prüfmethoden und -kriterien festlegen		v
QS 2.2 Prüfumgebung definieren		v
QS 2.3 Prüffälle festlegen		v
QS 2.4 Prüfprozedur erstellen		v
QS 3 Prozeßprüfung von Aktivitäten		v	m
QS 4.1 Prüfbarkeit feststellen		m	v
QS 4.2 Produkt inhaltlich prüfen			v
QS 5 QS-Berichtswesen		v
Tabelle R.4:	Aktivitäten/Rollen-Matrix für QS

Rolle   ⇒                  ⇓   Aktivität
KM 1.1 KM-Plan erstellen	b	v			m
KM 1.2 KM einrichten		b	v
KM 2.1 Produkt initialisieren			v
KM 2.2 Konfiguration initialisieren			v
KM 2.3 Produkt verwalten			v			m
KM 2.4 Konfiguration fortschreiben			v
KM 2.5 Zugriffsrechte verwalten			v
KM 3.1 Änderung bewerten		m	m		v
KM 3.2 Änderungsvorgehen entscheiden und  Änderung einleiten		m	m		v
KM 3.3 Änderung abschließen		v	m
KM 4.1 Daten administrieren				v
KM 4.2 SW-/HW-Produkte katalogisieren			v
KM 4.3 Schnittstellen koordinieren		v	m
KM 4.4 Ergebnisse sichern			v
KM 4.5 KM-Dokumentation führen			v
KM 4.6 Release-Management durchführen		v	m		m	m
KM 4.7 Projekthistorie führen		v
Tabelle R.5:	Aktivitäten/Rollen-Matrix für KM

Rolle   ⇒                  ⇓   Aktivität
SE 1.1 Ist-Aufnahme/-Analyse durchführen	v	b										m
SE 1.2 Anwendungssystem beschreiben	v											m
SE 1.3 Kritikalität und Anforderungen an die Qualität definieren	v											m
SE 1.4 Randbedingungen definieren	v											m
SE 1.5 System fachlich strukturieren	v				m	m		m	b	m	m	m
SE 1.6 Bedrohung und Risiko analysieren										v
SE 1.7 Forderungscontrolling durchführen	m	m										v	m
SE 1.8 Software-Pflege- und Änderungs Konzept erstellen		v										m	m
SE 2.1 System technisch entwerfen		v			m						m		m
SE 2.2 Wirksamkeitsanalyse durchführen										v
SE 2.3 Realisierbarkeit untersuchen	m	v								m	m		m
SE 2.4 Anwenderforderungen zuordnen		v
SE 2.5 Schnittstellen beschreiben		v
SE 2.6 System-Integration spezifizieren		v			m
SE 3.1 Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren		v
SE 3.2 Anforderungen an die externen Schnitt- stellen der SW-/HW-Einheit präzisieren		v
SE 3.3 Anforderungen an die Funktionalität definieren		v
SE 3.4 Anforderungen an die Qualität der SW-/ HW-Einheit definieren		v
SE 3.5 Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren		v			m		m
SE 4.1-SW SW-Architektur entwerfen			v		m
SE 4.2-SW SW-interne und -externe Schnittstellen entwerfen			v
SE 4.3-SW SW-Integration spezifizieren			v		m
SE 5.1-SW SW-Komponente/-Modul/Datenbank beschreiben			v		m
SE 5.2-SW Betriebsmittel- und Zeitbedarf analysieren			v
SE 6.1-SW SW-Module codieren			v
SE 6.2-SW Datenbank realisieren			v
SE 6.3-SW Selbstprüfung des SW-Moduls/der Datenbank durchführen			v
SE 7.1-SW Zur SW-Komponente integrieren			v
SE 7.2-SW Selbstprüfung der SW-Komponente durchführen			v
SE 7.3-SW Zur SW-Einheit integrieren			v
SE 7.4-SW Selbstprüfung der SW-Einheit durchführen			v
SE 4.1-HW Lösungsvorschläge erarbeiten und bewerten				v
SE 4.2-HW Grobentwurf einer HW-Einheit erarbeiten				v	m
SE 4.3-HW HW-interne Schnittstellen spezifizieren				v
SE 4.4-HW HW-Integration spezifizieren				v	m
SE 5.1-HW Detailentwürfe für HW-Komponenten/ HW-Module erstellen				v	m
SE 5.2-HW Zeichnungssatz erstellen				v
SE 5.3-HW Analysen und Nachweise durchführen				v
SE 6.1-HW HW-Komponente/HW-Modul anfertigen				v
SE 6.2-HW Selbstprüfung durchführen				v
SE 7.1-HW Zur HW-Teilstruktur integrieren				v
SE 7.2-HW HW-Teilstrukturen-Selbstprüfung durchführen				v
SE 7.3-HW Zur HW-Einheit integrieren				v
SE 7.4-HW HW-Einheiten-Selbstprüfung				v
SE 8.1 Zum System integrieren	b	v	m	m
SE 8.2 Selbstprüfung des Systems durchführen		v	m	m
SE 8.3 Produkt bereitstellen		v	m	m	m	m
SE 9.1 Beitrag zur Einführungsunterstützung leisten					m	v						m
SE 9.2 System installieren						v	m
SE 9.3 In Betrieb nehmen						v						m
Tabelle R.6:	Aktivitäten/Rollen-Matrix für SE


Tabellenverzeichnis AU250/3 - R
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - R)

A.1	Tabellenverzeichnis

Tabelle R.1:	Rollen im V-Modell

Tabelle R.2:	Beteiligungsarten

Tabelle R.3:	Aktivitäten/Rollen-Matrix für PM

Tabelle R.4:	Aktivitäten/Rollen-Matrix für QS

Tabelle R.5:	Aktivitäten/Rollen-Matrix für KM

Tabelle R.6:	Aktivitäten/Rollen-Matrix für SE


Projektmanager


Projektleiter


Projektadministrator


Rechtsverantwortlicher


Controller


Q-Manager


QS-Verantwortlicher


KM-Manager


SEU-Betreuer


IT-Beauftragter


Q-Manager


QS-Verantwortlicher


Prüfer


Projektleiter


KM-Manager


KM-Verantwortlicher


KM-Administrator


Datenadministrator


Projektleiter


Systembetreuer


Systemanalytiker


Systemdesigner


SW-Entwickler


HW-Entwickler


Technischer Autor


Systembetreuer


SEU-Betreuer


Datenadministrator


Datenschutzbeauftragter


IT-Sicherheitsbeauftragter


IT-Beauftragter


Anwender


Projektleiter


Vorbemerkungen (AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.1	Vorbemerkungen

Wenn SWPÄ-Projekte durchgeführt werden sollen, bei denen die Entwicklung und eventuell vorausgegangene SWPÄ-Maßnahmen nicht gemäß den Regelungen des V-Modells erfolgten, dann müssen zunächst die Grundlagen für die V-Modell-konforme Durchführung des Projekts geschaffen werden.

Die vorliegenden Regelungen für Reverse Engineering beschreiben anhand der folgenden neun Hauptaktivitäten, wie dabei vorzugehen ist:

−	Erhebung des Anwenderbedarfs,

−	Durchführung softwaretechnischer Verbesserungen,

−	Wiedergewinnung der technischen Sicht,

−	Wiedergewinnung der fachlichen Sicht,

−	Abbildung der fachlichen auf die technische Sicht,

−	SW-Integration,

−	Systemintegration,

−	Wiedereinführung des Systems,

−	Ermittlung wiederverwendungsfähiger Softwarebausteine.

Die Regelungen für Reverse Engineering ersetzen für die oben beschriebene Situation als "operatives Modul" die Regelungen des Submodells Systemerstellung (SE).


Begriffsbestimmung: Reverse Engineering
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.2	Begriffsbestimmung: Reverse Engineering

Angesichts der immer größer werdenden Menge an Software, die gepflegt und gewartet werden muß, sind Forderungen nach Maßnahmen, wodurch die Kosten der Softwarepflege und -änderung günstig beeinflußt werden, verständlich und gerechtfertigt.

Durch den Einsatz von Softwaretechniken, die unter dem Stichwort "Software Reengineering" zusammengefaßt werden, können solche Forderungen erfüllt werden, indem Merkmale vorhandener Software beeinflußt werden, die sich günstig auf die Softwarewartbarkeit auswirken.

Software Reengineering ist ein zweistufiger Prozeß, der sich zusammensetzt aus

−	Reverse Engineering und

−	Forward Engineering.

Die erste Stufe des Software-Reengineering-Prozesses wird als "Reverse Engineering" bezeichnet, weil sie im wesentlichen in Umkehrung des üblichen Vorgehens bei der Erstellung des Softwareanteils von IT-Systemen ausgeführt wird.

Die wesentlichen Aufgaben beim Reverse Engineering bestehen darin, die Struktur und das Verhalten des Softwareanteils vorhandener IT-Systeme zu verstehen, die Software aufzubereiten sowie nicht oder nicht mehr vorhandene Informationen über die Software wiederzugewinnen und auf abstrakten Ebenen zu beschreiben.

Reverse Engineering sollte als präventive Softwarepflegemaßnahme immer dann durchgeführt werden, wenn die Softwaredokumentation nur unvollständig oder gar nicht mehr zur Verfügung steht, wenn sie unverständlich ist, wenn sie nicht den aktuellen Zustand der Software widerspiegelt oder nicht den geforderten Dokumentationsstandards (hier: den Produktmustern des V-Modells) entspricht.

Die zweite Stufe des Software-Reengineering-Prozesses wird als "Forward Engineering" bezeichnet. Das Vorgehen beim Forward Engineering entspricht dem üblichen Vorgehen bei der Systemerstellung (hier: dem im Submodell SE beschriebenen Vorgehen).

Ziel beim Forward Engineering ist es, den Softwareanteil vorhandener IT-Systeme dem derzeitigen Technologiestand entsprechend zu modifizieren, was (im Gegensatz zum Reverse Engineering) auch zu funktionalen Änderungen der Software führen darf. Typische Beispiele für solche Modifizierungen sind der Wechsel in der Programmiersprache, der Übergang zu einem neuen Datenbankverwaltungssystem oder die Übertragung von Software auf eine neue Rechnerplattform.

Wenn Forward Engineering in Verbindung mit vorausgehendem Reverse Engineering durchgeführt wird, dann bilden die beim Reverse Engineering erzeugten Produkte die Grundlage für die Modifizierung der Software beim Forward Engineering. Generell läßt sich sagen, daß beim (hier beschriebenen) Reverse Engineering die (V-Modell-konformen) Grundlagen für die effiziente Durchführung von SWPÄ-Maßnahmen geschaffen werden.


Überblick (AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.1	Überblick

Während das Submodell Systemerstellung (SE) die Aktivitäten und Produkte vorgibt, die bei der Entwicklung bzw. Weiterentwicklung von IT-Systemen auszuführen bzw. zu erzeugen sind, beschreiben die Regelungen für Reverse Engineering (RE), wie bei der Durchführung von Reverse-Engineering-Maßnahmen vorzugehen ist.

Die Submodelle Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM), die die begleitenden Aktivitäten in einem Entwicklungsprojekt beschreiben, sind von den Regelungen für Reverse Engineering nicht betroffen und gelten in gleicher Weise wie für das Submodell Systemerstellung (SE).


Reverse-Engineering-Aktivitäten
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

In diesem Abschnitt werden alle RE-Aktivitäten im Detail anhand des aus dem Regelungsteil des V-Modells bekannten Aktivitätenschemas beschrieben.

Eine zusammenfassende Übersicht über alle RE-Aktivitäten und RE-Produkte findet sich im Abschnitt RE.3.4 am Ende dieses Handbuchs.


RE 1: Erhebung des Anwenderbedarfs
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
—	—		Anwenderbedarf		RE 2, RE 3, RE 4, RE 8, extern *)	vorgelegt
*)	Auftraggeber

**)	sonstige System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

Bei der Erhebung des Anwenderbedarfs wird der Ist-Zustand des vorhandenen Quellcodes und der übrigen vorhandenen System- und Softwaredokumentation aufgenommen und analysiert, um unter Reverse-Engineering-spezifischen Gesichtspunkten Schwachstellen zu ermitteln. Für die ermittelten Schwachstellen werden Lösungsmöglichkeiten aufgezeigt. Die technische Durchführbarkeit und Wirtschaftlichkeit der aufgezeigten Lösungsmöglichkeiten werden untersucht.


RE 1.1: Ist-Aufnahme durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

RE 1.1	Ist-Aufnahme durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
—	—		Anwenderbedarf.Ist-Aufnahme		RE 1.2 − RE 1.5	in Bearb.
*)	Auftraggeber

**)	sonstige System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

Bei der Ist-Aufnahme wird der Quellcode des zu bearbeitenden IT-Systems erfaßt und alle weiteren verfügbaren Informationen (einschließlich Informationen über die HW-Einheiten und die Nicht-IT-Anteile des IT-Systems)

−	ermittelt,

−	strukturiert und

−	archiviert.

Unter technischen (nicht aber unter wirtschaftlichen) Gesichtspunkten ist es gleichgültig, ob es sich um Quellcode in einer höheren Programmiersprache oder in einer Assembler-Sprache handelt. Im Falle von Assembler-Sprachen darf der Quellcode auch durch Disassemblierung, d. h. durch Rückübersetzung des Maschinenprogramms in die entsprechenden Befehle des Assemblers, erzeugt worden sein. Das gilt jedoch nicht für höhere Programmiersprachen, weil Aufwärtsübersetzung in diesem Fall nicht zum Quellcode zurückführt.

Voraussetzung für die Ermittlung weiterer Informationen (und Informationsquellen) ist es im allgemeinen, daß der Ermittlung vorausgehend oder parallel dazu eine Einarbeitung in die Umwelt des Auftraggebers erfolgt, d. h. in dessen Aufbau- und Ablauforganisation sowie in Dienstvorschriften, Erlasse, Gesetze, Richtlinien und ähnliches, wodurch die fachlichen Aufgaben von Anwendern und Nutzern beeinflußt werden.

Geeignete Suchräume für die Ermittlung weiterer Informationen (und Informationsquellen) sind das Umfeld von Anwendern, Nutzern, SE-, QS-, KM- und PM-Verantwortlichen. Geeignete Informationen können in schriftlicher bzw. maschinenlesbarer Form, aber auch in Form von Wissen vorliegen, das von den jeweiligen Wissensträgern erfragt werden muß.

Vorrangiges Interesse wird bei der Ist-Aufnahme der Erfassung des Quellcodes und der fachlichen Informationen gewidmet, weil sie die wesentlichen Eingangsgrößen für die geplante Reverse-Engi-neering-Maßnahme sind. Demgegenüber ist die Erfassung von SW-technischen Informationen, z. B. über den SW-Entwurf, die SW-Architektur und die Technischen Anforderungen, von untergeordneter Bedeutung, weil sie beim Reverse Engineering unmittelbar aus dem Quellcode abgeleitet werden können. Die Aufnahme solcher Informationen ist allenfalls dadurch gerechtfertigt, daß auch sie Informationen über die fachliche Sicht auf die Software enthalten können. Da keine Übernahme der SW-technischen Informationen in die im weiteren Verlauf der Reverse-Engineering-Maßnahme entstehenden Produkte, insbesondere auch keine Transformation vorhandener SW-technischer Dokumente in V-Modell-Produkte, vorgesehen ist, muß ihre Korrektheit und ihre Konsistenz mit dem Quellcode nicht nachgewiesen werden. Das wäre unter wirtschaftlichen Gesichtspunkten auch wenig sinnvoll, weil die unmittelbare Ableitung der SW-technischen Informationen aus dem Quellcode mit geringerem Aufwand möglich ist.

Bevor die ermittelten Informationen archiviert werden, werden sie unter geeigneten Gesichtspunkten strukturiert:

−	Eine grobe Strukturierung läßt sich beispielsweise vornehmen, indem unterschieden wird zwischen in erster Linie SW-technischen Informationen und in erster Linie fachlichen Informationen.

−	Eine weitere Strukturierung kann vorgenommen werden, indem hinsichtlich des Abstraktionsgrades der Informationen (betreffen sie z. B. die Implementierung, den Entwurf oder die Anforderungen) unterschieden wird.

−	Möglicherweise lassen sich auch bereits Beziehungen aufzeigen, die zwischen den ermittelten Informationen bestehen, und Zuordnungen vornehmen, zur Unterstützung welcher Reverse-Engineering-Aktivität bestimmte Informationen und Informationsquellen am besten geeignet sind.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Anwenderbedarf.Ist-Aufnahme" dokumentiert.

Empfehlung

Die Archivierung der bei der Ist-Aufnahme erfaßten Informationen erfolgt am besten werkzeuggestützt, z. B. unter Zuhilfenahme eines KM-Werkzeugs.

Änderungen sollten nur an einer Kopie der erfaßten Informationen vorgenommen werden, damit der ursprüngliche Informationsbestand als Beleg gegenüber dem Auftraggeber erhalten bleibt.


RE 1.2: Ist-Analyse durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

RE 1.2	Ist-Analyse durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
RE 1.1	in Bearb.		Anwenderbedarf.Ist-Aufnahme		—	—
—	—		Anwenderbedarf.Ist-Analyse		RE 1.3 − RE 1.5	in Bearb.
*)	Auftraggeber

**)	sonstige System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

Bei der Ist-Analyse wird der Ist-Zustand des vorhandenen Quellcodes und der übrigen vorhandenen System- und Softwaredokumentation unter Reverse-Engineering-spezifischen Gesichtspunkten beurteilt. Dazu werden Schwachstellen im Quellcode ermittelt, die durch die geplante Reverse-Engineering-Maßnahme verbessert werden können, beispielsweise

−	in der SW-Architektur,

−	in den Ablauf- und Datenstrukturen,

−	im Layout und

−	in der Kommentierung,

sowie Schwachstellen in der übrigen Dokumentation, beispielsweise

−	fehlende Dokumente,

−	unvollständige Dokumente oder

−	Abweichungen vom aktuellen Zustand der Software.

Soweit wie möglich werden auch die Ursachen für die ermittelten Schwachstellen aufgezeigt und festgehalten.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Anwenderbedarf.Ist-Analyse" dokumentiert.


RE 1.3: Lösungsvorschläge formulieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

RE 1.3	Lösungsvorschläge formulieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
RE 1.1	in Bearb.		Anwenderbedarf.Ist-Aufnahme		—	—
RE 1.2	in Bearb.		Anwenderbedarf.Ist-Analyse		—	—
—	—		Anwenderbedarf.Lösungsvorschläge		RE 1.4 − RE 1.5	in Bearb.
*)	Auftraggeber

**)	sonstige System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

In dieser Aktivität wird untersucht und festgelegt, wie die bei der Ist-Analyse erkannten Schwachstellen behoben werden können. Unter anderem können dazu folgende typischen Reverse-Engineering-Aufgaben geeignet sein:

−	Reformatierung des Quellcodes zur Verbesserung des Layouts,

−	Restrukturierung der Ablaufstrukturen, z. B. unter Beachtung der Prinzipien der Strukturierten Programmierung,

−	Rationalisierung der Daten, z. B. durch Auflösen von Redundanzen,

−	Rekommentierung des Quellcodes aus fachlicher Sicht,

−	Remodularisierung zur Verbesserung der Architektur der Software,

−	Wiedergewinnung und Dokumentierung der technischen Sicht (z. B. SW-Entwurf, SW-Architektur, Technische Anforderungen),

−	Wiedergewinnung und Dokumentierung der fachlichen Sicht auf die Software (Anwenderforderungen).

Bei allen Festlegungen muß darauf geachtet werden, daß die Lösungsvorschläge nicht zu funktionalen Änderungen oder Erweiterungen der zu bearbeitenden Software führen.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Anwenderbedarf.Lösungsvorschläge" dokumentiert.


RE 1.4: Technische Durchführbarkeit untersuchen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

RE 1.4	Technische Durchführbarkeit untersuchen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
RE 1.1	in Bearb.		Anwenderbedarf.Ist-Aufnahme		—	—
RE 1.2	in Bearb.		Anwenderbedarf.Ist-Analyse		—	—
RE 1.3	in Bearb.		Anwenderbedarf.Lösungsvorschläge		—	—
—	—		Anwenderbedarf.Technische Durchführbarkeit		RE 1.5	in Bearb.
*)	Auftraggeber

**)	sonstige System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

In dieser Aktivität wird untersucht, ob die grundlegenden technischen Voraussetzungen für die Durchführung der geplanten Reverse-Engineering-Maßnahme erfüllt sind. Bei der Untersuchung müssen folgende Fragen geklärt werden:

−	Ist der Quellcode vollständig verfügbar?

Die Forderung nach der Vollständigkeit des Quellcodes ist darin begründet, daß aus dem erfaßten Quellcode lauffähige Software erzeugbar sein muß, die das gleiche Verhalten zeigt wie die ursprünglich vorhandene lauffähige Software.

Wenn es sich bei der zu bearbeitenden Software um Assembler-Programme handelt, dann wird der Nachweis der Vollständigkeit des Quellcodes am einfachsten geführt, indem aus der vorhandenen lauffähigen Software durch Disassemblierung der Quellcode zurückgewonnen wird.

Handelt es sich um Quellcode in einer höheren Programmiersprache, kann der Nachweis der Vollständigkeit und der Aktualität des Quellcodes geführt werden, indem die Konfigurationsdokumente ausgewertet werden oder indem aus dem erfaßten Quellcode lauffähige Software erzeugt und der Inhalt der erzeugten ausführbaren Dateien byteweise mit dem Inhalt der ursprünglich vorhandenen ausführbaren Dateien verglichen wird. Es gilt allerdings nicht in jedem Fall der Schluß, daß der Quellcode unvollständig erfaßt wurde, wenn die verglichenen Dateiinhalte voneinander abweichen, weil solche Unterschiede nicht notwendigerweise zu Unterschieden im Verhalten der ausführbaren Software führen müssen.

Andere Möglichkeiten zur Prüfung des Quellcodes können allenfalls zu Hinweisen auf Unvollständigkeit, nicht aber zum Nachweis der Vollständigkeit führen. So kann beispielsweise anhand der Fehlermeldungen beim Übersetzen und Binden auf Unvollständigkeit des Quellcodes geschlossen werden. Auch können bei wenig komplexen Anwendungen durch Beobachtung des Ablaufs Unterschiede im Verhalten der erzeugten und der ursprünglich vorhandenen Software ermittelt werden, die auf Unvollständigkeit des Quellcodes schließen lassen. Hinweise auf Unvollständigkeit können darüber hinaus statisch ermittelt werden, indem die Aufrufbeziehungen im Quellcode und die verwendeten Datenobjekte untersucht werden. Wird eine Prozedur aufgerufen, die nicht zu der Menge des erfaßten Quellcodes gehört, ist der Quellcode vermutlich unvollständig. Gleiches gilt, wenn Datenobjekte referenziert werden, die im erfaßten Quellcode nicht deklariert worden sind. Bei dieser Art der Untersuchung muß allerdings berücksichtigt werden, daß Bezeichner in unterschiedlichen Teilen des Quellcodes mehrfach belegt sein können, daß rufende Prozeduren auch auf nicht zu erreichenden Programmpfaden liegen können und daß nicht in allen Programmiersprachen die explizite Deklaration von Datenobjekten vorgesehen ist.

−	Kann aus dem Quellcode lauffähige Software erzeugt werden?

Die Forderung nach der Erzeugbarkeit lauffähiger Software aus dem vorhandenen Quellcode ist darin begründet, daß aus der Beobachtung deren Verhaltens (in Zusammenarbeit mit Trägern fachlichen Wissens) wesentliche Rückschlüsse auf die Beziehungen zwischen den fachlichen Aufgaben, die die Software realisiert, und der technischen Struktur der Software gezogen werden können. Auch für die Prüfung der überarbeiteten Software ist es erforderlich, daß aus dem geänderten Quellcode lauffähige Software erzeugt werden kann.

Voraussetzung für die Erzeugung lauffähiger Software aus dem Quellcode ist, daß die ursprüngliche oder eine geeignete, zur ursprünglichen kompatible Entwicklungsumgebung (Übersetzer, Binder, Lader, Bibliothekssoftware usw.) zur Verfügung steht. Außerdem müssen Anweisungen für das Übersetzen, Binden, Laden und Installieren bekannt sein.

−	Sind fachliche Informationen in hinreichender Menge verfügbar?

Die Forderung nach der Verfügbarkeit einer hinreichenden Menge an fachlichen Informationen ist darin begründet, daß fachliche Informationen unverzichtbare Voraussetzung für die Wiedergewinnung der Anwenderforderungen sind, die die zu bearbeitende Software realisiert. Ohne fachliche Informationen kann Reverse Engineering nur zur Wiedergewinnung der technischen Sicht auf die zu bearbeitende Software führen.

Da auf dieser Stufe des Reverse-Engineering-Prozesses noch keine Aussage über die Qualität der zur Verfügung stehenden fachlichen Informationen möglich ist, muß deren Quantität als Indiz für die technische Durchführbarkeit genommen werden.

Nicht für jede geplante Reverse-Engineering-Maßnahme müssen alle der genannten Voraussetzungen erfüllt sein. Für die typischen Reverse-Engineering-Aufgaben gilt beispielsweise:

−	Reformatierung, Restrukturierung, Remodularisierung:

Der vollständige Quellcode und die Entwicklungsumgebung müssen verfügbar sein, weil keine Änderung am Quellcode ohne nachfolgende Prüfung vorgenommen werden darf. Fachliche Informationen sind nicht erforderlich, weil bei dieser Aufgabe ausschließlich die technische Sicht auf die Software betroffen ist.

Wenn die zu bearbeitende Software Prozesse realisiert, dann sollte die Remodularisierung nicht beim Reverse Engineering, sondern im Zusammenhang mit der Durchführung von Forward-Engineering-Maßnahmen vorgenommen werden.

−	Rekommentierung:

Der vollständige Quellcode, die Entwicklungsumgebung und fachliche Informationen müssen verfügbar sein, weil auch Änderungen an den Kommentaren des Quellcodes nicht ohne nachfolgende Prüfung vorgenommen werden dürfen und der Quellcode ohne fachliche Informationen nicht auf sinnvolle Weise, d. h. unter fachlichen Gesichtspunkten, kommentiert werden kann.

−	Wiedergewinnung der technischen Sicht auf die Software:

Für die Wiedergewinnung der technischen Sicht auf die Software ist die Verfügbarkeit des Quellcodes hinreichend, weil die Dokumentation der technischen Sicht unmittelbar aus dem Quellcode extrahiert werden kann.

−	Wiedergewinnung der fachlichen Sicht auf die Software:

Für die Wiedergewinnung der Anwenderforderungen kann die Verfügbarkeit des Quellcodes nur dann ausreichen, wenn auf Grund einer sehr guten Kommentierung alle erforderlichen fachlichen Informationen aus dem Quellcode entnommen werden können oder wenn als Informationsquelle der ursprüngliche Entwickler der Software zur Verfügung steht und dieser auf der Grundlage des Quellcodes die Anwenderforderungen benennen kann. Im allgemeinen ist jedoch die Wiedergewinnung der fachlichen Sicht auf die Software von der Verfügbarkeit quellcodeexterner fachlicher Informationen abhängig.

Die Ergebnisse der Untersuchung der technischen Durchführbarkeit werden in dem Produkt "Anwenderbedarf.Technische Durchführbarkeit" dokumentiert. Sie bilden die Grundlage für die anfängliche Entscheidung darüber, ob die Reverse-Engineering-Maßnahme durchgeführt werden kann. Die letztliche Entscheidung über die Durchführung der Maßnahme ergibt sich aus der Untersuchung der Wirtschaftlichkeit der geplanten Reverse-Engineering-Maßnahme.


RE 1.5: Wirtschaftlichkeit untersuchen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 1	Erhebung des Anwenderbedarfs

RE 1.5	Wirtschaftlichkeit untersuchen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
Extern *)	—		weitere Informationen **)		—	—
RE 1.1	in Bearb.		Anwenderbedarf.Ist-Aufnahme		—	—
RE 1.2	in Bearb.		Anwenderbedarf.Ist-Analyse		—	—
RE 1.3	in Bearb.		Anwenderbedarf.Lösungsvorschläge		—	—
RE 1.4	in Bearb.		Anwenderbedarf.Technische Durchführbarkeit		—	—
—	—		Anwenderbedarf.Wirtschaftlichkeit		RE 1.5	in Bearb.
—	—		Anwenderbedarf		RE 2.1 − RE 2.3, RE 3.1 − RE 3.2, RE 4.1, RE 8.2, extern *)	vorgelegt
*)	Auftraggeber

**)	Informationen über derzeitige SWPÄ-Kosten

Abwicklung

In dieser Aktivität wird untersucht, ob die Durchführung der geplanten Reverse-Engineering-Maßnahme wirtschaftlich ist. Da Reverse Engineering in erster Linie auf die Verbesserung der Softwarewartbarkeit zielt, ist die wirtschaftliche Durchführbarkeit dann gegeben, wenn die Summe aus den Kosten der Reverse-Engineering-Maßnahme und den Kosten, die für die Pflege und Änderung der überarbeiteten Software zukünftig anfallen, geringer ist als die Kosten, die derzeit durch die Pflege und Änderung der vorhandenen Software entstehen. Für diesen Vergleich ist es notwendig, ein geeignetes Kosten- und Nutzenschätzverfahren und geeignete Softwaremaße auszuwählen.

Empfehlung

Als Grundlage für die Untersuchung der Wirtschaftlichkeit können beispielsweise die "Empfehlungen zur Durchführung von Wirtschaftlichkeitsbetrachtungen beim Einsatz der IT in der Bundesverwaltung" herangezogen werden (herausgegeben von der KBSt, ISSN 01 79 - 72 63).


RE 2: Durchführung softwaretechnischer Verbesserungen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
RE 1	akzeptiert		Anwenderbedarf		—	—
—	—		Sachbericht "Messung des Quellcodes"		RE 8, extern *)	vorgelegt
—	—		Implementierungsdokumente (SW-Modul) / SW-Modul **)		RE 3, RE 5	in Bearb.
—	—		Implementierungsdokumente (Datenbank) / Datenbank **)		RE 3, RE 5	in Bearb.
*)	Auftraggeber

**)	verbesserter Code

Abwicklung

In dieser Aktivität werden auf der Grundlage des Teilprodukts "Anwenderbedarf.Lösungsvorschläge" softwaretechnische Verbesserungen am vorhandenen Quellcode vorgenommen. Dazu können beispielsweise die Verbesserung des modularen Aufbaus, die Verbesserung der Ablauf- und Datenstrukturen sowie die Verbesserung des Layouts gehören. Vor und nach der Durchführung von Verbesserungen wird der Quellcode unter Anwendung von Softwaremaßen gemessen, um den Erfolg der durchgeführten Verbesserungen nachzuweisen. Für den verbesserten Code (SW-Module, Datenbanken) werden die Implementierungsdokumente (SW-Modul) und die Implementierungsdokumente (Datenbank) erstellt. Darüber hinaus werden auf der Grundlage der Meßergebnisse jene Softwarebausteine festgelegt, die bei einer sich anschließenden Forward-Engineering-Maßnahme weiterverwendet werden können bzw. neuentwickelt werden sollten.

Erläuterung

Die Festlegung von Meßverfahren und Meßkriterien wird aus dem Projekthandbuch übernommen, das bei der Durchführung von Reverse-Engineering-Projekten um einen entsprechenden Abschnitt zu ergänzen ist.


RE 2.1: Vorhandenen Quellcode messen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.1	Vorhandenen Quellcode messen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
RE 1.5	akzeptiert		Anwenderbedarf		—	—
—	—		Sachbericht "Messung des Quellcodes.Vorhandener Quellcode"		RE 2.4, RE 2.5	in Bearb.
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird auf der Grundlage des Teilprodukts "Anwenderbedarf.Lösungsvorschläge" der vorhandene Quellcode unter Anwendung geeigneter Softwaremaße gemessen, damit sich im Anschluß an die Durchführung softwaretechnischer Verbesserungen im Vergleich mit den Ergebnissen der Messung des verbesserten Codes der Nachweis erbringen läßt, daß die durchgeführten Verbesserungen erfolgreich waren.

Da es das Ziel von Reverse-Engineering-Maßnahmen ist, die Wartbarkeit der zu bearbeitenden Software zu verbessern, gilt es in dieser Aktivität solche Softwaremaße anzuwenden, mit denen die Softwarewartbarkeit beurteilt werden kann.

Die Ergebnisse der Messung des vorhandenen Quellcodes werden in dem Sachbericht "Messung des Quellcodes.Vorhandener Quellcode" dokumentiert.

Empfehlung

Für die Bewertung der Softwarewartbarkeit eignen sich vor allem Softwaremaße, mit denen der Steuerfluß und der Datenfluß gemessen werden kann.


RE 2.2: Remodularisierung / Restrukturierung
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.2	Remodularisierung / Restrukturierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		vorhandener Quellcode		—	—
RE 1.5	akzeptiert		Anwenderbedarf		—	—
—	—		Implementierungsdokumente (SW-Modul) / SW-Modul		RE 2.3	in Bearb.
—	—		Implementierungsdokumente (Datenbank) / Datenbank		RE 2.3	in Bearb.
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird auf der Grundlage des Teilprodukts "Anwenderbedarf.Lösungsvorschläge" angestrebt, den modularen Aufbau der zu bearbeitenden Software unter Beachtung von Modularisierungsprinzipien wie Abgeschlossenheit, Geheimnisprinzip, Datenabstraktion, Kapselung, Schnittstellenspezifikation, Schnittstellenminimalität, Überschaubarkeit und Testbarkeit zu verbessern.

Es muß allerdings berücksichtigt werden, daß es bei den derzeitigen technischen Möglichkeiten in der Praxis häufig so sein wird, daß sich Remodularisierung darauf beschränken muß, SW-Module, die auf der Grundlage des Kriteriums "Anzahl der Anweisungen" als zu groß beurteilt wurden, auf mehrere SW-Module aufzuteilen. Ausgangspunkt für die Zerlegung kann der Steuerflußgraph sein, anhand dessen größere zusammenhängende Strukturen ermittelt und in eigene SW-Module umgewandelt werden. Verzweigungen zwischen diesen neuen SW-Modulen werden im Quellcode durch Aufrufanweisungen ersetzt. Bei der Aufteilung von SW-Modulen muß darauf geachtet werden, daß alle SW-Module nur solche Daten enthalten, die sie tatsächlich verwenden (Geheimnisprinzip).

Mit einer so verstandenen Remodularisierung ist immer auch eine Restrukturierung verbunden. Zur Restrukturierung gehören jedoch zusätzlich auch solche Maßnahmen, die unabhängig von den Änderungen am modularen Aufbau zur Verbesserung der Ablauf- und Datenstrukturen beitragen und damit die Verständlichkeit des Quellcodes verbessern.

Die Ablaufstrukturen können z. B. unter Beachtung der Prinzipien der Strukturierten Programmierung verbessert werden, d. h. es wird die ausschließliche Verwendung der Steuerstrukturen Sequenz, Selektion, Iteration und Prozeduraufruf angestrebt. Insbesondere sollten, so weit sinnvoll und möglich, goto-Anweisungen im Quellcode durch strukturierte Steueranweisungen ersetzt werden. Zu einer Reihe einfacher restrukturierender Maßnahmen gehören die Verlagerung bzw. Duplizierung von Codeblöcken, das grundsätzliche Hinzufügen von else-Klauseln, die Umstrukturierung von if-Anweisungen, die Verdeutlichung von Programmschleifen und die Vermeidung von Label-Variablen.

Die vorhandenen Datenobjekte können beispielsweise verbessert werden, indem Inkonsistenzen und Redundanzen aufgelöst werden. Inkonsistent sind z. B. Datenobjekte, die den gleichen Namen, jedoch unterschiedliche Aufgaben haben (Homonyme). Redundant sind Datenobjekte, die unterschiedliche Namen, jedoch die gleiche Aufgabe haben (Synonyme; Alias-Namen). Indizien für Synonyme können gleiche Formate und gleiche Wertebereiche von Objekten mit unterschiedlichen Namen sein. Homonyme lassen sich ermitteln, indem die Merkmale der gleichlautenden Datenobjekte miteinander verglichen werden. Haben beispielsweise gleichlautende Datenobjekte unterschiedliche Formate und unterschiedliche Wertebereiche, dann handelt es sich wahrscheinlich um Homonyme.

Die Auflösung von Homonymen und Synonymen darf nicht mechanisch erfolgen. Es müssen vielmehr genaue Untersuchungen durchgeführt werden, die jeden Irrtum ausschließen. Bei der Vergabe von neuen Bezeichnungen für homonyme und synonyme Objekte muß darauf geachtet werden, daß die neuen Namen fachlich orientiert sind, so daß vom Namen des Objekts auf dessen fachliche Aufgabe oder den von ihm repräsentierten Typ geschlossen werden kann. Da zu diesem Zeitpunkt noch kein fachliches Verständnis der zu bearbeitenden Software erworben wurde, kann die Vergabe neuer Bezeichner erst im Zusammenhang mit der Rekommentierung (Aktivität RE 5.2) erfolgen.

Die Ergebnisse dieser Aktivität werden in den Produkten "Implementierungsdokumente (SW-Modul)" und "SW-Modul" bzw. "Implementierungsdokumente (Datenbank)" und "Datenbank" dokumentiert.


RE 2.3: Reformatierung
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.3	Reformatierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 1.5	akzeptiert		Anwenderbedarf		—	—
RE 2.2	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		RE 2.4, RE 3.2 −  RE 3.6, RE 3.8, RE 5.1, RE 5.2	in Bearb.
RE 2.2	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		RE 2.4, RE 3.2, RE 3.4, RE 3.5, RE 3.6, RE 3.8, RE 5.1, RE 5.2	in Bearb.
Abwicklung

Bei der Reformatierung wird auf der Grundlage des Teilprodukts "Anwenderbedarf.Lösungsvorschläge" und des in der vorausgehenden Teilaktivität remodularisierten und restrukturierten Codes dessen Layout und damit dessen Lesbarkeit verbessert.

Dazu können beispielsweise folgende Maßnahmen geeignet sein:

−	Einrückungen zur Verdeutlichung der logischen Struktur,

−	Einfügen von Kommentaren, um den Anfang und das Ende bestimmter Programmabschnitte anzuzeigen,

−	Hervorheben (Fett- oder Kursivdruck) von Prozeduraufrufen,

−	Unterstreichen von Bedingungen wie if oder case,

−	Einfügen von Leerzeilen vor und nach längeren Programmstrukturen,

−	Markieren von Bereichen, z. B. deklarativer Programmteil,

−	Markieren von Bezeichnern, die für einen globalen Bereich gelten.

Die Ergebnisse dieser Aktivität werden in den Produkten "Implementierungsdokumente (SW-Modul)" und "SW-Modul" bzw. "Implementierungsdokumente (Datenbank)" und "Datenbank" dokumentiert.


RE 2.4: Verbesserten Quellcode messen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.4	Verbesserten Quellcode messen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.1	in Bearb.		Sachbericht "Messung des Quellcodes.Vorhandener Quellcode"		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
—	—		Sachbericht "Messung des Quellcodes.Verbesserter Quellcode"		RE 2.5	in Bearb.
Abwicklung

In dieser Aktivität wird unter Anwendung der bei der Messung des vorhandenen Quellcodes eingesetzten Softwaremaße der verbesserte Quellcode gemessen. Dadurch wird der Nachweis geführt, daß die durchgeführten Verbesserungen erfolgreich waren, d. h. daß sie zur Verbesserung der Softwarewartbarkeit geführt haben. Die Ergebnisse dieser Aktivität werden in dem Sachbericht "Messung des Quellcodes.Verbesserter Quellcode" dokumentiert.


RE 2.5: Weiterverwendungsfähige Softwarebausteine festlegen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.5	Weiterverwendungsfähige Softwarebausteine festlegen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.1	in Bearb.		Sachbericht "Messung des Quellcodes.Vorhandener Quellcode"		—	—
RE 2.4	in Bearb.		Sachbericht "Messung des Quellcodes.Verbesserter Quellcode"		—	—
—	—		Sachbericht "Messung des Quellcodes.Weiterverwendungsfähige Softwarebausteine"		RE 2.5	in Bearb.
—	—		Sachbericht "Messung des Quellcodes"		RE 8.2, extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden auf der Grundlage der Ergebnisse der Messung des verbesserten Quellcodes jene Softwarebausteine festgelegt, die sich für eine Weiterverwendung im Rahmen einer im Anschluß an die Reverse-Engineering-Maßnahme vorgesehenen Forward-Engineering-Maßnahme eignen. Jene Softwarebausteine, für die keine Weiterverwendungsfähigkeit festgelegt wird, sollten beim Forward Engineering durch Neuentwicklungen ersetzt werden.

Die Ergebnisse dieser Aktivität werden in dem Sachbericht "Messung des Quellcodes.
Weiterverwendungsfähige Softwarebausteine" dokumentiert.


RE 3: Wiedergewinnung der technischen Sicht
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		weitere Informationen **)		—	—
RE 1	akzeptiert		Anwenderbedarf		—	—
RE 2	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
—	—		Systemarchitektur		RE 5	in Bearb.
—	—		Schnittstellenübersicht		Extern *)	vorgelegt
—	—		Schnittstellenbeschreibung		Extern *)	vorgelegt
—	—		SW-Architektur		RE 5	in Bearb.
—	—		SW-Entwurf		RE 5	in Bearb.
—	—		Datenkatalog		RE 4	in Bearb.
—	—		Technische Anforderungen		Extern *)	vorgelegt
—	—		Betriebsinformationen		RE 7	in Bearb.
—	—		Integrationsplan		RE 6, RE 7, extern *)	vorgelegt
*)	Auftraggeber

**)	vorhandene System- und Softwaredokumentation, günstigstenfalls vorhandene Konfigurationsdokumente

Abwicklung

In dieser Aktivität wird unter Nutzung der Informationen aus dem Produkt "Anwenderbedarf" und weiterer Informationen aus dem in der vorausgegangenen Aktivität verbesserten Quellcode die technische Sicht auf die zu bearbeitende Software extrahiert. Die technische Sicht wird dargestellt in den Produkten "Systemarchitektur", "Schnittstellenübersicht", "Schnittstellenbeschreibung", "SW-Architektur", "SW-Entwurf", "Datenkatalog", "Technische Anforderungen", "Betriebsinformationen" und "Integrationsplan".


RE 3.1: Systemarchitektur wiedergewinnen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.1	Systemarchitektur wiedergewinnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		weitere Informationen **)		—	—
RE 1.5	akzeptiert		Anwenderbedarf		—	—
—	—		Systemarchitektur.Struktur des Systems		RE 3.2	in Bearb.
—	—		Betriebsinformationen		RE 3.4	in Bearb.
*)	Auftraggeber

**)	vorhandene System- und Softwaredokumentation, günstigstenfalls vorhandene Konfigurationsdokumente

Abwicklung

In dieser Aktivität wird auf der Grundlage weiterer Informationen (günstigstenfalls vorhandene Konfigurationsdokumente) und unter Nutzung der Informationen aus dem Produkt "Anwenderbedarf" der technische Aufbau des Systems wiedergewonnen. Da im allgemeinen davon ausgegangen werden muß, daß auf vorhandene Systeme der Begriff "Segment" nicht anwendbar ist, wird das System als unmittelbar in SW-Einheiten, HW-Einheiten und Nicht-IT-Anteile gegliedert beschrieben.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Systemarchitektur.Struktur des Systems" dokumentiert. Der technische Aufbau des Systems fließt ein in die Informationen zum Betriebshandbuch. Angaben über die Diagnoseumgebung und Diagnosemaßnahmen fließen in das Diagnosehandbuch ein.


RE 3.2: Systeminterne und -externe Schnittstellen wiedergewinnen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.2	Systeminterne und -externe Schnittstellen wiedergewinnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		weitere Informationen **)		—	—
RE 1.5	akzeptiert		Anwenderbedarf		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.1	in Bearb.		Systemarchitektur.Struktur des Systems		RE 3.10, RE 5.1	in Bearb.
—	—		Schnittstellenübersicht		RE 3.5	in Bearb.
—	—		Schnittstellenbeschreibung		RE 3.5	in Bearb.
*)	Auftraggeber

**)	vorhandene System- und Softwaredokumentation, günstigstenfalls vorhandene Konfigurationsdokumente

Abwicklung

In dieser Aktivität werden unter Nutzung der Informationen aus dem Produkt "Anwenderbedarf" und auf der Grundlage weiterer Informationen (günstigstenfalls vorhandener Konfigurationsdokumente), der Implementierungsdokumente (SW-Modul/Datenbank) und der in der vorausgehenden Teilaktivität beschriebenen Systemarchitektur die systeminternen und systemexternen Schnittstellen wiedergewonnen. Da auf die Einführung der Segmentebene verzichtet wurde, werden als systeminterne Schnittstellen die Schnittstellen zwischen SW-Einheiten, HW-Einheiten und Nicht-IT-Anteilen beschrieben.

Die systemexternen Schnittstellen sind die Schnittstellen des Systems zu seiner Umgebung, d. h. zum Nutzer und zu anderen Systemen.

Die Ergebnisse dieser Aktivität werden in dem Teilprodukt "Systemarchitektur.Struktur des Systems" und in den Produkten "Schnittstellenübersicht" und "Schnittstellenbeschreibung" dokumentiert.


RE 3.3: Prozeßentwurf wiedergewinnen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.3	Prozeßentwurf wiedergewinnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
—	—		SW-Architektur. Modularisierung/Datenbankentwurf		RE 3.4	in Bearb.
Abwicklung

In dieser Aktivität werden die Implementierungsdokumente (SW-Modul) bzw. die SW-Module hinsichtlich möglicherweise vorhandener echtzeitspezifischer Zusammenhänge untersucht und der Prozeßentwurf, d. h. die einzelnen Prozesse und die dynamischen Zusammenhänge zwischen den Prozessen, wiedergewonnen. Die Ergebnisse dieser Aktivität werden in dem Produkt "SW-Architektur.Modularisierung/Datenbankentwurf" dokumentiert.

Erläuterung

Für die Wiedergewinnung des Prozeßentwurfs werden die SW-Module daraufhin untersucht, ob sie (im Falle von Programmiersprachen wie Ada, die über sprachinterne Mittel zur Realisierung von Prozessen verfügen) Schlüsselwörter enthalten, die auf Prozesse hinweisen, oder (im Falle von Programmiersprachen, die nicht über sprachinterne Mittel zur Realisierung von Prozessen verfügen) Betriebssystemaufrufe enthalten, über die Prozesse realisiert werden.


RE 3.4: SW-Architektur beschreiben
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.4	SW-Architektur beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.1	in Bearb.		Betriebsinformationen		RE 3.6	in Bearb.
RE 3.3	in Bearb.		SW-Architektur. Modularisierung/Datenbankentwurf		RE 3.5, RE 3.7, RE 3.9, RE 5.1	in Bearb.
Abwicklung

In dieser Aktivität wird auf der Grundlage des verbesserten Quellcodes und unter Beachtung des in der vorausgehenden Teilaktivität wiedergewonnenen Prozeßentwurfs die SW-Architektur beschrieben. Dazu werden zusammengehörige SW-Module und Datenbanken jeweils einer SW-Einheit zugeordnet und die Zuordnung dokumentiert. Kriterien für die Zusammengehörigkeit von SW-Modulen und Datenbanken zu einer SW-Einheit sind der Austausch von Daten oder die gemeinsame Verwendung von Daten. Es muß somit ermittelt werden, welche Import- und Exportbeziehungen zwischen den SW-Modulen bestehen.

Die Ergebnisse dieser Aktivität sind eine Beschreibung der statischen Zerlegung einer SW-Einheit in SW-Module im Sinne einer "besteht-aus"-Hierarchie und ein Grobentwurf der evtl. vorhandenen Datenbanken der SW-Einheit. Sie werden im Produkt "SW-Architektur.Modularisierung/Datenbankentwurf" dokumentiert, das für jede SW-Einheit erstellt wird. Auf der Basis der SW-Architektur werden auf die SW-Einheit bezogene Angaben zu den Betriebsinformationen erstellt.


RE 3.5: SW-interne Schnittstellen beschreiben
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.5	SW-interne Schnittstellen beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.2	in Bearb.		Schnittstellenübersicht		Extern *)	vorgelegt
RE 3.2	in Bearb.		Schnittstellenbeschreibung		RE 3.9, RE 3.10, extern *)	vorgelegt
RE 3.4	in Bearb.		SW-Architektur. Modularisierung/Datenbankentwurf		—	—
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden die internen Schnittstellen der SW-Einheit beschrieben. Dazu werden die Implementierungsdokumente (SW-Modul) bzw. die SW-Module und die Implementierungsdokumente (Datenbank) bzw. die Datenbanken untersucht. SW-interne Schnittstellen sind die Schnittstellen zwischen SW-Modulen untereinander sowie zwischen den SW-Modulen und Datenbanken einer SW-Einheit.

Auf die Beschreibung der SW-externen Schnittstellen, d. h. der Schnittstellen zwischen den SW-Einheiten sowie der Schnittstellen zu HW-Einheiten und Nicht-IT-Anteilen, kann verzichtet werden, da sie mit den systeminternen Schnittstellen identisch sind, die bereits in Aktivität RE 3.2 beschrieben wurden.

Die Schnittstellen werden nach folgenden Gesichtspunkten beschrieben:

−	beteiligte SW-Module,

−	Realisierung,

−	Informationen und Dienstleistungen (Daten und Aktionen, die angeboten oder angefordert werden),

−	Benutzung und Bedienung (soweit relevant).

Die Ergebnisse dieser Aktivität werden in den Produkten "Schnittstellenübersicht" und "Schnittstellenbeschreibung" dokumentiert.


RE 3.6: SW-Entwurf beschreiben
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.6	SW-Entwurf beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.4	in Bearb.		Betriebsinformationen		RE 3.8	in Bearb.
—	—		SW-Entwurf.SW-Modul- Beschreibung bzw. SW- Entwurf.Datenbankbeschreibung		RE 3.7, RE 5.2	in Bearb.
Abwicklung

In dieser Aktivität wird auf der Grundlage des verbesserten Quellcodes die Realisierung der SW-Module und Datenbanken unabhängig von der verwendeten Programmiersprache bzw. dem verwendeten Datenbankmanagementsystem beschrieben.

Im Falle von SW-Modulen werden die Anweisungen der jeweiligen Programmiersprache in Pseudocode-Anweisungen oder Konstrukte einer Spezifikationssprache transformiert und in dem Teilprodukt "SW-Entwurf.SW-Modul-Beschreibung" dokumentiert.

Im Falle von Datenbanken werden die in der Datendefinitionssprache des jeweiligen Datenbankmanagementsystems vorliegenden Beschreibungen in die Schemadefinitionen der Datenbanken und Beschreibungen der Indizes umgesetzt und in dem Teilprodukt "SW-Entwurf.Datenbankbeschreibung" dokumentiert.

Die Beschreibungen der SW-Module und Datenbanken liefern die entwurfsbezogenen Angaben für die Betriebsinformationen. Sie bilden die Basis für Angaben zu Anwendung und Betrieb und zu Fehlerfällen bei Nutzung der Anwenderfunktionen (Informationen zum Anwendungshandbuch), zu den Diagnosemöglichkeiten (Informationen zum Diagnosehandbuch) und zu Initialisierung, Terminierung und Überwachung des Betriebs (Informationen zum Betriebshandbuch).


RE 3.7: Datenkatalog erstellen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.7	Datenkatalog erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3.4	in Bearb.		SW-Architektur. Modularisierung/Datenbankentwurf		—	—
RE 3.6	in Bearb.		SW-Entwurf.SW-Modul- Beschreibung bzw. SW- Entwurf.Datenbankbeschreibung		—	—
—	—		Datenkatalog		RE 3.8, RE 4.2	in Bearb.
Abwicklung

In dieser Aktivität werden auf der Grundlage der SW-Architektur und des SW-Entwurfs Informationen über die in den SW-Einheiten benutzten Daten (Einzeldaten und komplexe Gebilde) gesammelt und dokumentiert. Die Informationen können manuell, besser jedoch durch ein Werkzeug unterstützt, gesammelt und dokumentiert werden. Die Ergebnisse dieser Aktivität werden in dem Produkt "Datenkatalog" dokumentiert


RE 3.8: Technische Anforderungen beschreiben
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.8	Technische Anforderungen beschreiben

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.6	in Bearb.		Betriebsinformationen		RE 3.9	in Bearb.
RE 3.7	in Bearb.		Datenkatalog		—	—
—	—		Technische Anforderungen		Extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden die funktionalen Anforderungen an die SW-Einheit aus softwaretechnischer Sicht beschrieben. Grundlagen für die Beschreibung sind die Implementierungsdokumente (SW-Modul) bzw. die SW-Module und die Implementierungsdokumente (Datenbank) bzw. die Datenbanken sowie der Datenkatalog.

Ausgangspunkt für die Ermittlung sind die Unterprogramme der tiefsten Aufrufhierarchieebene. Sie werden unter dem Gesichtspunkt ihres Ein- und Ausgabeverhaltens softwaretechnisch beschrieben. Dabei ist zu unterscheiden zwischen dem Verhalten im Normal- und im Ausnahmefall.

Durch Zusammenfassung dieser Funktionen auf der SW-Modulebene entstehen SW-Module verschiedener Zielrichtungen wie Steuerungsmodule, Gateway-Module, Funktionsmodule, Nutzeroberflächenmodule oder Dienstleistungsmodule.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Technische Anforderungen" dokumentiert.

Die Beschreibung der Funktionen fließt auch in die Informationen zum Anwendungshandbuch ein, die Beschreibung der Ausnahme- und Fehlerbehandlungen in die Informationen zum Diagnosehandbuch. Weitere Informationen, die für Übernahme, Einführung und Betrieb des Systems relevant sind, die aber keinem dieser Teilprodukte zugeordnet werden können, werden in dem Teilprodukt "Sonstige Einsatzinformationen" dokumentiert.


RE 3.9: SW-Integration spezifizieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.9	SW-Integration spezifizieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3.4	in Bearb.		SW-Architektur. Modularisierung/Datenbankentwurf		—	—
RE 3.5	akzeptiert		Schnittstellenbeschreibung		—	—
RE 3.8	in Bearb.		Betriebsinformationen		RE 3.10	in Bearb.
—	—		Integrationsplan		RE 3.10	in Bearb.
Abwicklung

In dieser Aktivität werden Vorschriften und Regelungen für den Zusammenbau der SW-Einheit aus SW-Modulen und Datenbanken aus technischer Sicht festgelegt. Die Ergebnisse dieser Aktivität werden in dem Produkt "Integrationsplan" dokumentiert.

Der Integrationsplan wird im Hinblick auf Termine, Betriebs- und Hilfsmittel, Werkzeuge, Personal, Schnittstellen und ähnliche Einflüsse in Absprache mit dem Projektmanagement erstellt. Im Integrationsplan werden die Konfigurierung der SW-Einheit und alle für die Integrationsaktivität benötigten Informationen festgeschrieben, und Informationen für den Integrationstest werden abgeleitet und festgehalten.

Die Arbeiten am Integrationsplan liefern auch weitere Angaben zu den Betriebsinformationen, z. B. über die Bereitstellung der Umgebungskomponenten, die Aufnahme und Beendigung des Betriebs oder die Installation und Konfiguration.


RE 3.10: Systemintegration spezifizieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 3	Wiedergewinnung der technischen Sicht

RE 3.10	Systemintegration spezifizieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3.2	in Bearb.		Systemarchitektur.Struktur des Systems		—	—
RE 3.5	akzeptiert		Schnittstellenbeschreibung		—	—
RE 3.9	in Bearb.		Integrationsplan		RE 6.1, RE 7.1,  QS 2, extern *)	vorgelegt
RE 3.9	in Bearb.		Betriebsinformationen		RE 7.3	in Bearb.
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird festgelegt, wie die in der Systemarchitektur beschriebenen Elemente zum System zu integrieren sind. Die anzuwendenden Strategien, die durchzuführenden Maßnahmen, die eventuellen Restriktionen und Abhängigkeiten sowie die notwendigen Betriebs- und Hilfsmittel müssen definiert werden. Aus den Angaben zur Integration werden Angaben zu Installation und Betrieb, zur Systemumgebung und zu den SW- und HW-Einheiten abgeleitet. Die Informationen zum Betriebshandbuch, Anwendungshandbuch und Diagnosehandbuch sowie die sonstigen Einsatzinformationen werden auf dieser Grundlage fortgeschrieben.

Die Ergebnisse dieser Aktivität werden im Produkt "Integrationsplan" und in den "Betriebsinformationen" dokumentiert.


RE 4: Wiedergewinnung der fachlichen Sicht
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 4	Wiedergewinnung der fachlichen Sicht

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)			weitere Informationen **)		—	—
RE 1	akzeptiert		Anwenderbedarf		—	—
—	—		Anwenderforderungen		RE 5, RE 8, extern *)	vorgelegt
RE 3	in Bearb.		Datenkatalog		RE 5, extern *)	vorgelegt
*)	Auftraggeber

**)	vorhandene System- und Softwaredokumentation (Der Quellcode eignet sich als Grundlage für diese Aktivität nur dann, wenn er aus fachlicher Sicht kommentiert ist oder wenn der ursprüngliche Entwickler der Software zur Verfügung steht und die Beziehungen zwischen Quellcode und fachlicher Sicht herstellen kann. Da dies im allgemeinen nicht der Fall sein dürfte, wird auf die explizite Erwähnung des Quellcodes als Hilfsmittel bei der Wiedergewinnung der fachlichen Sicht im folgenden verzichtet.)

Abwicklung

In dieser Aktivität werden durch die Auswertung fachlicher Informationen die Anforderungen wiedergewonnen, die das System aus fachlicher Sicht erfüllt. Der Datenkatalog wird um die Beschreibung der Daten aus fachlicher Sicht ergänzt.


RE 4.1: Anwenderforderungen wiedergewinnen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 4	Wiedergewinnung der fachlichen Sicht

RE 4.1	Anwenderforderungen wiedergewinnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		weitere Informationen **)		—	—
RE 1.5	akzeptiert		Anwenderbedarf		—	—
—	—		Anwenderforderungen		RE 4.2, RE 5.1, RE 5.2, RE 8.2, RE 9, extern *)	vorgelegt
*)	Auftraggeber

**)	vorhandene System- und Softwaredokumentation und alle weiteren verfügbaren Informationen

Abwicklung

In dieser Aktivität werden die Anforderungen wiedergewonnen, die das System (bzw. die SW-Einheit, falls der Auftragsgegenstand eine einzelne SW-Einheit ist) aus fachlicher Sicht erfüllt.

Da es im allgemeinen nicht möglich sein wird, die benötigten Informationen aus dem Quellcode abzuleiten, ist es notwendig, die Informationen durch die Auswertung aller zur Verfügung stehenden fachlichen Informationsquellen zu gewinnen. Dies kann durch das Studium zur Verfügung stehender Dokumente, die Informationen über die fachliche Sicht auf das System enthalten, und durch die Befragung von Trägern fachlichen Wissens erfolgen.

Ziel der Auswertung ist es, die fachliche Strukturierung der Funktion des Systems aus Anwendersicht zu gewinnen, wobei die Gesamtfunktion des Systems im Sinne von "Geschäftsprozessen" zu beschrei-ben ist, die in "Bereiche" (z. B. "Mailing und Kommunikation", "Daten- und Dokumentenhaltung", "IT-Sicherheit", "Mensch-Maschine-Schnittstelle" oder "Bürofunktionen") unterteilt werden.

Die Ergebnisse dieser Aktivität werden im Produkt "Anwenderforderungen" dokumentiert.


RE 4.2: Datenkatalog vervollständigen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 4	Wiedergewinnung der fachlichen Sicht

RE 4.2	Datenkatalog vervollständigen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 4.1	akzeptiert		Anwenderforderungen		—	—
RE 3.7	in Bearb.		Datenkatalog		RE 5.2, extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird der Datenkatalog vervollständigt, indem er um Beschreibungen der Daten aus fachlicher Sicht ergänzt wird. Zu solchen Ergänzungen gehören beispielsweise die Bezeichnung der Daten in Langform oder die physikalische Einheit und Normierung der Daten.

Die Ergebnisse dieser Aktivität werden in dem Produkt "Datenkatalog" dokumentiert.


RE 5: Abbildung der fachlichen auf die technische Sicht
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 5	Abbildung der fachlichen auf die technische Sicht

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		RE 6, extern *)	vorgelegt
RE 2	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		RE 6, extern *)	vorgelegt
RE 3	in Bearb.		Systemarchitektur		Extern *)	vorgelegt
RE 3	in Bearb.		SW-Architektur		Extern *)	vorgelegt
RE 3	in Bearb.		SW-Entwurf		Extern *)	vorgelegt
RE 4	akzeptiert		Datenkatalog		—	—
RE 4	akzeptiert		Anwenderforderungen		—	—
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird die Verfolgbarkeit der Anforderungen zur System- und SW-Architektur und zum SW-Entwurf hergestellt. Der Quellcode wird unter fachlichen Gesichtspunkten rekommentiert.


RE 5.1: Fachliche Funktionseinheiten technischen Funktionseinheiten zuordnen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 5	Abbildung der fachlichen auf die technische Sicht

RE 5.1	Fachliche Funktionseinheiten technischen Funktionseinheiten zuordnen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		—	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		—	—
RE 3.2	in Bearb.		Systemarchitektur.Struktur des Systems		—	—
RE 3.4	in Bearb.		SW-Architektur.Modularisierung/ Datenbankentwurf		—	—
RE 4.1	akzeptiert		Anwenderforderungen		—	—
—	—		Systemarchitektur.Anforderungs- zuordnung		RE 5.1	in Bearb.
—	—		Systemarchitektur		RE 9, extern *)	vorgelegt
—	—		SW-Architektur. Anforderungszuordnung		RE 5.1	in Bearb.
—	—		SW-Architektur		RE 9, extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden die Beziehungen aufgezeigt, die zwischen den Funktionseinheiten der fachlichen Sicht und den Funktionseinheiten der technischen Sicht bestehen.

Diese Zuordnung kann beispielsweise gewonnen werden, indem der Quellcode auf geeignete Weise temporär instrumentiert, d. h. um zusätzliche Anweisungen zur Sammlung von Informationen erweitert wird, und aus dem instrumentierten Quellcode lauffähige Software erzeugt wird. Führt nun der Nutzer der Software bestimmte fachliche Aufgaben unter Anwendung der instrumentierten Software aus, so läßt sich ermitteln, welche technischen Funktionseinheiten an der Ausführung einer fachlichen Aufgabe beteiligt waren.

Die Ergebnisse dieser Aktivität dienen dazu, die Verfolgbarkeit der Anforderungen herzustellen. Sie werden in den Teilprodukten "Systemarchitektur.Anforderungszuordnung" und "SW-Architektur.
Anforderungszuordnung" dokumentiert.


RE 5.2: Rekommentierung
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 5	Abbildung der fachlichen auf die technische Sicht

RE 5.2	Rekommentierung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 2.3	in Bearb.		Implementierungsdokumente (SW-Modul) / SW-Modul		RE 6.1	—
RE 2.3	in Bearb.		Implementierungsdokumente (Datenbank) / Datenbank		RE 6.1	—
RE 3.6	in Bearb.		SW-Entwurf.SW-Modul- Beschreibung bzw. SW- Entwurf.Datenbankbeschreibung		RE 5.2	in Bearb.
RE 4.1	akzeptiert		Anwenderforderungen		—	—
RE 4.2	akzeptiert		Datenkatalog		—	—
—	—		SW-Entwurf		Extern *)	vorgelegt
—	—		SW-Modul		RE 6.1	vorgelegt
—	—		Datenbank		RE 6.1	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird der verbesserte Quellcode auf der Grundlage der wiedergewonnenen fachlichen Sicht auf die Software und der nunmehr hergestellten Anforderungsverfolgbarkeit unter fachlichen Gesichtspunkten und unter Berücksichtigung des überarbeiteten Datenkatalogs rekommentiert.

Die Ergebnisse dieser Aktivität werden in den Produkten "SW-Entwurf", "Implementierungsdokumente (SW-Modul)" bzw. "SW-Modul" und "Implementierungsdokumente (Datenbank)" bzw. "Datenbank" dokumentiert.

Abschließend werden die SW-Module kompiliert und die Datenbanken erzeugt.


RE 6: SW-Integration
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 6	SW-Integration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3	akzeptiert		Integrationsplan		—	—
RE 5	akzeptiert		Implementierungsdokumente (SW-Modul)		—	—
RE 5	akzeptiert		Implementierungsdokumente (Datenbank)		—	—
RE 5	akzeptiert		SW-Modul		—	—
RE 5	akzeptiert		Datenbank		—	—
—	—		Implementierungsdokumente (SW-Einheit)		RE 7, extern *)	vorgelegt
—	—		SW-Einheit		RE 7	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden die SW-Module und Datenbanken zur SW-Einheit integriert. Bei der Integration wird entsprechend den Regelungen im Integrationsplan vorgegangen.


RE 6.1: Zur SW-Einheit integrieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 6	SW-Integration

RE 6.1	Zur SW-Einheit integrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3.10	akzeptiert		Integrationsplan		—	—
RE 5.2	akzeptiert		Implementierungsdokumente (SW-Modul)		—	—
RE 5.2	akzeptiert		Implementierungsdokumente (Datenbank)		—	—
RE 5.2	akzeptiert		SW-Modul		—	—
RE 5.2	akzeptiert		Datenbank		—	—
—	—		Implementierungsdokumente (SW-Einheit)		RE 6.2	in Bearb.
—	—		SW-Einheit		RE 6.2	in Bearb.
Abwicklung

In dieser Aktivität werden die SW-Module und Datenbanken der SW-Einheit und möglicherweise auch Querschnittsmodule, die in anderen SW-Einheiten verwendet werden, integriert, was nach unterschiedlichen Vorgehensweisen erfolgen kann, die im Integrationsplan festgelegt sind. Die sich ergebende SW-Einheit muß frei von Platzhaltern sein.


RE 6.2: Selbstprüfung der SW-Einheit durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 6	SW-Integration

RE 6.2	Selbstprüfung der SW-Einheit durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 6.1	in Bearb.		Implementierungsdokumente (SW-Einheit)		RE 7.1, extern *)	vorgelegt
RE 6.1	in Bearb.		SW-Einheit		RE 7.1	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden vom Entwickler Selbstprüfungen der SW-Einheit durchgeführt. Bei den Selbstprüfungen werden zunächst die Prüfvoraussetzungen geschaffen, z. B. Installation des Prüfgegenstands in der Prüfumgebung und Generierung der benötigten Prüffälle. Nach der Durchführung der Prüfung erfolgt die Auswertung der Prüfergebnisse, die den weiteren Verlauf der Reverse-Engineering-Maßnahme bestimmt. Sofern die Prüfung beanstandungsfrei war, wird der Prüfgegenstand zur formellen Produktprüfung an QS weitergegeben, ansonsten sind Wiederholungen von RE-Aktivitäten erforderlich, die mit einer erneuten Selbstprüfung abgeschlossen werden.

Empfehlung

Zum Umfang der Selbstprüfung der SW-Einheit sollten insbesondere gehören:

−	Funktionsprüfung der SW-Einheit,

−	Prüfung der Zuverlässigkeit, der Effizienz und des Echtzeitverhaltens der SW-Einheit,

−	Prüfung der Benutzbarkeit, Änderbarkeit und Übertragbarkeit,

−	Prüfung der SW-internen Schnittstellen zwischen SW-Modulen, Datenbanken und Prozessen,

−	Prüfung der SW-externen, d. h. der systeminternen Schnittstellen.


RE 7: Systemintegration
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 7	Systemintegration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		HW-Einheit		—	—
Extern *)	—		Nicht-IT-Anteil		—	—
RE 3	akzeptiert		Integrationsplan		—	—
RE 3	in Bearb.		Betriebsinformationen		RE 8, extern *)	vorgelegt
RE 6	akzeptiert		Implementierungsdokumente (SW-Einheit)		—	—
RE 6	akzeptiert		SW-Einheit		—	—
—	—		System (installierbar)		RE 8, extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

Das System wird entsprechend den im Integrationsplan getroffenen Regelungen aus SW-Einheiten, HW-Einheiten und Nicht-IT-Anteilen integriert, einer Selbstprüfung unterzogen und als installierbares System bereitgestellt.


RE 7.1: Zum System integrieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 7	Systemintegration

RE 7.1	Zum System integrieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		HW-Einheit		—	—
Extern *)	—		Nicht-IT-Anteil		—	—
RE 3.10	akzeptiert		Integrationsplan		—	—
RE 6.2	akzeptiert		Implementierungsdokumente (SW-Einheit)		—	—
RE 6.2	akzeptiert		SW-Einheit		—	—
—	—		System		RE 7.2	in Bearb.
*)	Auftraggeber

Abwicklung

Die in der Systemarchitektur spezifizierten SW-Einheiten, HW-Einheiten und Nicht-IT-Anteile werden zum System integriert. Es wird entsprechend dem Integrationsplan vorgegangen, in dem die durchzuführenden Integrationsmaßnahmen beschrieben sind.


RE 7.2: Selbstprüfung des Systems durchführen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 7	Systemintegration

RE 7.2	Selbstprüfung des Systems durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 7.1	in Bearb.		System		RE 7.3	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden vom Entwickler Selbstprüfungen des Systems durchgeführt. Bei den Selbstprüfungen werden zunächst die Prüfvoraussetzungen geschaffen, z. B. Installation des Prüfgegenstands in der Prüfumgebung und Generierung der benötigten Prüffälle. Nach der Durchführung der Prüfung erfolgt die Auswertung der Prüfergebnisse, die den weiteren Verlauf der Reverse-Engineering-Maßnahme bestimmt. Sofern die Prüfung erfolgreich war, wird der Prüfgegenstand zur formellen Produktprüfung an QS weitergegeben, ansonsten sind Wiederholungen von RE-Aktivitäten erforderlich, die mit einer erneuten Selbstprüfung abgeschlossen werden.

Empfehlung

Zum Umfang der Selbstprüfung von Systemen sollte insbesondere gehören:

−	Prüfung gegen die Anwenderforderungen und die Systemarchitektur,

−	Prüfung zunächst in einer speziellen Systemprüfumgebung; die abschließende Systemprüfung muß in der operativen Einsatzumgebung durchgeführt werden,

−	Prüfung des technischen und funktionalen Zusammenwirkens der SW-Einheiten mit dem Hauptaugenmerk auf

−	Systembelastung hinsichtlich Effizienz und Robustheit,

−	Verhalten unter "worst-case"-Bedingungen,

−	Demonstration der Systemsicherheit,

−	typische Situationen und Bedingungen,

−	kritische Situationen und Funktionen.

Bei nicht unter realen Bedingungen prüfbaren Systemreaktionen müssen diese der realen Einsatzumgebung per Simulation so weit wie möglich angenähert werden.


RE 7.3: Produkt bereitstellen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 7	Systemintegration

RE 7.3	Produkt bereitstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 3.10	in Bearb.		Betriebsinformationen		RE 8.1, RE 8.3, RE 8.4, extern *)	vorgelegt
RE 7.2	akzeptiert		System		—	—
—	—		System (installierbar)		RE 8.3	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden zur Unterstützung bei der Wiedereinführung des Systems die Betriebsinformationen vervollständigt und abgeschlossen und das System in installierbarer Form (d. h. auf geeigneten Datenträgern) zur Verfügung gestellt. Die Dokumentierung dieser Aktivität wird im V-Modell nicht geregelt.


RE 8: Wiedereinführung des Systems
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 8	Wiedereinführung des Systems

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 1	akzeptiert		Anwenderbedarf		—	—
RE 2	akzeptiert		Sachbericht "Messung des Quellcodes"		—	—
RE 4	akzeptiert		Anwenderforderungen		—	—
RE 7	akzeptiert		Betriebsinformationen		—	—
RE 7	akzeptiert		System (installierbar)		—	—
—	—		SWPÄ-Konzept		Extern *)	vorgelegt
—	—		System (installiert und in Betrieb)		Extern *)	—
*)	Auftraggeber

Abwicklung

In dieser Aktivität wird das überarbeitete System beim Auftraggeber installiert und wieder in Betrieb genommen sowie das SWPÄ-Konzept erarbeitet.


RE 8.1: Beitrag zur Wiedereinführungsunterstützung leisten
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 8	Wiedereinführung des Systems

RE 8.1	Beitrag zur Wiedereinführungsunterstützung leisten

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 7.3	akzeptiert		Betriebsinformationen		—	—
*)	Auftraggeber

Abwicklung

Zur Unterstützung der Wiedereinführung des Systems sind folgende Maßnahmen erforderlich:

−	Die Durchführung aller notwendigen Infrastrukturmaßnahmen ist abzuschließen.

−	Die Durchführung aller notwendigen Ausbildungsmaßnahmen ist abzuschließen.

−	Das für die Nutzung erforderliche Personal ist auszuwählen und bereitzustellen.

−	Die Festlegung der Aufbau- und Ablauforganisation für die Nutzung ist ebenso abzuschließen wie die Einarbeitung der künftigen Arbeitsabläufe in die entsprechenden Regelungen des Anwenders.

−	Es sind alle Maßnahmen zu definieren und zu planen, die für die Wiedereinführung des Systems in die Nutzung erforderlich sind.

Die Dokumentierung dieser Maßnahmen ist im V-Modell nicht geregelt. Je nach den Erfordernissen sind separate Dokumente wie Infrastrukturkonzept, Ausbildungskonzept, Organisationskonzept, Überleitungsplan usw. zu erstellen.


RE 8.2: SWPÄ-Konzept erstellen
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 8	Wiedereinführung des Systems

RE 8.2	SWPÄ-Konzept erstellen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 1.5	akzeptiert		Anwenderbedarf		—	—
RE 2.5	akzeptiert		Sachbericht "Messung des Quellcodes"		—	—
RE 4.1	akzeptiert		Anwenderforderungen		—	—
—	—		SWPÄ-Konzept		RE 8.3, extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

In dieser Aktivität werden alle organisatorischen und technischen Maßnahmen für die künftige SWPÄ während des Betriebs festgelegt. Zunächst muß die SWPÄ-Strategie entschieden werden, z. B. ob und gegebenenfalls welche Anteile der SWPÄ nach extern vergeben werden sollen. Geeignete Grundlagen für diese Festlegungen sind sowohl das Produkt "Anwenderbedarf" als auch das Produkt "Anwenderforderungen", aber auch der Sachbericht "Messung des Quellcodes". Für das SWPÄ-Konzept sind zu berücksichtigen:

−	die erforderliche SWPÄ-Organisation (Aufbau und Strategie),

−	die notwendigen personellen Ressourcen (temporär/permanent, erforderliche Kenntnisse),

−	die Verteilung von Kompetenzen und Verantwortlichkeiten innerhalb der SWPÄ-Organisation,

−	die Beschreibung des Prozesses zur Durchführung der SWPÄ,

−	die SWPÄ von Fertigprodukten,

−	die technischen Einrichtungen, die für die SWPÄ erforderlich sind (z. B. Entwicklungs- und Prüfumgebungen).


RE 8.3: System installieren
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 8	Wiedereinführung des Systems

RE 8.3	System installieren

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 7.3	akzeptiert		System (installierbar)		—	—
RE 7.3	akzeptiert		Betriebsinformationen		—	—
RE 8.2	akzeptiert		SWPÄ-Konzept		—	—
—	—		System (installiert)		RE 8.4	vorgelegt
Abwicklung

Zur Installation des Systems gehört das Zusammenfügen und Installieren der einzelnen Bestandteile des Systems (Hardware und Software) sowie die Herstellung des betriebsbereiten Zustandes.

Für das Betriebs- und SWPÄ-Personal ist eine Einweisung am installierten System durchzuführen. Neben der Einweisung in die Handbücher und technischen Unterlagen sind typische Abläufe des Systems zu demonstrieren, wobei sowohl Normal- als auch Ausnahmesituationen zu berücksichtigen sind.


RE 8.4: Wiederinbetriebnahme
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 8	Wiedereinführung des Systems

RE 8.4	Wiederinbetriebnahme

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
RE 7.3	akzeptiert		Betriebsinformationen		—	—
RE 8.3	akzeptiert		System (installiert)		—	—
—	—		System (installiert und in Betrieb)		Extern *)	vorgelegt
*)	Auftraggeber

Abwicklung

Ziel dieser Aktivität ist es, das installierte IT-System wieder in Betrieb zu nehmen und es für die Abnahmeprüfung vorzubereiten sowie den reibungslosen Übergang zur Arbeit mit dem überarbeiteten IT-System sicherzustellen.

Zur Unterstützung der Wiederinbetriebnahme sind folgende Maßnahmen durchzuführen:

−	Auswahl und Bereitstellung von Wiederinbetriebnahmedokumentation, Repository-Daten (Datenbanksysteme), Startparametern,

−	Einlesen der Daten,

−	Technische Wiederinbetriebnahme,

−	Registrierung aller für die Wiederinbetriebnahme verwendeten Daten (Parameter, Dateien usw.),

−	Personaleinweisung.

Alle Datenbestände, die im überarbeiteten System benötigt werden, müssen aus dem Altsystem übernommen werden. Erforderliche Ersterfassungen von Daten sind durchzuführen.

Gegebenenfalls müssen zur Sicherstellung eines einwandfreien Betriebs für eine bestimmte Zeitspanne die alten Arbeitsabläufe bzw. das alte System und das neue System parallel betrieben werden.

Die ordnungsgemäße Ausmusterung des Altsystems (z. B. Beenden von Lizenzen, Löschen der Datenbestände, Entsorgung/Abgabe des Altsystems usw.) ist gemäß den gesetzlichen Bestimmungen durchzuführen.


RE 9: Ermittlung wiederverwendungsfähiger Softwarebausteine
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.2	Reverse-Engineering-Aktivitäten

RE 9	Ermittlung wiederverwendungsfähiger Softwarebausteine

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
Extern *)	—		weitere Informationen **)		—	—
RE 4.1	akzeptiert		Anwenderforderungen		—	—
RE 5.1	akzeptiert		Systemarchitektur		—	—
RE 5.1	akzeptiert		SW-Architektur		—	—
—	—		Sachbericht "Wiederverwendungsfähige Softwarebausteine"		Extern *)	vorgelegt
*)	Auftraggeber

**)	Gebietsmodell

Abwicklung

In dieser Aktivität werden auf der Grundlage der Anwenderforderungen jene Softwarebausteine ermittelt, die potentiell für Systeme des Anwendungsgebiets, zu dem das vorliegende System gehört, wiederverwendbar sind. Dazu wird ein Abgleich zwischen der Menge der fachlichen Anforderungen an das vorliegende System und der Menge der in einem spezifischen Modell formulierten Anforderungen an Systeme des betreffenden Anwendungsgebiets (Gebietsmodell) durchgeführt. Potentiell wiederverwendbare Anforderungen zeigen sich in der Schnittmenge dieser beiden Anforderungsmengen.

Da in vorausgehenden Aktivitäten (vgl. Aktivität RE 5) die Verfolgbarkeit der fachlichen Anforderungen zur System- und SW-Architektur hergestellt wurde, ist es möglich, diejenigen Architekturelemente zu benennen, die die potentiell wiederverwendbaren Anforderungen realisieren.

Die Auflistung der potentiell wiederverwendbaren Anforderungen und Verweise auf ihre technische Realisierung werden in dem Sachbericht "Wiederverwendungsfähige Softwarebausteine" dokumentiert.

Empfehlung

Da die Erstellung eines Gebietsmodells mit einem erheblichen Aufwand verbunden ist, sollte diese Aktivität nur dann durchgeführt werden, wenn ein Gebietsmodell für das betreffende Anwendungsgebiet bereits existiert.


Reverse-Engineering-Produkte
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

Im folgenden wird eine Übersicht über alle Produkte gegeben, die beim Reverse Engineering erzeugt werden. Wie aus dem Regelungsteil des V-Modells bekannt, wird aus Gründen der Übersichtlichkeit für jedes Produkt und Teilprodukt ein Produktpräfix (z. B. Afo_ für Anwenderforderungen) verwendet, das nur Erläuterungscharakter hat und als Orientierungshilfe in diesem Abschnitt dient. Es wird zwischen den folgenden drei Produktkategorien unterschieden:

−	Produkte, die vollständig den aus dem Submodell SE bekannten Produkten entsprechen:

−	Schnittstellenübersicht (SSÜb_),

−	Schnittstellenbeschreibung (SSB_),

−	Integrationsplan (IntPl_),

−	SWPÄ-Konzept (SWPÄK_),

−	Datenkatalog (DatK_),

−	Implementierungsdokumente (ImplD_),

−	Betriebsinformationen mit Informationen zum Anwendungshandbuch (AHb_), Informationen zum Diagnosehandbuch (DiagHb_), Informationen zum Betriebshandbuch (BetrHb_) und Sonstigen Einsatzinformationen (EinInf_).

Die Produkte dieser Kategorie werden im folgenden nicht mehr erwähnt.

−	Produkte, die aus dem Submodell SE bekannt sind, bei denen jedoch einzelne Teilprodukte entfallen:

−	Anwenderforderungen (AFo_),

−	Systemarchitektur (SysArc_),

−	Technische Anforderungen (TAnf_),

−	SW-Architektur (SwArc_),

−	SW-Entwurf (SwEnt_).

Für die Produkte dieser Kategorie wird im folgenden lediglich aufgeführt, welche Teilprodukte entfallen.

−	Produkte, die ausschließlich beim Reverse Engineering entstehen und zu denen es keine Entsprechung im Submodell SE gibt:

−	Anwenderbedarf (ABed_),

−	Sachbericht "Wiederverwendungsfähige Softwarebausteine" (SbWv_),

−	Sachbericht "Messung des Quellcodes" (SbMes_).

Diese Produkte werden im folgenden detailliert hinsichtlich ihres Inhalts beschrieben.

Alle genannten Produkte haben als Vorspann den aus dem Regelungsteil des V-Modells ("Produktmuster") bekannten Gliederungspunkt "1 Allgemeines". Er wird in den nachfolgenden Darstellungen zu den Produkten nicht aufgeführt. Deshalb beginnen die Kapitelnumerierungen mit dem Kapitel 2.


Anwenderforderungen (AFo_ / AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.1	Anwenderforderungen (AFo_)

Afo_2  Ist-Aufnahme und Ist-Analyse

entfällt

Afo_3  IT-Sicherheitsziel

entfällt

Afo_4  Bedrohungs- und Risikoanalyse

entfällt

Afo_5  IT-Sicherheit

entfällt

Afo_6  Fachliche Anforderungen

Afo_6.1  Grobe Systembeschreibung

Afo_6.2  Organisatorische Einbettung

Afo_6.3  Nutzung

Afo_6.4  Kritikalität des Systems

entfällt

Afo_6.5  Externe Schnittstellen

Afo_6.6  Beschreibung der Funktionalität

Afo_6.7  Qualitätsforderungen

entfällt

Afo_7  Randbedingungen

entfällt


Systemarchitektur (SysArc_ / AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.2	Systemarchitektur (SysArc_)

SysArc_2  Struktur des System

SysArc_2.1  Darstellung der technischen Systemarchitektur

SysArc_2.1.1  Technischer Aufbau des Systems

SysArc_2.1.2  Identifikation der Schnittstellen

SysArc_2.1.3  Anforderungszuordnung

SysArc_2.2  Erläuterung der Zusammenarbeit der technischen Elemente

SysArc_3  Realisierung

entfällt

SysArc_4  IT-Sicherheitskonzept

entfällt

SysArc_5  IT-Sicherheitsmodell

entfällt


Technische Anforderungen (TAnf_ / AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.3	Technische Anforderungen (TAnf_)

Tanf_2  Allgemeine Anforderungen

Tanf_3  Technische Anforderungen an das Gesamtsystem

Gliederung: siehe unten

Tanf_4  Technische Anforderungen an Segmente

entfällt

Tanf_5  Technische Anforderungen an SW-Einheiten

Gliederung je SW-Einheit: siehe unten

Für jedes Element x (= System oder SW-Einheit) der Systemarchitektur sind die Technischen Anforderungen wie folgt zu spezifizieren:

TAnf_x.1  Identifikation des Elements

TAnf_x.2  Gesamtfunktion des Elements

TAnf_x.3  Technische Anforderungen an die Schnittstellen

Tanf_x.3.1  Technische Anforderungen an die Nutzerschnittstelle

Tanf_x.3.2  Technische Anforderungen an andere Schnittstellen

TAnf_x.4  Qualitätsforderungen

entfällt

TAnf_.x.5  Technische Anforderungen an die Entwicklungs- und SWPÄ-Umgebung

entfällt


SW-Architektur (SwArc_ / AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.4	SW-Architektur (SwArc_)

SwArc_2  Lösungsvorschläge

entfällt

SwArc_3  Modularisierung/Datenbankentwurf

SwArc_3.1  Übersicht über die SW-Module, Prozesse und Datenbanken

SwArc_3.2  Einzelbeschreibungen

SwArc_3.2.m  SW-Modul/Prozeß/Datenbank (m)

SwArc_3.3  Dynamisches Ablaufmodell

SwArc_3.4  Kritikalität der SW-Module/Prozesse/Datenbanken

entfällt

SwArc_3.5  Sonstige Entwurfsentscheidungen

entfällt

SwArc_4  Schnittstellen

SwArc_4.1  Externe Schnittstellen der SW-Einheit

SwArc_4.2  Interne Schnittstellen der SW-Einheit

SwArc_5  Anforderungszuordnung


SW-Entwurf (SwEnt_ / AU250/3 - RE)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.5	SW-Entwurf (SwEnt_)

SwEnt_2  SW-Modul-Beschreibung

SwEnt_2.1  Charakterisierung der Aufgabe

SwEnt_2.2  Umgebung

SwEnt_2.3  Schnittstellen

SwEnt_2.3.1  Passiv-Aktiv-Aufrufmatrix

SwEnt_2.3.2  Eingabe-/Ausgabedaten

SwEnt_2.3.3  Weitere Schnittstellen

SwEnt_2.4  Realisierung des SW-Moduls

SwEnt_2.5  Lokale Daten

SwEnt_2.6  Ausnahmeverhalten

SwEnt_3  Kenngrößen

entfällt

Alternativ für den Entwurf einer Datenbank:

SwEnt_2  Datenbankbeschreibung

SwEnt_2.1  DBMS-Name

SwEnt_2.2  Schemadefinition

SwEnt_3  Kenngrößen

entfällt


Anwenderbedarf (ABed_)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.6	Anwenderbedarf (ABed_)

Im Produkt "Anwenderbedarf" werden der Ist- und der Soll-Zustand der zu bearbeitenden Software beschrieben. Es werden Möglichkeiten aufgezeigt, wie vom Ist- zum Soll-Zustand gelangt werden kann, und die Ergebnisse der Untersuchungen festgehalten, ob die geplante Reverse-Engineering-Maßnahme unter technischen und wirtschaftlichen Gesichtspunkten durchführbar ist.

Dieses Produkt existiert für das zu bearbeitende System. Handelt es sich bei der zu bearbeitenden Software um eine einzelne SW-Einheit, so existiert es auf der Ebene der SW-Einheit.

Abed_2  Ist-Aufnahme

Alle Informationen, die bei der Ist-Aufnahme aufgenommen werden konnten, werden an dieser Stelle aufgeführt. Möglich ist deren explizite Darstellung oder die Nennung der Fundstelle. Sinnvoll ist es, wenn eine geeignete Strukturierung der Informationen vorgenommen wird, indem beispielsweise  zwischen vorwiegend softwaretechnischen und vorwiegend fachlichen Informationen unterschieden wird, oder wenn zwischen dem Abstraktionsgrad der Informationen unterschieden wird. Hilfreich ist es auch, wenn die Beziehungen zwischen den ermittelten Informationen bereits aufgezeigt werden.

Abed_3  Ist-Analyse

Es werden die Schwachstellen im vorhandenen Quellcode und in der übrigen vorhandenen System- und Softwaredokumentation dargestellt. Soweit wie möglich werden auch die Ursachen für die Schwachstellen aufgezeigt.

Abed_4  Lösungsvorschläge

Es wird beschrieben, wie die bei der Ist-Analyse erkannten Schwachstellen behoben werden können.

Abed_5  Technische Durchführbarkeit

Es wird beschrieben, ob die grundlegenden technischen Voraussetzungen für die Durchführung der geplanten Reverse-Engineering-Maßnahme erfüllt werden. In Abhängigkeit vom Umfang der geplanten Maßnahme müssen die Fragen geklärt werden, ob der Quellcode vollständig verfügbar ist, ob aus dem Quellcode lauffähige Software erzeugt werden kann und ob fachliche Informationen in hinreichender Menge verfügbar sind.

Abed_6  Wirtschaftlichkeit

Es werden die Ergebnisse der Wirtschaftlichkeitsuntersuchung für die geplante Reverse-Engineering-Maßnahme dargestellt.

Eine feinere Untergliederung wird für das Produkt "Anwenderbedarf" nicht vorgegeben, weil damit nicht beabsichtigte Festlegungen hinsichtlich des methodischen Vorgehens bei den Teilaktivitäten getroffen würden.


Sachbericht ”Messung des Quellcodes” (SbMes_)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.7	Sachbericht "Messung des Quellcodes" (SbMes_)

Im Sachbericht "Messung des Quellcodes" werden die Planung, Spezifizierung und Durchführung sowie die Ergebnisse der Messung des vorhandenen und des verbesserten Quellcodes dargestellt. Zu den Ergebnissen der Messung gehören auch Aussagen darüber, welche der verbesserten Softwarebausteine im Rahmen einer sich an die Reverse-Engineering-Maßnahme anschließenden Forward-Engineering-Maßnahme weiterverwendet bzw. neuentwickelt werden sollten.

Dieses Produkt existiert für das zu bearbeitende System. Handelt es sich bei der zu bearbeitenden Software um eine einzelne SW-Einheit, so existiert es auf der Ebene der SW-Einheit.

SbMes_2  Meßplan

SbMes_2.1  Meßgegenstände

Die der Messung zu unterziehenden Meßgegenstände werden genannt.

SbMes_2.2  Aufgaben und Verantwortlichkeiten

Es wird für jede an der Messung beteiligte Organisationseinheit deren Verantwortlichkeit hinsichtlich der Messung kurz beschrieben. Zu unterscheiden ist zwischen ausführender, mitwirkender, beratender oder beaufsichtigender Beteiligung. Die einzelnen Messungen werden namentlich genannten Personen zugeordnet.

SbMes_2.3  Zeitplan

Es werden die Termine für die Vorbereitung und Durchführung der Messung der o. g. Meßgegenstände genannt.

SbMes_2.4  Ressourcen

Es wird beschrieben, welche Umgebung (Hardware, Software, DV-Betriebsmittel usw.) für die Messung benötigt wird.

SbMes_3  Meßspezifikation

Es wird beschrieben, welches Meßverfahren bei der Durchführung der Messung angewendet wird.

SbMes_4  Arbeitsanleitung

SbMes_4.1  Voraussetzungen

Es wird beschrieben, wie die Voraussetzungen für die Messung geschaffen werden und der geforderte Ausgangszustand für die Messung hergestellt wird (Vorbereitung der Meßumgebung, Datenträger, freier Speicherplatz usw.).

SbMes_4.2  Konfiguration

Es wird beschrieben, wie der Meßgegenstand zu konfigurieren und zu installieren ist und wie er mit der Meßumgebung in Verbindung steht.

SbMes_4.3  Durchführung

Es werden die einzelnen Schritte beschrieben, die bei der Durchführung der Messung auszuführen sind.

SbMes_4.4  Ergebnissicherung

Es wird beschrieben, welche Meßergebnisse wie zu dokumentieren sind (Papier, Datenträger o. ä.).

SbMes_4.5  Ergebnisauswertung

Es wird beschrieben, wie und unter welchen Gesichtspunkten und Bedingungen die Meßergebnisse ausgewertet werden.

SbMes_5  Messung des vorhandenen Quellcodes

für jeden Meßgegenstand m:

SbMes_5.m  Identifikation der Messung

SbMes_5.m.1  Meßobjekt

Es wird der Meßgegenstand eindeutig definiert.

SbMes_5.m.2  Angaben zur Durchführung

Es werden Angaben zum Durchführenden, zu Ort, Datum und Zeit der Messung gemacht.

SbMes_5.m.3  Ergebnisse

Die bei der Messung erzielten Ergebnisse werden festgehalten.

SbMes_6  Messung des verbesserten Quellcodes

für jeden Meßgegenstand m:

SbMes_6.m  Identifikation der Messung

SbMes_6.m.1  Meßobjekt

Es wird der Meßgegenstand eindeutig definiert.

SbMes_6.m.2  Angaben zur Durchführung

Es werden Angaben zum Durchführenden, zu Ort, Datum und Zeit der Messung gemacht.

SbMes_6.m.2  Ergebnisse

Die bei der Messung erzielten Ergebnisse werden festgehalten.

SbMes_7  Auswertung

Die für jeden Meßgegenstand bei der Messung des vorhandenen und des verbesserten Quellcodes ermittelten Ergebnisse werden einander tabellarisch gegenübergestellt.

SbMes_8  Weiterverwendungsfähige Softwarebausteine

Es wird dargestellt, welche Softwarebausteine sich auf Grund des jeweiligen Meßergebnisses dafür eignen, bei einer sich an die Reverse-Engineering-Maßnahme anschließenden Forward-Engineering-Maßnahme weiterverwendet zu werden. Jene Softwarebausteine, die hier nicht genannt werden, sollten bei einer Forward-Engineering-Maßnahme neuentwickelt werden.


Sachbericht ”Wiederverwendungsfähige Softwarebausteine” (SbWv_)
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.3	Reverse-Engineering-Produkte

RE.3.3.8	Sachbericht "Wiederverwendungsfähige Softwarebausteine" (SbWv_)

SbWv_2  Wiederverwendungsfähige Softwarebausteine

Es werden tabellarisch die durch den Abgleich mit dem Gebietsmodell ermittelten potentiell wiederverwendbaren Anforderungen dargestellt, wobei jeweils darauf verwiesen wird, durch welche technischen Funktionseinheiten die potentiell wiederverwendbaren Anforderungen realisiert werden.

Dieses Produkt existiert für das zu bearbeitende System. Handelt es sich bei der zu bearbeitenden Software um eine einzelne SW-Einheit, so existiert es auf der Ebene der SW-Einheit.


Überblick über Aktivitäten und entstehende Produkte
Teil 3	Vorgehensmodell / Handbuchsammlung

RE	Reverse Engineering

RE.3	Regelungen für Reverse Engineering

RE.3.4	Überblick über Aktivitäten und entstehende Produkte

RE 1	Erhebung des Anwenderbedarfs

RE 1.1	Ist-Aufnahme durchführen

RE 1.2	Ist-Analyse durchführen

RE 1.3	Lösungsvorschläge formulieren

RE 1.4	Technische Durchführbarkeit untersuchen

RE 1.5	Wirtschaftlichkeit untersuchen	⇒ Anwenderbedarf

RE 2	Durchführung softwaretechnischer Verbesserungen

RE 2.1	Vorhandenen Quellcode messen

RE 2.2	Remodularisierung / Restrukturierung

RE 2.3	Reformatierung	⇒ Implementierungsdokumente

RE 2.4	Verbesserten Quellcode messen

RE 2.5	Weiterverwendungsfähige SW-Bausteine
festlegen	⇒ Sachbericht "Messung des
Quellcodes"

RE 3	Wiedergewinnung der technischen Sicht

RE 3.1	Systemarchitektur wiedergewinnen

RE 3.2	Systeminterne und -externe Schnittstellen
wiedergewinnen	⇒ Systemarchitektur

RE 3.3	Prozeßentwurf wiedergewinnen

RE 3.4	SW-Architektur beschreiben	⇒ SW-Architektur

RE 3.5	SW-interne Schnittstellen beschreiben	⇒ Schnittstellenübersicht

⇒ Schnittstellenbeschreibung

RE 3.6	SW-Entwurf beschreiben	⇒ SW-Entwurf

RE 3.7	Datenkatalog erstellen	⇒ Datenkatalog

RE 3.8	Technische Anforderungen beschreiben	⇒ Technische Anforderungen

RE 3.9	SW-Integration spezifizieren

RE 3.10	Systemintegration spezifizieren	⇒ Integrationsplan

RE 4	Wiedergewinnung der fachlichen Sicht

RE 4.1	Anwenderforderungen wiedergewinnen	⇒ Anwenderforderungen

RE 4.2	Datenkatalog vervollständigen	⇒ Datenkatalog

RE 5	Abbildung der fachlichen auf die technische Sicht

RE 5.1	Fachliche Funktionseinheiten technischen	⇒ Systemarchitektur
Funktionseinheiten zuordnen	⇒ SW-Architektur

RE 5.2	Rekommentierung	⇒ SW-Entwurf

⇒ Implementierungsdokumente

⇒ SW-Modul bzw. Datenbank

RE 6	SW-Integration

RE 6.1	Zur SW-Einheit integrieren

RE 6.2	Selbstprüfung der SW-Einheit durchführen	⇒ Implementierungsdokumente

⇒ SW-Einheit

RE 7	Systemintegration

RE 7.1	Zum System integrieren

RE 7.2	Selbstprüfung des Systems durchführen

RE 7.3	Produkt bereitstellen	⇒ System

⇒ Betriebsinformationen

RE 8	Wiedereinführung des Systems

RE 8.1	Beitrag zur Wiedereinführungsunterstützung
leisten

RE 8.2	SWPÄ-Konzept erstellen	⇒ SWPÄ-Konzept

RE 8.3	System installieren

RE 8.4	Wiederinbetriebnahme	⇒ System

RE 9	Ermittlung wiederverwendungsfähiger SW-Bausteine	⇒ Sachbericht "Wiederverwen-
dungsfähige Softwarebausteine"


Einleitung
Teil 3	Vorgehensmodell / Handbuchsammlung

SEC	Anwendung des V-Modells und der ITSEC

SEC.1	Einleitung

In diesem Handbuch sollen die Aktivitäten und Produkte genannt werden, die für die Evaluation von Systemen relevant sind. Es wird beschrieben, was bei den einzelnen Aktivitäten speziell unter dem Aspekt Evaluation zu tun ist bzw. welche Inhalte bei den Produkten für die Evaluation erwartet werden.

Für die verschiedenen E-Stufen kann es unterschiedliche Anforderungen bei den einzelnen Aktivitäten und Produkten geben. Auch sind nicht alle Aktivitäten und Produkte stets für jede E-Stufe der ITSEC gefordert. Diese Abweichungen werden bei den einzelnen Aktivitäten und Produkten entsprechend vermerkt. Bei den Aktivitäten und Produkten wird außerdem vermerkt, zu welchem Evaluationsdokument ihre Ergebnisse beitragen können.

Bei nicht kommentierten Aktivitäten und Produkten konnte keine Relevanz für die Evaluation nach ITSEC festgestellt werden.


Erläuterungen zum Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SEC	Anwendung des V-Modells und der ITSEC

SEC.2	Erläuterungen zum Submodell SE

SE 1: System-Anforderungsanalyse

SE 1.1: Ist-Aufnahme/-Analyse durchführen

Falls bei einem vorhandenen System bereits Sicherheitsmaßnahmen existieren, müssen diese hinsichtlich eines neu vorgegebenen Sicherheitsziels und einer veränderten Einsatzumgebung analysiert und bewertet werden.

SE 1.2: Anwendungssystem beschreiben

Zusätzlich zu den operationellen Anforderungen an das System muß vom AG das Sicherheitsziel vorgegeben werden. Das Sicherheitsziel ist die Grundlage für die Erarbeitung der Sicherheitsanforderungen. Diese werden bei der Aktivität SE 1.6 "Bedrohung und Risiko analysieren" nach Durchführung einer Bedrohungs- und Risikoanalyse im Hinblick auf dieses Sicherheitsziel ermittelt.

Aufgrund der Sicherheitsanforderungen wird unter Berücksichtigung des tragbaren Restrisikos die angestrebte Stärke der Mechanismen für die Realisierung der Sicherheitsfunktionen und die angestrebte E-Stufe festgelegt.

SE 1.6: Bedrohung und Risiko analysieren

Auf der Basis der operationellen Anforderungen und im Hinblick auf das Sicherheitsziel, das erreicht werden soll, werden gemäß IT-Sicherheitshandbuch oder AU 248 die Bedrohungen festgestellt und die jeweiligen Risiken ermittelt. Es werden diejenigen Bedrohungen als relevant eingestuft, die ein nicht akzeptables Risiko (Eintrittswahrscheinlichkeit einer Bedrohung und Schadenshöhe) bergen.

Um diese als relevant eingestuften Bedrohungen abzuwehren, müssen geeignete Maßnahmen ergriffen werden. Solche Maßnahmen können IT-Maßnahmen sein, aber auch Maßnahmen administrativer, organisatorischer, personeller oder infrastruktureller Art. Die Gesamtheit dieser Maßnahmen bildet das Sicherheitskonzept. Die Entwicklung der Nicht-IT-Maßnahmen wird nicht weiter durch das V-Modell geregelt. Sie werden aber sehr wohl bei der Evaluation berücksichtigt, da sie zur Sicherheit des Systems beitragen.

Die IT-Maßnahmen werden realisiert durch Sicherheitsfunktionen. Diese Sicherheitsfunktionen benötigen eine bestimmte Vertrauenswürdigkeit, die sowohl durch die Stärke des Mechanismus als auch durch die Qualität ihrer Realisierung (E-Stufe) bestimmt wird. Die Bestimmung der Mechanismenstärke und der E-Stufe für die Sicherheitsfunktionen liegt außerhalb der Regelungen durch das V-Modell.

SE 1.5: System fachlich strukturieren

Bei der fachlichen Strukturierung des Systems werden die IT-Maßnahmen des Sicherheitskonzepts umgesetzt in Sicherheitsfunktionen, die den Bedrohungen entgegenwirken können. Diese Funktionen werden als "sicherheitsspezifische Funktionen" bezeichnet, da sie direkt zur Sicherheit des Systems beitragen. Diese Sicherheitsfunktionen, die zur Abwehr von Bedrohungen gewählt werden, können einer vordefinierten Funktionalitätsklasse der ITSEC entsprechen, können aber auch völlig frei definierte Sicherheitsfunktionen sein.

Die Sicherheitsfunktionalität ist abzugrenzen von der übrigen operationellen Funktionalität.

SE 2: System-Entwurf

SE 2.1: System technisch entwerfen

Neben den sicherheitsspezifischen Funktionen wird es auch solche Funktionen geben, deren korrektes Verhalten für die Sicherheitsfunktionen unerläßlich ist. Diese Funktionen tragen indirekt zur Sicherheit bei, wenn sich eine oder mehrere Sicherheitsfunktionen auf diese Funktionen verlassen. Deshalb werden sie als "sicherheitsrelevante Funktionen" bezeichnet.

Beim Entwurf des Systems ist darauf zu achten, daß sowohl die Sicherheitsfunktionen selbst als auch die sicherheitsrelevanten Funktionen von der Software, die als nicht sicherheitsrelevant angesehen wird, ausreichend abgegrenzt werden, indem die Anzahl der Schnittstellen so klein wie möglich gehalten wird. Die Notwendigkeit jeder Schnittstelle ist zu beschreiben und zu begründen. Es ist auch darauf zu achten, daß der Umfang des gesamten Sicherheitsanteils (sicherheitsspezifische und sicherheitsrelevante Funktionen), der Gegenstand der Evaluation ist, so klein wie möglich gehalten wird (Minimierung des vertrauenswürdigen Anteils).

Die Schnittstellen zur Einsatzumgebung sind exakt zu beschreiben.

SE 2.3: Realisierbarkeit untersuchen

Die Abgrenzbarkeit des sicherheitsrelevanten Teils vom nicht sicherheitsrelevanten Teil ist zu prüfen.

Die Machbarkeit der angestrebten E-Stufe ist zu prüfen. Ein Kriterium für die Realisierbarkeit einer hohen E-Stufe ist auch die erwartete Komplexität des Sicherheitsanteils.

Es sind aber auch Überlegungen bezüglich der Wirtschaftlichkeit einer vorgegebenen E-Stufe anzustellen. Die Untersuchungen, die durchzuführen sind, müssen unter Berücksichtigung des tragbaren Restrisikos die Kosten, die für eine bestimmte E-Stufe entstehen, abwägen gegen die möglichen Schäden, die bei Wirksamwerden der Bedrohungen eintreten.

SE 2.4: Anwenderforderungen zuordnen

Es ist der Nachweis zu erbringen, daß sämtliche Sicherheitsanforderungen im Sicherheitskonzept (IT- Maßnahmen und Nicht-IT-Maßnahmen) berücksichtigt werden. Das erleichtert u. a. die Feststellung des noch vorhandenen Restrisikos.

SE 2.6: System-Integration spezifizieren

Es muß spezifiziert werden, wie die Integration des sicherheitsrelevanten Teils, der begleitend oder später evaluiert werden soll, in den Teil, der nicht evaluiert werden soll, zu erfolgen hat.

SE 3: SW-/HW-Anforderungsanalyse

SE 3.1: Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren

Es ist zu prüfen, ob sich der sicherheitsrelevante Teil auf diese SW-/HW-Einheit auswirkt, d. h. ob bestimmte sicherheitsspezifische oder -relevante Funktionen in dieser SW-/HW-Einheit realisiert werden müssen.

SE 3.2: Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren

Falls sich sicherheitsspezifische oder -relevante Funktionen in dieser SW-/HW-Einheit befinden, muß eine exakte Schnittstellenbeschreibung zum restlichen sicherheitsspezifischen oder sicherheitsrelevanten Teil, der in anderen SW-/HW-Einheiten verstreut sein kann, vorliegen. Es muß das Zusammenwirken dieser Funktionen mit den anderen über diese Schnittstelle beschrieben werden.

SE 3.3: Anforderungen an die Funktionalität definieren

Es sind die Anforderungen an die Sicherheitsfunktionen und die dafür notwendigen Daten zu erstellen.

SE 3.4: Anforderungen an die Qualität der SW-/HW-Einheit definieren

Falls die SW-/HW-Einheit einen sicherheitsrelevanten Teil enthält, ist dieser mit der vorgegebenen E-Stufe zu realisieren.

SE 3.5: Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren

Die verschiedenen E-Stufen haben unterschiedliche Anforderungen an die Entwicklungsumgebung.

Anforderungen werden gestellt an den Einsatz von Methoden und Werkzeugen wie

−	die Methode der Spezifikation und die Spezifikationssprache,

−	die Programmiersprache und den eingesetzten Compiler,

−	das Konfigurationsmanagement und die Leistungsfähigkeit eines Werkzeugs zur Konfigurationskontrolle.

Forderungen werden auch gestellt bezüglich der Möglichkeit, innerhalb der Entwicklungsumgebung verschiedene Benutzer und Rollen unterscheiden zu können und deren Accountability sicherzustellen, um

−	Benutzer für Aktivitäten und Aktionen autorisieren zu können,

−	Rollentrennung zur Durchführung von Aktivitäten zu ermöglichen,

−	die Nachweisbarkeit von Aktivitäten und Aktionen während des Entwicklungsprozesses zu ermöglichen.

SE 4-SW: SW-Grobentwurf

SE 4.1-SW: SW-Architektur entwerfen

Diese Aktivität ist für alle E-Stufen erforderlich. Die Art der geforderten Darstellung ist für die verschiedenen E-Stufen unterschiedlich. Sie reicht von einer informellen Beschreibung bis zur Notwendigkeit einer formalen Notation.

Die Bedrohungs- und Risikoanalyse ist fortzuschreiben. Es ist zu untersuchen, ob durch die Verfeinerung neue Bedrohungen und Risiken auftreten.

Bei den Stufen E1 bis E3 wird eine informelle Beschreibung der Architektur gefordert.

Es gibt zwischen diesen drei E-Stufen allerdings unterschiedliche Anforderungen, wie präzise die Aufteilung in sicherheitsrelevante und andere Komponenten dargestellt und das Erreichen der Trennung beschrieben werden muß.

Bei den Stufen E4 bis E5 wird eine semiformale Beschreibung des sicherheitsrelevanten Teils gefordert.

Zwischen diesen beiden E-Stufen gibt es ebenfalls unterschiedliche Anforderungen bzgl. Detaillierungsgrad dieser semiformalen Darstellung. Sie bezieht sich vor allem auf die größtmögliche Unabhängigkeit der sicherheitsspezifischen Komponenten und die inhärent bestehenden Abhängigkeiten.

Bei der Sufe E6 wird eine formale Beschreibung des sicherheitsrelevanten Teils verlangt.

SE 4.2-SW: SW-interne und -externe Schnittstellen entwerfen

Alle Schnittstellen der sicherheitsspezifischen und sicherheitsrelevanten SW-Komponenten/Prozesse/SW-Module müssen mit ihrem Zweck und ihren Parametern beschrieben werden. Die Separierung vom nicht sicherheitrelevanten Teil muß sichtbar sein. Die Schnittstellen sind zu minimieren. Der Einsatz von bestimmten  Beschreibungsmethoden ist von der E-Stufe abhängig.

SE 4.3-SW: SW-Integration spezifizieren

Die Integration des sicherheitsrelevanten Teils, der evaluiert werden soll, in den Teil, der nicht evaluiert werden soll, muß spezifiziert sein.

SE 5-SW: SW-Feinentwurf

SE 5.1-SW: SW-Komponente/-Modul/Datenbank beschreiben

Ab der Evaluationsstufe E2 darf der Feinentwurf im Rahmen des Tailoring nicht mehr entfallen.

Bei den Stufen E2 und E3 ist eine informelle Beschreibung des Sicherheitsanteils des Feinentwurfs ausreichend.

Bei den Stufen E4 bis E6 ist eine semiformale Beschreibung des Sicherheitsanteils des Feinentwurfs erforderlich.

Es muß ein Abgleich des Feinentwurfs bzgl. des Grobentwurfs durchgeführt werden.

SE 5.2-SW: Betriebsmittel- und Zeitbedarf analysieren

Dieser Aspekt kann evtl. für die Sicherheitsvorgaben relevant sein.

SE 6-SW: SW-Implementierung

SE 6.3-SW: Selbstprüfung des SW-Moduls/der Datenbank durchführen

Es muß ein Abgleich des Codes bzgl. des Feinentwurfs durchgeführt werden.

SE 8: System-Integration

SE 8.2: Selbstprüfung des Systems durchführen

Das Zusammenwirken der Mechanismen ist zu untersuchen, und es müssen Penetrationsanalysen durchgeführt werden.

SE 8.3: Produkt bereitstellen

Die korrekte Anwendung der Sicherheitsfunktionen durch den Sicherheitsverantwortlichen und die Benutzer muß gewährleistet werden. Deshalb sind diese Informationen in die entsprechenden Handbücher zur Systemverwalter- und Benutzerdokumentation aufzunehmen.


Erläuterungen zum Submodell QS
Teil 3	Vorgehensmodell / Handbuchsammlung

SEC	Anwendung des V-Modells und der ITSEC

SEC.3	Erläuterungen zum Submodell QS

QS 1: QS-Initialisierung

Bis E3 ist ein manuelles Konfigurationsmanagement möglich.

Ab E4 ist ein werkzeuggestütztes Konfigurationsmanagement erforderlich.

Eine strikte Rollentrennung zwischen Entwicklung und QS ist ab E5 zwingend vorgeschrieben.

QS 2: Prüfungsvorbereitung

QS 2.1: Prüfmethoden und -kriterien festlegen

Als Prüfkriterien für die Sicherheitsfunktionen sind zu berücksichtigen:

−	Zusammenwirken der Sicherheitsfunktionen

−	Wirksamkeit der Mechanismen

−	Abgrenzung, dh. Schnittstellen zu nicht vertrauenswürdiger Software

Als Prüfmethoden für die Sicherheitsfunktionen sind zu berücksichtigen:

−	Schwachstellenanalyse

−	Wirksamkeitsanalyse

−	Penetrationstest

QS 4: Produktprüfung

QS 4.2: Produkt inhaltlich prüfen

Laufzeitbibliotheken werden in das System oder Produkt mit eingebunden und sind entsprechend der angestrebten Evaluationsstufe zu behandeln


Erläuterungen zum Submodell KM
Teil 3	Vorgehensmodell / Handbuchsammlung

SEC	Anwendung des V-Modells und der ITSEC

SEC.4	Erläuterungen zum Submodell KM

KM 1: KM-Planung

Konfigurationskontrolle ist bei allen E-Stufen erforderlich. Ab der Stufe E4 muß sie werkzeuggestützt erfolgen.

Für E6 müssen nicht nur die sicherheitsrelevanten Produkte, sondern auch die eingesetzten Werkzeuge der Konfigurationskontrolle unterliegen.

KM 2: Produkt- und Konfigurationsverwaltung

Ab der Stufe E4 muß sie werkzeuggestützt erfolgen. Die Anforderungen an die Leistungsfähigkeit dieses Werkzeugs wachsen bei jeder Evaluationsstufe.

KM 3: Änderungsmanagement (Konfigurationssteuerung)

KM 3.3: Änderung abschließen

Ab E4 muß eine Protokollinformation über Änderungen aller Produkte, die der Konfigurationskontrolle unterliegen, vorgelegt werden.


Erläuterungen zum Submodell PM
Teil 3	Vorgehensmodell / Handbuchsammlung

SEC	Anwendung des V-Modells und der ITSEC

SEC.5	Erläuterungen zum Submodell PM

PM 1: Projektinitialisierung

PM 1.2: Projektkriterien und Entwicklungsstrategie festlegen

Eine wesentliche Festlegung ist, ob das zu erstellende System oder Produkt evaluiert werden soll. Nur dann sind die ITSEC-Kriterien relevant und einzuhalten.

Ab der Evaluationsstufe E5 müssen die Laufzeitbibliotheken im Quellcode zur Verfügung gestellt werden. Deshalb muß vorab geklärt werden, ob der Compiler-Hersteller bereit ist, die Quellen an die Evaluationsstelle zur Einsichtnahme auszuliefern.

PM 1.3: Projektspezifisches V-Modell erstellen

Ein endgültiges projektspezifisches V-Modell kann erst dann erstellt werden, wenn die angestrebte E-Stufe feststeht.

PM 1.5: Grobplan erstellen

Da ab der Evaluationsstufe E4 oder höher spezielle Anforderungen an den Enwicklungsvorgang und an die Enwicklungsumgebung gestellt werden, muß rechtzeitig für die Verfügbarkeit der speziellen Werkzeuge, die über die geforderte Funktionalität bzw. Qualität verfügen, gesorgt werden.

Es muß erfahrenes Personal vorhanden sein, das eine Analyse des Zusammenwirkens der gewählten Sicherheitsfunktionen durchführen kann. Ebenso muß es imstande sein, Wirksamkeitsanalysen für die Mechanismen, die zur Implementierung der Sicherheitsfunktionen gewählt wurden, durchzuführen.

Bei höheren E-Stufen muß die Verfügbarkeit des Personals, das über entsprechende Erfahrung im Umgang mit semiformalen bzw. formalen Spezifikationen verfügt, gewährleistet sein.

Soll eine begleitende Evaluation durchgeführt werden, muß die Mitarbeit der Evaluatoren und des BSI  bei der Planung ebenfalls berücksichtigt werden.

PM 1.4: Toolset-Management durchführen

Bei den einzelnen E-Stufen sind Mindestanforderungen an Methoden und Werkzeuge definiert.

PM 10: Schulung/Einarbeitung

Falls die Projektmitarbeiter kein entsprechendes Wissen und keine entsprechende Erfahrungen in den notwendigen Kenntnissen (siehe Aktivität PM 1.3) für die Entwicklung nach einer bestimmten E-Stufe besitzen, müssen sie entsprechend geschult werden. Eine Sensibilisierung bzgl. Sicherheit ist erforderlich.


Behandlung der Sicherheit
Teil 3	Vorgehensmodell / Handbuchsammlung

SI	Sicherheit und Kritikalität

SI.1	Behandlung der Sicherheit

Kriterienkataloge zur Sicherheit fassen jeweils Mengen von Prüfkriterien an den Sicherheitsanteil eines Systems in Abhängigkeit der sicherheitsrelevanten Einstufung zusammen. Diese Einstufung bestimmt die Evaluierung unter den Aspekten Wirksamkeit und Korrektheit.

Aus Sicht des Entwicklungsprozesses sind hieraus abzuleiten:

−	Anforderungen an die Existenz bestimmter Produkte

−	Anforderungen an Inhalt und Eigenschaften dieser Produkte

−	Anforderungen an die Prüfung dieser Produkte

−	Anforderungen an Methoden/Werkzeuge, der Entwicklung

−	Anforderungen an die Rollenverteilungen und die damit verbundenen organisatorischen Maßnahmen

Die Anforderungen an die ersten drei Kategorien werden durch die Regelungen des V-Modells unmittelbar erfüllt. Die Anforderungen hinsichtlich der Methoden, Werkzeuge und organisatorischen Maßnahmen werden mittelbar im Rahmen der Vorgehensweise nach V-Modell erfüllt, indem diese in den entsprechenden Planungsdokumenten festgeschrieben und damit kontrolliert realisiert werden.


Behandlung der Kritikalität
Teil 3	Vorgehensmodell / Handbuchsammlung

SI	Sicherheit und Kritikalität

SI.2	Behandlung der Kritikalität

Unter "Kritikalität" wird im V-Modell die Bedeutung verstanden, die einem Fehlverhalten einer Betrachtungseinheit beigemessen wird. Es gibt sowohl physikalische Betrachtungseinheiten, dies sind die Produkte System, Segment, SW-Einheit/HW-Einheit, SW-Komponente, SW-Modul, Datenbank, als auch logische Betrachtungseinheiten, dies sind Funktionen (Systemfunktion, Segmentfunktion, Einheiten-Funktion). Zur Einstufung der Kritikalität ist nicht allein die physikalische Betrachtungseinheit, sondern auch die von ihr berührte Umgebung zu berücksichtigen. So sind z. B. bei einem Fehlverhalten der Software eines IT-Systems potentielle Auswirkungen in Betracht zu ziehen, die sowohl das System selbst als auch in der Folge seine Umwelt betreffen.


Kritikalitätszuordnung
Teil 3	Vorgehensmodell / Handbuchsammlung

SI	Sicherheit und Kritikalität

SI.2	Behandlung der Kritikalität

SI.2.1	Kritikalitätszuordnung

Die Kritikalität einer Betrachtungseinheit wird in Stufen (Kritikalitätsstufen) angegeben, wobei die Einstufung umso höher ist, je gravierendere direkte und indirekte Auswirkungen bei Fehlverhalten zu erwarten sind.

Als eine allgemeine Festlegung für technische Systeme kann die Kritikalitätseinstufung in Tabelle SI.1 angesehen werden.

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten kann zum Verlust von Menschenleben führen
mittel	Fehlverhalten kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen
niedrig	Fehlverhalten kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden
keine	Fehlverhalten gefährdet weder die Gesundheit von Menschen noch Sachgüter
Tabelle SI.1:	Festlegung von Kritikalität für technische Systeme

Bei Software muß die Festlegung der Kritikalität von deren Einsatzzweck abhängig gemacht werden. Sie soll, ebenso wie die Festlegung der Anzahl der Stufen, immer projektspezifisch durch eine Abschätzung der direkten und indirekten Auswirkungen eines möglichen Fehlverhaltens erfolgen.

Bei administrativen Informationssystemen ist durch ein Fehlverhalten keine Gefährdung von Menschenleben zu erwarten. Hier könnte beispielsweise für ein spezifisches Projekt die Kritikalitätseinstufung in Tabelle SI.2 verwendet werden.

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten macht sensitive Daten für unberechtigte Personen zugänglich oder verhindert administrative Vorgänge (z. B. Gehaltsauszahlung, Mittelzuweisung) oder führt zu Fehlentscheidungen infolge fehlerhafter Daten
niedrig	Fehlverhalten verhindert Zugang zu Informationen, die regelmäßig benötigt werden
keine	Fehlverhalten beeinträchtigt die zugesicherten Eigenschaften nicht wesentlich
Tabelle SI.2:	Festlegung von Kritikalität für administrative Informationssysteme

Als Beispiel einer projektspezifischen Kritikalitätseinstufung für eine Realzeitanwendung (z. B. Flugsicherung) könnte die Kritikalitätseinstufung in Tabelle SI.3 angesehen werden.

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten, das zu fehlerhaften Positionsangaben der Flugobjekte am Kontrollschirm führen kann
niedrig	Fehlverhalten, das zum Ausfall von Plandaten und damit zu Abflugverzögerungen führen kann
keine	alle übrigen Arten von Fehlverhalten
Tabelle SI.3:	Festlegung von Kritikalität für Realzeitanwendungen

Im Geltungsbereich des V-Modells leiten sich aus einer festgelegten Kritikalitätsstufe zusätzliche Qualitätsanforderungen ab, die der jeweiligen Funktionalität, d. h. den jeweiligen Funktionen samt ihren Importschnittstellen, zuzuordnen sind. Die Festlegung der Kritikalität der Funktionen ist für das System, jedes Segment und jede SW-Einheit/HW-Einheit in einer Kritikalitäten/Funktionen-Matrix darzustellen. Hierbei wird in Matrizendarstellung einer jeden Funktion eine bestimmte Kritikalitätsstufe zugeordnet.


Vererbung der Kritikalität
Teil 3	Vorgehensmodell / Handbuchsammlung

SI	Sicherheit und Kritikalität

SI.2	Behandlung der Kritikalität

SI.2.2	Vererbung der Kritikalität

Im Verlauf der Entwicklung werden Betrachtungseinheiten zunehmend verfeinert. Dabei vererben sich die Kritikalitätseinstufungen vom System auf die Systemfunktionen (Produkt ⇒ Funktion), von den Systemfunktionen auf Segmente (Funktion ⇒ Produkt), vom Segment auf die Segmentfunktionen und von hier ab über die SW-Einheiten/HW-Einheiten zu den Funktionen der SW-Einheiten/HW-Einheiten bis auf die SW-Komponenten, SW-Module und Datenbanken.

Da mit der Kritikalitätsstufe die Entwicklungskosten steigen, muß stets eine Minimierung der Anzahl kritischer Funktionen bei unverändertem Systemverhalten angestrebt werden. Hohe Kritikalität darf nur dort vergeben werden, wo sie notwendig ist.

Es gilt folgende Regel 1 (Vererbungsregel):

R 1a	Produkt ⇒ Funktion
Mindestens eine der bei oben angeführtem Verfeinerungprozeß aus einem Produkt erzeugten Funktionen muß eine gleich hohe Kritikalitätsstufe wie das Produkt selbst besitzen.

R 1b	Funktion ⇒ Produkt
Bei der Zuordnung der Funktionen zu den Produkten muß mindestens ein einer Funktion zugeordnetes Produkt eine gleich hohe Kritikalitätsstufe haben wie die Funktion.

Eine weitere Regel R2 betrifft die Kritikalität abhängiger Funktionen:

R 2a	Beeinflussen sich zwei Funktionen einseitig, d. h. eine Funktion nutzt Leistungen der anderen, so muß die Kritikalitätsstufe der beeinflussenden (benutzten) Funktion mindestens ebenso hoch sein wie die der nutzenden Funktion.

R 2b	Beeinflussen sich zwei Funktionen gegenseitig, z. B. durch gegenseitiges Senden von Signalen, müssen beide die gleiche Kritikalitätseinstufung haben.

Die Vererbungsregel R1 gewährleistet, daß eine einmal festgelegte Kritikalitätseinstufung eines Produkts im Verlaufe des Verfeinerungsprozesses in mindestens einem Verfeinerungszweig erhalten bleibt. Sie soll einen Designer dazu veranlassen, die Kritikalitätseinschätzung beim Entwurf möglichst genau zu lokalisieren.

Die Regel R2 soll ihn veranlassen, die Abhängigkeiten zwischen den Entwurfseinheiten zu minimieren. Dies entspricht einem wesentlichen Entwurfsprinzip für sichere, zuverlässige und wartbare Systeme.


Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten
Teil 3	Vorgehensmodell / Handbuchsammlung

SI	Sicherheit und Kritikalität

SI.2	Behandlung der Kritikalität

SI.2.3	Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten

Bei optimalen kritischen Pfaden kann die geforderte Sicherheit und Zuverlässigkeit durch Erhöhung der Kritikalität weiterer Funktionen nicht erhöht werden. Dadurch können die mit den jeweiligen Kritikalitätsstufen verbundenen Maßnahmen gezielt und mit besonderen Anstrengungen wahrgenommen werden. Diese Maßnahmen sind konstruktiver oder analytischer Natur. Sie haben das Ziel, die Zuverlässigkeit und Sicherheit auf unterschiedliche Art und Weise zu erhöhen:

−	Konstruktive Maßnahmen:
Entwicklung von eigensicheren bzw. fehlertoleranten Funktionseinheiten,
Konfigurierung von redundanten oder diversitären 1) Funktionseinheiten

−	Analytische Maßnahmen:
Durchführung umfangreicher Verifikation und Validation bis zur Zertifikationsreife

1)	Unter "diversitär" wird in diesem Zusammenhang die Realisierung redundanter Funktionseinheiten durch unterschiedliche Algorithmen oder physische Prinzipien verstanden.

In dieser generellen Formulierung sind die Maßnahmen sowohl auf die Hardware bzw. die materiellen Funktionseinheiten (z. B. von den Schaltkreisen bis zu den Geräten) als auch auf die Software (z. B. von Prozeduren bis zu Prozessen) anwendbar.

Während die Einstufung der Kritikalität im Submodell SE erfolgt, geschieht im Rahmen der Aktivität QS 1 "QS-Initialisierung" die Zuordnung der erforderlichen Maßnahmen. Hierfür sind Vorgaben für die Erstellung und Prüfung von Produkten zu machen. Diese Vorgaben bestehen primär in der Festschreibung bestimmter Methoden, aber auch von Werkzeugvorgaben, wie die Produkte zu erstellen und zu prüfen ist. Für jede Kritikalitätsstufe ist vorzugeben, welche Maßnahmen (anzuwendende Methoden und/oder einzusetzende Werkzeuge) gefordert werden, um einem Fehlverhalten entgegenzuwirken. Diese Angaben lassen sich am besten in Matrizenform darstellen. Aus diesem Grunde werden die Erstellungs- und Prüfvorgaben bezüglich der Kritikalitätsstufen als Kritikalitäten/Methoden-Matrix bezeichnet. Diese Kritikalitäten/Methoden-Matrix ist im QS-Plan festzuschreiben.

Bei der Festlegung der projektspezifischen Kritikalitäten/Methoden-Matrix sind vertragliche Vereinbarungen und Vorgaben zu beachten, wie z. B. bezüglich Zertifizierungs-Richtlinien, Genehmigungs-Richtlinien, validierte Werkzeuge oder diversitäre Entwicklungen.

Die Vorgehensweise und das Zusammenspiel zwischen SE und QS skizziert Abbildung SI.1. Unter Beachtung der Regeln R1 und R2 wird in den Aktivitäten SE 1 bis SE 4-SW die Kritikalität der Funktionseinheiten bestimmt, verfeinert und in Kritikalitäten/Funktionen-Matrizen dargestellt.

Unter Verwendung der Kritikalitäten/Methoden-Matrix im QS-Plan werden

−	die Konstruktionsvorgaben in eine Aufgabenplanung umgesetzt (Aktivitäten PM 1, PM 4),

−	die Konstruktionsschritte durchgeführt (Aktivitäten SE 1−SE 6-SW),

−	Prüfvorgaben festgeschrieben (Aktivität QS 2),

−	Prüfungen durchgeführt (Aktivität QS 4),

−	geprüfte Produkte integriert (Aktivitäten SE 7-SW−SE 8),

−	integrierte SE-Produkte geprüft (Aktivität QS 4).

Abbildung SI.1: SE- und QS-Zusammenarbeit bezüglich der Kritikalität

Die folgende Tabelle SI.4 enthält beispielhafte Empfehlungen für die Aufstellung einer Kritikalitäten/Methoden-Matrix für Software-Produkte unter Berücksichtigung des heutigen und mittelfristig zu erwartenden Technologiestandes. Die Tabellen geben die Zuordnung nur als Vorschlag und ohne Berücksichtigung anwendungsspezifischer Aspekte wieder. So ist im allgemeinen Fall weder eine Prüfung mittels C1-Testabdeckung für eine unkritische Funktionseinheit ausgeschlossen noch eine Spezifikation nach streng mathematischen Methoden für eine hochkritische Funktionseinheit obligatorisch. Ist jedoch eine Festlegung wie im Beipiel der Tabelle SI.4 getroffen, so ist diese für das Projekt verbindlich.

Konstruktive Qualitätssicherungsmethoden	Kritikalitätsstufe
(Erstellungsmethoden)	hoch	mittel	niedrig	keine
SW-Anforderungen mit SADT	•	•	•
Grobentwurf mit HOOD	•	•	•
Feinentwurf mit HOOD PDL	•	•	•
Feinentwurf mit VDM (algebraisch)	•
Programmierrichtlinien XYZ befolgen	•	•	•	•
Strukturierte Programmierung	•	•	•	•
Verwendung eines validierten Compilers	•	•	•
Analytische Qualitätssicherungsmethoden	Kritikalitätsstufe
(Prüfmethoden)	hoch	mittel	niedrig	keine
Walkthrough	•	•	•	•
Audit für Aktivitäten laut QS-Plan	•	•	•
Durchschnittliche C1-Testabdeckung von mindestens 90 %	•	•	•	•
Durchschnittliche C2-Testabdeckung von mindestens 90 %	•	•	•
Informelle Prüfung gemäß Prüfspezifikation	•	•
Korrektheitsbeweis Code versus Feinentwurf	•
Stat. Analyse bzgl. Einhaltung der Programmierrichtl. XYZ	•	•	•	•
Simulation	•
Tabelle SI.4:	Beispiel einer Kritikalitäten/Methoden-Matrix


Abbildungsverzeichnis AU250/3 - SI
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - SI)

A.1	Abbildungsverzeichnis

Abbildung SI.1:	SE- und QS-Zusammenarbeit bezüglich der Kritikalität


Tabellenverzeichnis AU250/3 - SI
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - SI)

A.2	Tabellenverzeichnis

Tabelle SI.1:	Festlegung von Kritikalität für technische Systeme

Tabelle SI.2:	Festlegung von Kritikalität für administrative Informationssysteme

Tabelle SI.3:	Festlegung von Kritikalität für Realzeitanwendungen

Tabelle SI.4:	Beispiel einer Kritikalitäten/Methoden-Matrix


Überblick
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.1	Überblick

In dem vorliegenden Handbuch werden Szenarien zur Anwendung des V-Modells dargestellt, in denen beispielhaft der dynamische Ablauf der Aktivitäten skizziert wird.

Die folgenden Szenarien werden behandelt:

−	Inkrementelle Entwicklung,

−	Grand Design (Traditionelles Vorgehen),

−	Einsatz von Fertigprodukten,

−	Objektorientierte Entwicklung,

−	Entwicklung wissensbasierter Systeme,

−	Software-Pflege und -Änderung.

Die inkrementelle Entwicklung wird als Regelfall betrachtet. Der Grand Design wird als Spezialfall der inkrementellen Entwicklung dargestellt.

Die Szenarien wurden auf der Basis konkreter Projekterfahrungen aus V-Modell-Projekten im BWB und in Industriefirmen erarbeitet. Die Inhalte sind verträglich mit internationalen Arbeiten (ISO, WEAG) und den Konzepten der entsprechenden amerikanischen Standards (MIL-STD-498 usw.).


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.2	Inkrementelle Entwicklung

SZ.2.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Die inkrementelle Vorgehensweise basiert auf der Grundidee, daß ein System in seiner Gesamtheit geplant, aber in Teilen realisiert wird − mit einem ständigen, stufenweisen Zuwachs an Funktionalität. Im Regelfall wird an den Anwender möglichst frühzeitig eine erste Systemversion ausgeliefert, die die Basisfunktionalität bietet. Später entwickelte (und gelieferte) Systemteile erweitern die Funktionalität im wesentlichen nur.

Die inkrementelle Vorgehensweise geht davon aus, daß die Anwenderforderungen in ihren wesentlichen Aspekten vollständig bereits zu Beginn der Entwicklung erfaßt werden können und daß es möglich ist, das gesamte System in verschiedenen Teilabschnitten bzw. Ausbaustufen (im Englischen "increments" oder "builds") zu entwerfen, zu entwickeln, einzuführen und zu nutzen.

Die einzelnen Ausbaustufen erfüllen jeweils einen Teil der gesamten geplanten Funktionalität des Systems. Dabei ist es notwendig, frühzeitig das gesamte System durch die Definition der Systemarchitektur zu entwerfen. Für die Ermöglichung eines inkrementellen Vorgehens werden an die Systemarchitektur besondere Anforderungen gestellt. So müssen Schnittstellen klar definiert sein und einen modularen, schrittweisen Ausbau des Systems ermöglichen.

Im weiteren Vorgehen wird dann die Systemarchitektur (im Regelfall nach funktionalen Kriterien) in Teile zerlegt, so daß die einzelnen Ausbaustufen bezüglich Umfang und Reihenfolge der Bearbeitung festgelegt werden können.

Die Vergabe der einzelnen Ausbaustufen als einzelne Verträge ist möglich. Der Endnutzer kann bereits die jeweiligen Ausbaustufen für seine Aufgabenerfüllung einsetzen.

Der Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung ist in Abbildung SZ.1 illustriert.

Abbildung SZ.1: Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung

Zeitpunkt T 0 − Start

Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.

Zeitpunkt T 1 − Erste Ausbaustufe

Als Ergebnis von Aktivität SE 1.2 liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt.

Für einige der in Aktivität SE 1.5 identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.

Die Ergebnisse der Aktivitäten SE 1.2 und SE 1.5 bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 1 in einer ersten Version vorliegen.

Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:

−	Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. 1)

−	Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.

−	Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.

1)	Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.

Als Ergebnis von Aktivität SE 2.1 sind die Bereiche der ersten Ausbaustufe in ihrer technischen Umsetzung (in der Systemarchitektur und den Technischen Anforderungen) beschrieben.

Die einzelnen Bereiche werden soweit detailliert und ausgearbeitet, wie es für die erste produktive Systemversion notwendig ist. In späteren Stufen können die einzelnen Bereiche verfeinert und um neue ergänzt werden.

Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE 1-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt. Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet.

Zeitpunkt T 2 bis T N-1 − Weitere Ausbaustufen

Zum Zeitpunkt T 2 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE 1.2 eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen Bereichen kommen.

Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.

Die damit in einer zweiten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.

Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.

Diese Arbeitsschritte werden für jedes Inkrement wiederholt.

Zeitpunkt T N − Abschluß der Systementwicklung

Zum Zeitpunkt T N liegen Anwenderforderungen, Systemarchitektur und Technische Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung.


Zusammenspiel der Submodelle SE und PM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.2	Inkrementelle Entwicklung

SZ.2.2	Zusammenspiel mit den übrigen Submodellen

SZ.2.2.1	Zusammenspiel der Submodelle SE und PM

Die besondere Komplexität des Projektmanagements für inkrementell ablaufende Entwicklungen ergibt sich aus der Tatsache, daß parallel zu den Entwicklungstätigkeiten bereits Systemteile vom Anwender (evtl. im Parallelbetrieb) eingesetzt werden. Durch die aufeinanderfolgende Auslieferung von Systemteilen ergeben sich mehrere zu koordinierende Liefertermine und i. d. R. Teilabnahmen. Der anzuwendende PM-Zyklus ist in Abbildung SZ.2 dargestellt.

Abbildung SZ.2: PM-Zyklus bei einer inkrementellen Entwicklung

Auf der Basis einer groben Beschreibung des Planungshorizonts und der Systemarchitektur muß im Rahmen der Grobplanung die Konzipierung der Inkremente erfolgen. Dies betrifft sowohl die inhaltliche Abgrenzung der Inkremente gegeneinander als auch die zeitliche Planung für die Erstellung der einzelnen Inkremente. Bedingung für die Aufteilung der Systemarchitektur in die einzelnen Realisierungsstufen ist die Modularität der Architektur. Sie muß den schrittweisen Aufwuchs des Systems ermöglichen, ohne bereits fertiggestellte Inkremente grundsätzlich überarbeiten zu müssen. Für jede Ausbaustufe wird im Rahmen der Projektplanung eine Baseline als Basis für die nachfolgende Entwicklung definiert.

Die Realisierbarkeitsuntersuchungen auf der technischen Entwicklungsebene liefern wertvolle Informationen für das Risikomanagement. Die Ergebnisse sind Teil der Entscheidungsgrundlage für das Projektmanagement.

Forderungscontrolling wird für alle Ausbaustufen durchlaufen und kann bei Entscheidungsbedarf zu einer Durchführungsentscheidung führen.


Zusammenspiel der Submodelle SE und QS
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.2	Inkrementelle Entwicklung

SZ.2.2	Zusammenspiel mit den übrigen Submodellen

SZ.2.2.2	Zusammenspiel der Submodelle SE und QS

Aus Sicht der Qualitätssicherung ergeben sich durch die Teillieferungen erhöhte Anforderungen an die Prüfung von Schnittstellen. Die Durchführung von Teilabnahmen mit vorausgehender Qualitätsprüfung ist in der Prüfplanung zu berücksichtigen.


Zusammenspiel der Submodelle SE und KM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.2	Inkrementelle Entwicklung

SZ.2.2	Zusammenspiel mit den übrigen Submodellen

SZ.2.2.3	Zusammenspiel der Submodelle SE und KM

Das Konfigurationsmanagement verwaltet im Fall der inkrementellen Vorgehensweise neben der Konfigurationsstruktur auf der Seite der technischen Systementwicklung auch die Struktur der bereits ausgelieferten Systemteile.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.2	Inkrementelle Entwicklung

SZ.2.3	Kriterien für die Auswahl des Szenarios

Die folgende Auflistung von Vor- und Nachteilen und die Nennung der wichtigsten Voraussetzungen unterstützt die Entscheidungsfindung zur Auswahl der dargestellten inkrementellen Entwicklungsstrategie.

Vorteile:

−	Frühzeitige Auslieferung eines Basissystems und dadurch frühzeitiger Einsatz eines operablen Systemkerns beim Anwender,

−	Priorisierung der Lieferreihenfolge durch den Anwender (evtl. auf der Basis von Erfahrungen mit den ersten ausgelieferten Systemteilen),

−	einfacher Austausch von Systemteilen (nämlich den Inkrementen) im Pflege- und Änderungsfall,

−	Problemloser Wechsel des Auftragnehmers nach Abschluß der Realisierung eines Inkrements,

−	Verfeinerung der Anwenderforderungen im Laufe der Entwicklung (die Anwenderforderungen müssen zu Beginn nicht vollständig vorliegen),

−	deutlich kürzere Zyklen bei Änderung von Anwenderforderungen gegenüber konventioneller Entwicklung.

Nachteile:

−	Änderungen des geplanten Vorgehens beim Systemaufwuchs müssen den jeweiligen Auslieferungsstand berücksichtigen. Durch eine geeignete Modularisierung und die Definition von sauberen Schnittstellen können Probleme nachhaltig vermieden werden.

−	Die Notwendigkeit der frühzeitigen Festschreibung des Gesamthorizonts für die gesamte Entwicklungszeit kann bei langen Projektlaufzeiten schwierig sein. Hier kann es sinnvoll sein, mehrere aufeinanderfolgene Projekte zu definieren.

Voraussetzungen:

−	Separierbarkeit des Systems bei klaren Schnittstellen (modularer Aufbau der Systemarchitektur).

−	Die genannten Vor- und Nachteile sind jeweils im Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal für alle Projekte als gültig angesehen werden, sondern müssen vor dem Hintergrund der fachlichen und technischen Anforderungen sowie der zu beachtenden Randbedingungen geprüft werden.


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Die traditionelle Vorgehensweise bei einer Systementwicklung wird häufig im Englischen als "Big Bang", "One Shot" oder "Grand Design" bezeichnet.

Kennzeichnend für diese Vorgehensweise ist der lineare zeitliche Verlauf der Systementwicklung (Phasenmodell). In jeder Phase wird stets das gesamte beabsichtigte System in seiner vollständigen Funktionalität behandelt. Der vollständige Abschluß einer Phase ist Voraussetzung für den Beginn der nächsten Phase.

Die traditionelle Vorgehensweise ist damit ein Spezialfall der inkrementellen Entwicklung (Realisierung in einem Inkrement).

Der Ablauf der SE-Aktivitäten beim Grand Design ist in Abbildung SZ.3 illustriert.

Abbildung SZ.3: Ablauf der SE-Aktivitäten beim Grand Design

Zeitpunkt T 0 − Start

Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.

Zeitpunkt T 1 − vollständige Anwenderforderungen

Zum Zeitpunkt T 1 ist das System aus Sicht von Aktivität SE 1 vollständig bearbeitet. Im einzelnen bedeutet dies:

−	Die Anwenderforderungen sind vollständig ausgearbeitet.

−	Das System ist vollständig in Segmente zerlegt.

−	Die technische Anforderungen an das System sind vollständig festgelegt.

Zeitpunkt T 2 − Abschluß der Systementwicklung und Überleitung des Systems

Zum Zeitpunkt T 2 ist die Systementwicklung abgeschlossen und das System in die Nutzung übergeleitet.

Die Realisierung erfolgt in folgenden Schritten:

−	Falls bei der Systemarchitektur in Aktivität SE 2 Segmente identifiziert sind, werden für diese Segmente die technischen Anforderungen vollständig festgelegt und vollständige Zerlegungen in SW- und HW-Einheiten durchgeführt (Aktivität SE 2).

−	Für die identifizierten SW-Einheiten/HW-Einheiten werden die technischen Anforderungen vollständig festgelegt. Die Erstellung der Technischen Anforderungen ist damit abgeschlossen (Aktivität SE 3).

−	Alle identifizierten SW-Einheiten/HW-Einheiten werden vollständig realisiert (Aktivitäten SE 4-SW bis SE 7-SW).

−	Die realisierten SW-Einheiten/HW-Einheiten werden zum System integriert (Aktivität SE 8).

Das Entwicklungsprojekt ist nach der Überleitung des Systems abgeschlossen.


Zusammenspiel der Submodelle SE und PM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.2	Zusammenspiel mit den übrigen Submodellen

SZ.3.2.1	Zusammenspiel der Submodelle SE und PM

Die schematisch geregelte und relativ starre Abwicklungsweise eines Vorhabens in der geschilderten Art und Weise kann − bei ausreichender Erfahrung im Anwendungsgebiet − durch die Festschreibung der Anforderungen häufig vorausschauend und mit tragbaren Risiken geplant und durchgeführt werden.

Die besondere Problematik der phasenorientierten Vorgehensweise liegt in den eingeschränkten und aufwendigen Mechanismen zur Berücksichtigung von unvorhergesehen Änderungen und dem mangelhaften Umgang mit unscharfen oder ungenügend detaillierten Anforderungen.

Erfahrungsgemäß kann nur bei sehr klar definierten Anforderungen und bei geringen technischen und fachlichen Projektrisiken eine solche Vorgehensweise zuverlässig und erfolgreich angewendet werden.

Zur besonderen Aufgabe des PM gehört deshalb ein sensibles Risikomanagement, das Risiken der Vorgehensweise frühzeitig erkennt und zu einer Änderung der Entwicklungsstrategie führen kann.


Zusammenspiel der Submodelle SE und QS
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.2	Zusammenspiel mit den übrigen Submodellen

SZ.3.2.2	Zusammenspiel der Submodelle SE und QS

Auf der Basis relativ frühzeitig bekannter und festgeschriebener Anforderungen sind die Schritte zur Qualitätsprüfung regelmäßig zu planen und durchzuführen. Bei Ausschluß obengenannter Risiken sind keine besonderen Vorgehensweisen bezüglich der Regelungen zur Qualitätssicherung zu beachten.


Zusammenspiel der Submodelle SE und KM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.2	Zusammenspiel mit den übrigen Submodellen

SZ.3.2.3	Zusammenspiel der Submodelle SE und KM

Die schichtenweise Erstellung des Systems entlang der Erzeugnisstruktur wird durch die Regelungen des Konfigurationsmanagements abgedeckt. Da die Überleitung des Systems in die Nutzung in einem Schritt erfolgt, ist die Auslieferung unproblematisch.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.3	Grand Design (Traditionelles Vorgehen)

SZ.3.3	Kriterien für die Auswahl des Szenarios

Die folgende Auflistung von Vor- und Nachteilen und die Nennung der wichtigsten Voraussetzungen unterstützt die Entscheidungsfindung zur Auswahl der dargestellten Grand Design Vorgehensweise.

Vorteile:

−	Große Planungs- und Abwicklungssicherheit aufgrund frühzeitigem Vorliegen stabiler Anwenderforderungen,

−	problemloser Wechsel des Auftragnehmers nach Abschluß jeder Phase.

Nachteile:

−	Inflexible Reaktion auf unvorhersehbare Änderungen,

−	Notwendigkeit der frühzeitigen Definition der Anwenderforderungen und deren Festschreibung für die gesamte Entwicklungszeit,

−	späte Auslieferung des Systems.

Voraussetzungen:

−	Stabile Anwenderforderungen.

Die genannten Vor- und Nachteile sind jeweils im Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal für alle Projekte als gültig angesehen werden, sondern müssen vor dem Hintergrund der fachlichen und technischen Anforderungen sowie der zu beachtenden Randbedingungen geprüft werden.


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.4	Einsatz von Fertigprodukten

SZ.4.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Die Einbindung von Fertigprodukten (verfügbare, für das Projekt passende Funktionseinheiten) in ein System basiert auf der Idee, Entwicklungsaufwand durch Nutzung bereits verfügbarer Bausteine (SW und HW) zu reduzieren.

Fertigprodukte können unterschiedlicher Herkunft sein:

−	Kommerzielle Fertigprodukte werden auf dem Markt angeboten. Der Quellcode steht im Normalfall nicht zur Verfügung. Sie werden in Lizenz erworben.

−	Fertigprodukte liegen im eigenen Umfeld vor (z. B. Industrie, Behörde, befreundete Organisationen). Der Quellcode steht hier in der Regel zur Verfügung.

Sie können auf allen Ebenen der Erzeugnisstruktur des V-Modells eingesetzt werden, sofern sie die zuvor festgelegten Anforderungen erfüllen.

Der Einsatz von Fertigprodukten im Rahmen einer inkrementellen Entwicklung ist in Abbildung SZ.4 illustriert.

Vorbemerkungen:

−	Grundlage der nachfolgenden Beschreibungen ist das Szenario zur inkrementellen Systementwicklung.

−	Die Ergänzungen zum Einsatz von Fertigprodukten sind kursiv dargestellt.

Abbildung SZ.4: Ablauf der SE-Aktivitäten bei einem Einsatz von Fertigprodukten

Zeitpunkt T 0 − Start

Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.

Zeitpunkt T 1 − Prüfung auf einsetzbare Fertigprodukte

Als Ergebnis von Aktivität SE 1.2 liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt.

Für einige der in Aktivität SE 1.5 identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.

Die Ergebnisse der Aktivitäten SE 1.2 und SE 1.5 bilden zusammen die Anwenderforderungen, die in einer ersten Version vorliegen (Anwenderforderungen Version 1).

Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:

−	Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. 2)

−	Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.

−	Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.

2)	Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.

Als Ergebnis von Aktivität SE 2.1 sind die Bereiche der ersten Ausbaustufe in ihrer technischen Umsetzung (in der Systemarchitektur und den technischen Anforderungen) beschrieben.

Die einzelnen Bereiche werden soweit detailliert und ausgearbeitet, wie es für die erste produktive Systemversion notwendig ist. In späteren Stufen können die einzelnen Bereiche verfeinert und um neue ergänzt werden.

Die im Rahmen der Realisierbarkeitsuntersuchung durchgeführte Marktsichtung ergibt, daß Teile der Anwenderforderungen durch kommerziell verfügbare Produkte abgedeckt werden können. Die Bewertung der in Frage kommenden Fertigprodukte (in Aktivität PM 2) ergibt jedoch, daß kein Fertigprodukt alle definierten Anwenderforderungen erfüllt. Im Rahmen einer Durchführungsentscheidung (Aktivität PM 6) wird die Durchführung eines Forderungscontrolling beschlossen.

Im Forderungscontrolling werden Vorschläge für eine Modifikation/Reduzierung der Anforderungen erarbeitet. Die Ergebnisse des Forderungscontrolling werden in die Anwenderforderungen eingearbeitet (Anwenderforderungen Version 2). Gegebenenfalls ist auch eine Modifikation der Systemarchitektur erforderlich. Die Anwenderforderungen bilden die Basis für den in PM zu erstellenden Kriterienkatalog zur Auswahl geeigneter Fertigprodukte.

Zeitpunkt T 2 − Integration der Fertigprodukte

Zum Zeitpunkt T 2 sind die von PM beschafften Fertigprodukte zur ersten Ausbaustufe integriert. Erforderliche Konfektionierungsarbeiten sind durchgeführt.

Nach Abschluß der Integration wird die erste Ausbaustufe in die Nutzung übergeleitet.

Zeitpunkt T 3 bis T N-1 − Weitere Ausbaustufen

Zum Zeitpunkt T 3 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE 1.2 eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen Bereichen kommen.

Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.

Die damit in einer dritten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.

In der zweiten Ausbaustufe werden Anforderungen umgesetzt, die nicht durch Fertigprodukte abgedeckt werden können.

Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.

Diese Arbeitsschritte werden für jedes Inkrement wiederholt.

Zeitpunkt T N − Abschluß der Systementwicklung

Zum Zeitpunkt T N liegen Anwenderforderungen, Systemarchitektur und Technische Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung.


Zusammenspiel der Submodelle SE und PM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.4	Einsatz von Fertigprodukten

SZ.4.2	Zusammenspiel mit den übrigen Submodellen

SZ.4.2.1	Zusammenspiel der Submodelle SE und PM

Die Beschaffung der Fertigprodukte erfolgt im Submodell PM (Aktivität PM 2). Zwecks Konkurrenzierung sind Angebote unterschiedlicher Anbieter einzuholen und zu bewerten. Im Rahmen der Angebotsbewertung sind erforderliche Konfektionierungsmaßnahmen zu skizzieren.

Sofern kein angebotenes Fertigprodukt alle definierten Auswahlkriterien erfüllt, wird im Rahmen einer Durchführungsentscheidung (Aktivität PM 6) über die Notwendigkeit eines Forderungscontrolling entschieden.


Zusammenspiel der Submodelle SE und QS
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.4	Einsatz von Fertigprodukten

SZ.4.2	Zusammenspiel mit den übrigen Submodellen

SZ.4.2.2	Zusammenspiel der Submodelle SE und QS

Die Erfüllung der von einem Fertigprodukt geforderten Eigenschaften wird im Rahmen der Bewertung der Angebote (Aktivität PM 2) geprüft und bewertet. Eine explizite Prüfung der Fertigprodukte im Rahmen des Submodells QS ist deshalb nicht erforderlich.

Durchgeführte Konfektionierungsmaßnahmen sind gemäß den Regelungen des Submodells QS zu prüfen, ebenso wie die im Rahmen von Aktivität PM 2 erstellten Ausschreibungsunterlagen.


Zusammenspiel der Submodelle SE und KM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.4	Einsatz von Fertigprodukten

SZ.4.2	Zusammenspiel mit den übrigen Submodellen

SZ.4.2.3	Zusammenspiel der Submodelle SE und KM

Jedes Fertigprodukt ist hinsichtlich der Konfigurationsadministration ebenso wie jedes eigenentwickelte Produkt zu behandeln. Bezüglich des Änderungsmanagements ist anzumerken, daß die Weiterentwicklung vom Anbieter der Fertigprodukte beeinflußt wird. Modifikationen der Anwenderforderungen haben im Normalfall keinen Einfluß auf die Weiterentwicklung des Fertigprodukts.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.4	Einsatz von Fertigprodukten

SZ.4.3	Kriterien für die Auswahl des Szenarios

Die folgende Auflistung von Vor- und Nachteilen und die Nennung der wichtigsten Voraussetzungen unterstützt die Entscheidungsfindung bezüglich des Einsatzes von Fertigprodukten.

Vorteile:

−	Reduzierung des Entwicklungsrisikos,

−	Minimierung der Entwicklungszeiten,

−	Erhöhung der Produktivität der Softwareentwicklung,

−	Reduzierung der Lebenszykluskosten,

−	Einsatz bereits ausgereifter Produkte, die dem aktuellen Stand der Technik entsprechen,

−	Minimierung des Pflege-/Änderungsaufwands,

−	schnelle Realisierung von Prototypen.

Nachteile:

−	Fehlende Einflußnahme auf die Weiterentwicklung des Fertigprodukts (Abhängigkeit vom Lieferanten), 3)

−	oftmals keine vollständige Erfüllung aller definierten Anforderungen durch ein Fertigprodukt,

−	Nutzung der Fertigprodukte in Lizenz,

−	Defizite bezüglich Sicherheit und Zuverlässigkeit,

−	häufig Änderung der Organisation erforderlich.

3)	Die Produktweiterentwicklung wird in der Hauptsache vom Markt getrieben, nicht von den Anwenderforderungen.

Voraussetzungen:

−	Definierte Auswahlkriterien,

−	stabile Anwenderforderungen.

Die genannten Vor- und Nachteile sind jeweils im konkreten Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal als gültig angesehen werden. Beispielsweise kann die aufgrund eines Fertigprodukteinsatzes erforderliche Änderung der Organisation positive Auswirkungen haben und die Effektivität der Organisation steigern.


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.5	Objektorientierte Entwicklung

SZ.5.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Objektorientierung wurde vorwiegend als Programmierkonzept bekannt. Durch den Einsatz von objektorientierten Analyse- und Entwurfsmethoden können jedoch bereits sehr früh im Entwicklungsgang objektorientierte Konzepte eingesetzt werden und von der Analyse über den Entwurf bis zur Implementierung zu einer durchgängigen Betrachtungsweise für den gesamten Entwicklungsgang zusammengefügt werden.

Der Einsatz objektorientierter Konzepte begünstigt die Identifikation, Erstellung und Wiederverwendung vorgefertigter (fachlicher und technischer) Bausteine, die gegebenenfalls in Bibliotheken projektübergreifend zur Verfügung gestellt werden. Diese als sogenannte "Klassen" vorliegenden Bausteine kapseln Daten und Funktionen. Dadurch werden die Entwurfsprinzipien der Datenkapselung und der Abstraktion umgesetzt. Änderungen an Klassen sind dann ohne Auswirkungen auf andere Systemteile durchführbar, wenn sie sich lediglich auf die innere Implementierung einer Klasse, jedoch nicht auf deren äußere Spezifikation beziehen.

Klassen und Objekte sind Bausteine einer objektorientierten Architektur. Sie werden sowohl aus statischer Sicht (Klassen- und Objektmodelle) als auch aus dynamischer Sicht (Zustands- und Interaktionsmodelle) spezifiziert. Klassen werden im allgemeinen hierarchisch in Gruppen (Subsystemmodelle) zusammengefaßt.

Eine objektorientierte Vorgehensweise ist im Grundsatz gekennzeichnet durch

−	iteratives Vorgehen,

−	inkrementelle Entwicklung,

−	Prototyping und

−	Einsatz objektorientierter Methoden.

Iteratives Vorgehen gestattet die wiederholte (iterative) Prüfung und Verbesserung vorangehender Ergebnisse. Die inkrementelle Vorgehensweise ermöglicht die Entwicklung von Teilen der objektorientierten Architektur, mit denen u. a. erste greifbare Ergebnisse geliefert werden können. Prototyping wird bei der objektorientierten Vorgehensweise zur Entwicklung von Informationssystemen primär im Sinne des explorativen Prototypings angewendet. Ziel dieses Prototypings ist es, primär Informationen zur Verfeinerung, Ergänzung und Klärung der Anwenderanforderungen zu bekommen. Bei der Entwicklung technischer Systeme wird Prototyping in erster Linie im Sinne des experimentellen Prototypings verwendet.

Durch den Einsatz objektorientierter Methoden werden SE-Aktivitäten zur statischen und dynamischen Modellierung der objektorientierten Architektur unterstützt. Weiterhin dienen sie der Erfassung der an das System gestellten funktionalen Anforderungen und der Beschreibung des physischen Softwareentwurfs, der physischen Plattform der objektorientierten Architektur und der Prozeßgliederung des Systems.

Durch den Einsatz von modular zusammenfügbaren Bausteinen (Klassen) sind Änderungen an der Architektur i. d. R. mit geringerem Aufwand möglich, als bei klassischer (nicht objektorientierter) Vorgehensweise.

Durch den Einsatz von Klassenbibliotheken und objektorientierte Methoden wird die Verwendung vorgefertigter Teile im Sinne einer Fertigprodukt-orientierten Entwicklungsstrategie erleichtert. Entwicklungszyklen sind schneller abwickelbar, da modulare, objektorientierte Architekturen i. d. R. änderungsfreundlich sind.

Die Regelungen zum Projekt- und Konfigurationsmanagement sowie zur Qualitätssicherung bleiben vom Einsatz objektorientierter Methoden grundsätzlich unbeeinflußt, da die Regelungen des V-Modells methodenunabhängig formuliert sind.

Im Rahmen einer objektorientierten Vorgehensweise sind Anwenderforderungen Ausgangspunkt aller weiteren Arbeiten und sind im Sinne einer vertragstauglichen Arbeitsgrundlage verbindlich für die gesamte Systementwicklung. Im objektorientierten Szenario werden die Anwenderforderungen im Rahmen des Gesamthorizonts verfeinert.

Der Ablauf der SE-Aktivitäten bei einer objektorientierten Vorgehensweise ist in Abbildung SZ.5 illustriert.

Vorbemerkungen:

−	Um von speziellen objektorientierten Methoden zu abstrahieren, wird  − soweit wie möglich − eine für alle objektorientierten Methoden gültige Vorgehensweise dargestellt.

−	Objektorientierung ist ein generelles Konzept, das sich im Prinzip für alle Teile (fachlich wie technisch) eines Systems anwenden läßt. Im Szenario wird der Fall dargestellt, daß objektorientierte Konzepte möglichst weitgehend angewendet werden und es nur vernachlässigbare "konventionelle" Anteile gibt. 4)

−	Die objektorientierten Ergänzungen sind kursiv dargestellt.

4)	Im Unterschied dazu wird z. B. im Szenario für die Entwicklung wissensbasierter Systeme grundsätzlich von einer Zweiteilung in den wissensbasierten Teil einerseits und einen relevanten "konventionellen" Anteil andererseits ausgegangen.

Abbildung SZ.5: Ablauf der SE-Aktivitäten bei einer objektorientierten Entwicklung

Zeitpunkt T 0 − Start

Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.

Zeitpunkt T 1 − grobe Systembeschreibung

Als Ergebnis von Aktivität SE 1.2 liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt. Hier wird das System zunächst in Bereiche untergliedert, wobei jeder Bereich aus konzeptionell fachlicher Sicht eine Einheit für die Analyse darstellt. Anwenderanforderungen werden in Form von Anwendungsfällen, sogenannten "Use Cases" beschrieben. Die so definierten Anwendungsfälle stellen mit ihren funktionalen Anforderungen eine Basis für die Ermittlung von Klassen und Objekten, für die Zuordnung von Funktionalität zu Klassen und den Entwurf von Schnittstellen dar. Sie werden auch zur Abstimmung der Anwenderanforderungen mit dem Nutzer eingesetzt. Die für ein System spezifizierten Anwendungsfälle enthalten in ihrer Gesamtheit die anwendungsorientierten, funktionalen Anforderungen an das System. Darauf aufbauend werden die objektorientierten Konzepte der Klassen- und Objektmodellierung eingesetzt, um im weiteren als durchgängige Darstellungsweise bis zur Implementierung verfeinert zu werden. Wesentliche Aufgabe der Klassen- und Objektmodellierung ist, die statischen Aspekte objektorientierter Systeme zu erfassen. Die Dynamik und die Interaktionen innerhalb objektorientierter Systeme werden mit anderen objektorientierten Elementarmethoden erfaßt.

Für einige der in Aktivität SE 1.5 identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.

Die Beschreibung der Funktionalität enthält die Gesamtheit der Anwendungsfälle ("Use cases") und der darauf aufbauenden ersten Klassenstruktur − in der vor allem die Verantwortlichkeiten der Klassen und deren Zusammenarbeit beschrieben sind − sowie eine erste Darstellung der Dynamik und der Interaktionen zwischen Objekten der Klassen.

Zeitpunkt T 2 − Integration vordefinierter fachlicher Bausteine

Wichtiger Bestandteil einer fortgeschrittenen objektorientierten Entwicklung ist das Vorliegen und der Einsatz von Bibliotheken mit vordefinierten Klassen.

Die Verwendung vordefinierter Klassen soll

−	die Entwicklungsarbeiten durch Einsparung an Entwicklungsaufwand beschleunigen,

−	die Qualität durch Integration "gereifter" Klassen erhöhen,

−	die fachlich und technisch ausgerichteten Entwurfsarbeiten an verfügbaren Bausteinen orientieren, um kostengünstigere Lösungen zu erzielen,

−	durch evolutionäre Weiterentwicklung der Klassenbibliothek als Nebeneffekt ("spin off") der Systementwicklung zukünftige Entwicklungen fördern.

Die Klassenbibliothek soll nicht nur als Bausteinquelle dienen, sondern auch bewährte und evtl. standardisierte fachliche Architekturen begünstigen. Falls für den Anwendungsbereich bereits vordefinierte Bereichsbeschreibungen in objektorientierter Form vorliegen, können sie  verwendet werden.

Die Ergebnisse der Aktivitäten SE 1.2 bis SE 1.5 bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 2 in einer ersten Version vorliegen.

Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:

−	Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. 5)

−	Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.C

−	Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (ggf. als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.

5)	Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.

Zeitpunkt T 3 − Entwurf der technischen Lösung

Als Ergebnis von Aktivität SE 2.1 sind die Bereiche der ersten Ausbaustufe in ihrer technischen Umsetzung (in der Systemarchitektur und den Technischen Anforderungen) beschrieben.

Die Beschreibung der Systemarchitektur im objektorientierten Bereich erfolgt über Klassenhierarchien. Dabei werden die Klassen und Objekte, die aufgrund der Anwenderanforderungen definiert wurden durch technische Klassen und Objekte ergänzt und zu einer objektorientierten Architektur zusammengefaßt. Hierbei ist die Anwenderorganisation als Einflußfaktor mit zu berücksichtigen.

Technische Klassen und Objekte können ergänzenden technischen Bereichen zugeordnet werden, z. B. Bereichen zur Daten- und Systemverwaltung, mit Mechanismen und Funktionen zur Unterstützung der Anwenderbereiche oder in solche mit Hilfsmitteln zur Softwareimplementierung.

Wie für die fachliche Strukturierung kann auch für die technische Strukturierung auf Klassenbibliotheken aufgesetzt werden.

Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE 1-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt.

Mit den Technischen Anforderungen und der Systemarchitektur liegen objektorientierte Modelle vor, die nahtlos als Vorgabe für die Implementierung verwendet werden können. Im Rahmen der Implementierung kann es aus technischen Gründen zur Formulierung neuer − technischer − Objekte kommen, die ergänzend in die Systemarchitektur und die technischen Anforderungen aufgenommen werden.

Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet.

Zeitpunkt T 4 bis T N-1 − Weitere Ausbaustufen

Zum Zeitpunkt T 4 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE 1.2 eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen Bereichen kommen.

Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Insbesondere werden die fachlichen objektorientierten Modelle fortgeschrieben und verfeinert. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.

Die damit in einer zweiten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.

Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.

Diese Arbeitsschritte werden für jedes Inkrement wiederholt.

Zeitpunkt T N − vollständige Systembeschreibung

Zum Zeitpunkt T N liegen Anwenderforderungen, Systemarchitektur und Technische Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung.


Zusammenspiel mit den übrigen Submodellen
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.5	Objektorientierte Entwicklung

SZ.5.2	Zusammenspiel mit den übrigen Submodellen

Das Zusammenspiel mit den übrigen Submodellen entspricht dem Szenario zur Anwendung des V-Modells bei einer inkrementellen Systementwicklung.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.5	Objektorientierte Entwicklung

SZ.5.3	Kriterien für die Auswahl des Szenarios

Die folgende Auflistung von Vor- und Nachteilen der objektorientierten Technologie unterstützt die Entscheidungsfindung zur Auswahl der objektorientierten Vorgehensweise.

Vorteile:

−	Objektorientierte Methoden zur Ermittlung der Anwenderanforderungen, Prototyping und iteratives Vorgehen ermöglichen eine intensive, stufenweise Einbeziehung des Anwenders in die Konkretisierung. Dadurch ist eine begleitende Validierung bereits während der Entwicklung möglich.

−	Objektorientiert entwickelte Systeme sind weniger empfindlich gegenüber Veränderungen als "strukturiert entwickelte Systeme".

−	Objektorientiert entwickelte Systeme sind leichter wartbar als "strukturiert entwickelte Systeme".

−	Die Ausdruckskraft der objektorientierten Programmiersprachen kann ausgenutzt werden.

Nachteile:

−	In objektorientiert entwickelten Systemen liegen zahlreiche Performance-Risiken. Diese können verschiedene Ursachen haben, angefangen bei der Verflechtung von Klassen, die tief im Vererbungsgitter angesiedelt sind bis zum dynamischen Aufbau und dem Löschen von Objekten. Dies ist besonders beim Aufbau sehr zeitkritischer Realzeitsysteme zu beachten.

−	Die Vertragsgestaltung muß Rücksicht nehmen auf sich ändernde und lückenhafte Anforderungen.

Voraussetzungen:

−	Qualifiziertes, OO-methodisch ausgebildetes Personal,

−	OO-Werkzeuge zur methodischen (CASE-Tools) und programmtechnischen Realisierung (Compiler für OO-Sprachen),

−	ein geeignetes organisatorisches Umfeld,

−	effizientes Konfigurations- und Änderungsmanagement,

−	Forderungscontrolling in allen Entwicklungszyklen,

−	Risikomanagement zu Beginn jedes Entwicklungszyklus,

−	angemessene und effiziente Maßnahmen zur Qualitätsprüfung sowohl von Anforderungen als auch von lauffähigen und prüfbaren HW-/SW-/System-Anteilen,

Die genannten Vor- und Nachteile sind jeweils im Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal für alle Projekte als gültig angesehen werden, sondern müssen vor dem Hintergrund der fachlichen und technischen Anforderungen sowie der zu beachtenden Randbedingungen geprüft werden.


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.6	Entwicklung wissensbasierter Systeme

SZ.6.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Charakteristisch für wissensbasierte IT-Systemen sind Anwenderforderungen, die zum Großteil als Regelbasis formulierbar sind. Es wird davon ausgegangen, daß neben diesen Teilen auch weitere, konventionell beschriebene und zu entwickelnde Anteile vorhanden sind.

Das Szenario zeigt, wie wissensbasierte und konventionelle Anteile parallel entwickelt werden und wie die Erstellung und schrittweise Verfeinerung der Regelbasis in die Aktivitätenfolge gemäß V-Modell integriert wird. Zusätzlich werden Hinweise zur Interpretation der Produktmuster (insbesondere für die Anwenderforderungen) gegeben.

Die Entwicklung wissensbasierter Systeme folgt der Strategie der inkrementellen Entwicklung, um die schrittweise Verbreiterung und Verfeinerung der Regelbasis im Dialog mit dem Anwender geeignet abbilden zu können.

Der Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme ist in Abbildung SZ.6 illustriert.

Vorbemerkungen:

−	Grundlage der nachfolgenden Beschreibungen ist das Szenario zur inkrementellen Systementwicklung.

−	Die Ergänzungen zur Entwicklung wissensbasierter Systeme sind kursiv dargestellt.

Abbildung SZ.6: Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme

Zeitpunkt T 0 − Start

Initialisierung des Projekts und Beginn der inhaltlichen Arbeiten gemäß Submodell SE.

Zeitpunkt T 1 − Erste Ausbaustufe

Als Ergebnis von Aktivität SE 1.2 liegt eine grobe Systembeschreibung vor, die den Kern und den Gesamthorizont für die Funktionalität des Systems beschreibt. Wissensbasierte Anteile sind hierbei auszuweisen, um den Geltungsbereich der Wissensbasis festlegen zu können.

Für einige der in Aktivität SE 1.5 identifizierten Bereiche (erste Ausbaustufe) sind die fachlichen Anforderungen zum Teil vollständig (Bereich 1), zum Teil unvollständig (Bereich 2) erstellt.

Die Darstellung der Funktionalität der wissensbasierten Anteile geschieht als Regelbasis, die bereichsüberschreitend erarbeitet wird. Die Regelbasis füllt das Kapitel "Anforderungen an die Funktionalität" als Teil der "Fachlichen Anforderungen".

Die Ergebnisse der Aktivitäten SE 1.2 und SE 1.5 bilden zusammen die Anwenderforderungen, die zum Zeitpunkt T 1 in einer ersten Version vorliegen.

Die Anwenderforderungen müssen so detailliert sein, daß folgende Ziele erreicht werden:

−	Alle relevanten fachlichen Bereiche müssen möglichst benannt und in ihrem Funktionsumfang gegeneinander abgegrenzt werden. 6)

−	Das Zusammenspiel der Bereiche muß für die Projektbeteiligten klar dargestellt sein.

−	Es muß klar sein, in welchen (bereichsspezifischen) Stufen das System aufwachsen soll und welche Gesamtfunktionalität im Endausbau abgedeckt werden soll. Dazu müssen Meilensteine (gegebenenfalls als Baseline mit Zeitpunkt und Funktionsumfang) angegeben werden.

−	Die wissensbasierten Anteile müssen ausgewiesen sein.

6)	Es ist möglich, daß neue fachliche Bereiche im Laufe der Entwicklung hinzugefügt werden. Dies kann aus vertragsrechtlichen Gründen problematisch sein.

Als Ergebnis von Aktivität SE 2.1 sind die Bereiche der ersten Ausbaustufe in ihrer technischen Umsetzung (in der Systemarchitektur und den Technischen Anforderungen) beschrieben.

Die einzelnen Bereiche werden soweit detailliert und ausgearbeitet, wie es für die erste produktive Systemversion notwendig ist. In späteren Stufen können die einzelnen Bereiche verfeinert und um neue ergänzt werden.

Durch die Berücksichtigung von technischen Lösungen im Rahmen der SE 1-Aktivitäten entsteht eine fachlich fundierte und ausreichend spezifizierte Vorgabe für die Realisierung der ersten Ausbaustufe durch einen Auftragnehmer. Die Systemarchitektur und die Technischen Anforderungen werden ergänzt und alle weiteren, realisierungsspezifischen Dokumente und Entwicklungsergebnisse erstellt. Nach Abschluß der Realisierung wird die erste Ausbaustufe in die Nutzung übergeleitet.

Für den wissenbasierten Anteil ist mit der Regelbasis (Teil der fachlichen Anwenderforderungen) im Normalfall bereits ein relevanter Anteil der Implementierung vorgegeben. Jedoch ist auch eine Regelbasis im Rahmen des Grobentwurfs zu modularisieren und im Rahmen des Feinentwurf zu beschreiben. Dies ist unabhängig von der gewählten Darstellungssprache.

Für den konventionellen Anteil erfolgt die Entwicklung parallel zum wissensbasierten Anteil. Beide Anteile werden im Rahmen der Integrationsschritte zusammengefügt.

Zeitpunkt T 2 bis T N-1 − Weitere Ausbaustufen

Zum Zeitpunkt T 2 liegt als Ergebnis der wiederholten Durchführung von Aktivität SE 1.2 eine verfeinerte Version der groben Systembeschreibung vor. Die Verfeinerungen bewegen sich im Normalfall im Rahmen des Gesamthorizonts, der bereits zum Zeitpunkt T 1 definiert wurde. Sie stellen eine Präzisierung der Anforderungen dar. Es kann durch solche Verfeinerungen jedoch auch zu neuen (wissensbasierten und konventionellen) Bereichen kommen.

Für die Bestandteile der zweiten Ausbaustufe werden die fachlichen Anforderungen erarbeitet. Dabei können bisher nicht berücksichtigte Bereiche neu beschrieben und bereits vorhandene verfeinert werden. Insbesondere wird die Regelbasis der wissensbasierten Anteile fortgeschrieben und verfeinert. Erste Rückmeldungen aus der Nutzung der ersten Ausbaustufe werden berücksichtigt.

Die damit in einer zweiten Version vorliegenden Anwenderforderungen bilden den Ausgangspunkt für die Verfeinerung und Ergänzung der Systemarchitektur und der Technischen Anforderungen.

Der Realisierer, beispielsweise ein Auftragnehmer, erweitert die bereits produktive Systemversion 1 um die neu hinzugekommenen Teile und integriert sie im Rahmen der Integrationsschritte. Eventuell sind im Rahmen der Integrationsarbeiten auch Änderungen an der Systemversion 1 durchzuführen. Nach Abschluß der Realisierung wird auch die zweite Ausbaustufe in die Nutzung übergeleitet.

Diese Arbeitsschritte werden für jedes Inkrement wiederholt.

Zeitpunkt T N − vollständige Systembeschreibung

Zum Zeitpunkt T N liegen Anwenderforderungen, Systemarchitektur und Technische Anforderungen vollständig und konsistent vor. Nach Realisierung und Überleitung der letzten Ausbaustufe in die Nutzung befindet sich das komplette System in der Nutzung.


Zusammenspiel mit den übrigen Submodellen
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.6	Entwicklung wissensbasierter Systeme

SZ.6.2	Zusammenspiel mit den übrigen Submodellen

Das Zusammenspiel mit den übrigen Submodellen entspricht ohne Änderungen dem Szenario zur Anwendung des V-Modells bei einer inkrementellen Systementwicklung.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.6	Entwicklung wissensbasierter Systeme

SZ.6.3	Kriterien für die Auswahl des Szenarios

Die folgende Auflistung von Vor- und Nachteilen und die Nennung der wichtigsten Voraussetzungen unterstützt die Entscheidungsfindung zur Auswahl der dargestellten inkrementellen Vorgehensweise zur Entwicklung wissensbasierter Systeme.

Vorteile:

−	Anwendernahe Modellierung von fachlichen Anforderungen, die geeignet als Regelbasis darstellbar sind,

−	flexible Änderung von Regelbasen und nahtloser Übergang in die Realisierungsschritte,

−	frühzeitige Auslieferung eines Basissystems und dadurch frühzeitiger Einsatz eines operablen Systemkerns beim Anwender,

−	Priorisierung der Lieferreihenfolge durch den Anwender (ev. auf der Basis von Erfahrungen mit den ersten ausgelieferten Systemteilen),

−	einfacher Austausch von Systemteilen (nämlich den Inkrementen) im Pflege- und Änderungsfall,

−	problemloser Wechsel des Auftragnehmers nach Abschluß der Realisierung eines Inkrements,

−	Verfeinerung der Anwenderforderungen im Laufe der Entwicklung (die Anwenderforderungen müssen zu Beginn nicht vollständig vorliegen),

−	deutlich kürzere Zyklen bei Änderung von Anwenderforderungen gegenüber konventioneller Entwicklung.

Nachteile:

−	In der Praxis ergibt sich immer eine Mischung aus wissensbasierten und konventionellen Anteilen, die parallel entwickelt werden müssen. Die obengenannten Vorteile einer rein wissensbasierten Lösung sind daher gegebenenfalls zu relativieren.

−	ungünstiges Laufzeitverhalten bei regelbasierten Lösungen im Vergleich zu konventionellen Lösungen,

−	inflexible Reaktion auf unvorhergesehene Änderungen, wenn ausgelieferte Systemteile oder deren Schnittstellen betroffen sind,

−	Notwendigkeit der frühzeitigen Festschreibung des Gesamthorizonts für die gesamte Entwicklungszeit.

Voraussetzungen:

−	Anwenderforderungen, die als Regelbasis geeignet modelliert werden können,

−	Separierbarkeit des Systems bei klaren Schnittstellen (modularer Aufbau der Systemarchitektur).

Die genannten Vor- und Nachteile sind jeweils im Einzelfall zu überprüfen und zu bewerten. Sie dürfen nicht pauschal für alle Projekte als gültig angesehen werden, sondern müssen vor dem Hintergrund der fachlichen und technischen Anforderungen sowie der zu beachtenden Randbedingungen geprüft werden.


Ablaufbeschreibung für die Aktivitäten im Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.7	Pflege und Änderung

SZ.7.1	Ablaufbeschreibung für die Aktivitäten im Submodell SE

Pflege/Änderung (PÄ) beinhaltet die Durchführung von Pflege- und Änderungsmaßnahmen während der Nutzung. Die Pflege des Systems hat die Erhaltung der Funktionsfähigkeit zur Aufgabe, d. h. die Behebung von Fehlern und Mängeln, sowie die Durchführung von Optimierungen, ohne daß eine Modifikation an den Anwenderforderungen, der Systemarchitektur oder den Technischen Anforderungen erforderlich ist. Änderungen des Systems dagegen haben immer auch eine Modifikation oben genannter Dokumente mit zum Inhalt (Weiterentwicklung des Systems).

Modifikationen am System werden durch Änderungsanträge/Problemmeldungen angezeigt.

Eingehende Änderungsanträge/Problemmeldungen können einerseits zu einem eigenständigen Pflege/Änderungsprojekt führen (d. h. ein Projekt ist entsprechend den Regelungen des Submodells PM zu initialisieren) oder andererseits im Rahmen des Änderungsmanagements (Aktivität KM 3) eines bereits laufenden PÄ-Projekts abgearbeitet werden.

Charakteristisch für PÄ-Projekte ist der Umstand, daß die durchzuführenden Aktivitäten auf bereits existierenden Produkten aufsetzen.

Bei der Überarbeitung der Produkte sind generell zwei Vorgehensweisen möglich:

a)	Modifikation im Produkt
Ergebnis: neues Produkt

b)	Modifikation in einem zusätzlichen Produkt mit Bezug zum ursprünglichen Produkt
Ergebnis: Produkt plus Zusatz

In beiden Fällen entsteht eine neue Version des Produkts. Welche Vorgehensweise für das PÄ-Projekt gewählt ist, ist im KM-Plan des Projekts festzulegen. Abbildung SZ.7 skizziert die beiden Möglichkeiten der Fortschreibung der Produkte.

Der Ablauf der SE-Aktivitäten bei der Durchführung einer Pflege/Änderung ist in Abbildung SZ.8 illustriert.

Abbildung SZ.7: Vorgehensweisen bei der Produktfortschreibung

Abbildung SZ.8: Ablauf der SE-Aktivitäten bei der Durchführung einer Pflege/Änderung

Vorbemerkungen:

−	Im folgenden wird die Bearbeitung eines Änderungsantrags behandelt. In der Praxis ist es durchaus möglich, mehrere Änderungsanträge gleichzeitig zu bearbeiten.

−	Es wird davon ausgegangen, daß der Änderungsantrag die Entwicklung einer zusätzlichen Funktionalität und die Integration der Erweiterung in das bestehende System zum Inhalt hat.

−	Das nachfolgende Szenario illustriert die Umsetzung des Änderungsantrags in mehreren Ausbaustufen (inkrementelle Vorgehensweise).

Zeitpunkt T 0 − Start

Initialisierung des PÄ-Projekts und Beginn der Durchführung der Pflege-/Änderungsmaßnahmen im Submodell SE. Ausgangspunkt ist die aus dem Entwicklungsprojekt übernommene Dokumentation des existierenden Systems. Die gemäß Änderungsantrag durchzuführenden SE-Aktivitäten sind im Änderungsauftrag identifiziert.

Zeitpunkt T 1 − Erste Ausbaustufe

Die Anwenderforderungen sind fortgeschrieben und liegen in Version 2 vor. Der "Gesamthorizont" der geforderten Änderung ist in der groben Systembeschreibung berücksichtigt. Für die Teile, die in einer ersten Ausbaustufe realisiert werden sollen (Bereich 3), sind die fachlichen Anforderungen vollständig festgelegt. Systemarchitektur und Technische Anforderungen sind entsprechend ergänzt und liegen in einer zweiten Version vor.

Die Überleitung der ersten Ausbaustufe ist nach ihrer Realisierung und Integration in das bestehende System zum Zeitpunkt T 1 erfolgt.

Zeitpunkt T 2 − Abschluß der Pflege/Änderung

Die zusätzlichen Anwenderforderungen, die der Änderungsauftrag bedingt hat, sind vollständig realisiert und das neue System in die Nutzung übergeleitet. Der Änderungsantrag ist damit vollständig bearbeitet. Im Rahmen dieser zweiten Ausbaustufe wurde ein weiterer Änderungsantrag berücksichtigt, der eine Ergänzung des bereits in der ersten Ausbaustufe realisierten Bereichs 3 zur Folge hatte.


Zusammenspiel der Submodelle SE und PM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.7	Pflege und Änderung

SZ.7.2	Zusammenspiel mit den übrigen Submodellen

SZ.7.2.1	Zusammenspiel der Submodelle SE und PM

Die Aktivitäten des Submodells PM sind in einem PÄ-Projekt ebenso durchzuführen wie in einem Entwicklungsprojekt. Die Vorgaben des SWPÄ-Konzepts (z. B. zur Projektorganisation) sind bei der Projektinitialisierung zu berücksichtigen.

Die Festlegungen bezüglich Methoden und Werkzeugen sowie Standards und Richtlinien im Projekthandbuch des Entwicklungsprojekts sind für das PÄ-Projekt zu übernehmen. Gegebenenfalls ist eine Anpassung/Ergänzung vorzunehmen (Aktivität PM 1.4 "Toolset-Management").

Sofern in dem PÄ-Projekt mehrere Änderungsanträge/Problemmeldungen zu bearbeiten sind, obliegt dem Submodell PM die Planung, Steuerung und Kontrolle der in den Änderungsaufträgen identifizierten Aktivitäten.


Zusammenspiel der Submodelle SE und QS
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.7	Pflege und Änderung

SZ.7.2	Zusammenspiel mit den übrigen Submodellen

SZ.7.2.2	Zusammenspiel der Submodelle SE und QS

Die im Rahmen des PÄ-Projekts geänderten Produkte sind im Submodell QS zu prüfen. Die Prüfspezifikationen und Prüfprozeduren des Entwicklungsprojekts können als Ausgangsdokumente verwendet werden, sind jedoch bezüglich der geänderten SE-Produkte anzupassen.


Zusammenspiel der Submodelle SE und KM
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.7	Pflege und Änderung

SZ.7.2	Zusammenspiel mit den übrigen Submodellen

SZ.7.2.3	Zusammenspiel der Submodelle SE und KM

Die Übernahme der SE-Produkte aus dem Entwicklungsprojekt in das PÄ-Projekt ist Aufgabe des Konfigurationsmanagements (Aktivität KM 1.2 "KM einrichten"). Es handelt sich hierbei neben den SE-Produkten auch um die Produkte der Submodelle QS, KM und PM.

Die Vorgehensweise bezüglich der Fortschreibung der Produkte wird im KM-Plan geregelt.

Die bereits in Nutzung befindliche Systemkonfiguration wird von KM verwaltet.

Das Konfigurationsmanagement dient als zentrale Sammelstelle für alle eingehenden Änderungsanträge/Problemmeldungen. Änderungsvorschlag und Änderungsauftrag werden in Aktivität KM 3 "Änderungsmanagement (Konfigurationssteuerung)" erstellt. Der Änderungsauftrag ist Grundlage der im Submodell SE durchzuführenden Aktivitäten.

Gegebenenfalls werden von KM die bekannten Änderungs- und Fehlermeldungen in einem Berichtsdokument zur Unterstützung der Nutzer gesammelt und gepflegt.


Kriterien für die Auswahl des Szenarios
Teil 3	Vorgehensmodell / Handbuchsammlung

SZ	Szenarien

SZ.7	Pflege und Änderung

SZ.7.3	Kriterien für die Auswahl des Szenarios

Das Szenario ist anzuwenden, wenn Änderungsanträge/Problemmeldungen während der Nutzung eines Systems bearbeitet werden sollen. Die folgenden Voraussetzungen müssen gegeben sein:

−	Abschluß der Systementwicklung, d. h. das System ist bereits in der Nutzung,

−	Vorliegen des SWPÄ-Konzepts,

−	Verfügbarkeit aller relevanten Produkte aus dem Entwicklungsprojekt in aktueller und konsistenter Form.


Abbildungsverzeichnis AU250/3 - SZ
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - SZ)

A.1	Abbildungsverzeichnis

Abbildung SZ.1:	Ablauf der SE-Aktivitäten bei einer inkrementellen Entwicklung

Abbildung SZ.2:	PM-Zyklus bei einer inkrementellen Entwicklung

Abbildung SZ.3:	Ablauf der SE-Aktivitäten beim Grand Design

Abbildung SZ.4:	Ablauf der SE-Aktivitäten bei einem Einsatz von Fertigprodukten

Abbildung SZ.5:	Ablauf der SE-Aktivitäten bei einer objektorientierten Entwicklung

Abbildung SZ.6:	Ablauf der SE-Aktivitäten bei der Entwicklung wissensbasierter Systeme

Abbildung SZ.7:	Vorgehensweisen bei der Produktfortschreibung

Abbildung SZ.8:	Ablauf der SE-Aktivitäten bei der Durchführung einer Pflege/Änderung


Gründe und Ziele
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.1	Gründe und Ziele

Das V-Modell als die Basis für die technische Abwicklung eines Projekts zeichnet sich durch Allgemeingültigkeit aus. Es ist unabhängig vom Einsatzbereich. Diese Allgemeingültigkeit bedingt aber, daß nicht alle enthaltenen Regelungen für jedes beliebige Projekt relevant sind, wie mit folgenden Schema beispielhaft verdeutlicht wird:

Abbildung T.1: Beispiel für die unterschiedliche Relevanz von Regelungen

Um für ein konkretes Projekt das V-Modell anwendbar zu machen, muß deshalb zunächst entschieden werden:

−	Welche Aktivitäten sind für die Durchführung des Projekts erforderlich?

−	Welche Produkte müssen im Rahmen der Projektabwicklung erzeugt werden?

Die damit verbundene Streichung nicht relevanter Aktivitäten und Produkte wird als Tailoring bezeichnet. Hauptanliegen des Tailoring ist es, für jedes Projekt zu gewährleisten, daß der eingesetzte Aufwand den Projektzielen dienlich ist. Zu vermeidende Probleme sind:

−	übermäßige Papierflut,

−	sinnlose Dokumente, aber auch

−	das Fehlen wichtiger Dokumente!

Dies wird durch die Reduzierung der allgemeingültigen (generischen) Regelungen des V-Modells auf die aus sachlichen Gründen erforderlichen Regelungen erreicht. Die entstehende Teilmenge des V-Modells ("projektspezifisches V-Modell") ist neben der Beschreibung des Projektes, seiner Organisation und seiner Ziele Hauptbestandteil des Projekthandbuchs (PHb).

Das V-Modell kann als Checkliste angesehen werden, die eine große Menge erprobter und sinnvoller Regelungen enthält. Für jedes Einzelprojekt wird aus diesem Angebot eine Teilmenge ausgewählt. Das V-Modell kann daher auch als ein "Baukasten" angesehen werden, aus dem im Rahmen des Tailoringvorgangs die für ein Projekt geeigneten Bausteine (Aktivitäten/Produkte) herausgenommen werden.


Projektspezifische Anpassung des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

Die Anpassung des generischen V-Modells an das konkrete Projekt erfolgt über nachstehende Schritte:

−	Erstellung des projektspezifischen V-Modells
Die Aktivitäten- und Produktklassen, die für das Projekt sinnvoll sind, werden bestimmt. Dabei kann zwischen zwei Verfahren unterschieden werden:

1.	Standardisiertes Vortailoring oder

2.	Tailoring mit Streichbedingungen.

Weiterhin werden die Gründe für durchgeführte Streichungen und die Bedingungen für die Zulässigkeit künftiger Streichungen (Streichbedingungen) benannt. Diese werden bei der Projektplanung (Feinplanung) ausgewertet. Bei der Auswahl der Aktivitäten- und Produktklassen sind Mindestanforderungen zu berücksichtigen, die in jedem Projekt einzuhalten sind.

−	Prüfung des projektspezifischen V-Modells
Die durchgeführten Streichungen, die zu dem projektspezifischen V-Modell führten, sind auf ihre Nachvollziehbarkeit zu prüfen. Dabei ist zu prüfen, ob die Mindestanforderungen eingehalten sind bzw. Abweichungen ausreichend begründet sind. Das Modell selbst ist auf seine Konsistenz im Sinne der "Ausführbarkeit" zu untersuchen.

−	Dokumentation des projektspezifischen V-Modells
Zunächst wird einmal die Form des projektspezifischen V-Modells festgelegt, d. h. in welcher Weise das projektspezifische V-Modell die Aktivitäten und Produkte beschreibt. Dazu gibt es zwei Möglichkeiten: Die Aktivitäten und Produkte des projektspezifischen V-Modells

1.	verweisen auf die Beschreibungen des generischen V-Modells oder

2.	enthalten die vollständige Darstellung des V-Modells.

Im Falle der Übernahme der Beschreibungstexte aus dem V-Modell kann eine Anpassung der Texte erfolgen.

Die genannten Schritte werden unter dem Begriff Ausschreibungsrelevantes Tailoring 1) zusammengefaßt.

1)	Dieser erste Schritt ist auch auszuführen, wenn das Ergebnis nicht für eine Ausschreibung, sondern z. B. für die Leistungsbeschreibung einer internen Entwicklungsbeauftragung verwendet werden soll.


Erstellung des projektspezifischen V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

Zu Beginn eines Projekts müssen die für ein Projekt sinnvollen bzw. erforderlichen Tätigkeiten und Produkte ermittelt werden. Damit wird entschieden, welche Teile aus dem Angebot des V-Modells generell im Projekt anzuwenden sind und welche Teile für das Projekt nicht sinnvoll sind. Hier wird für das Projekt eine prinzipielle Entscheidung getroffen. Die Aktivitäten und Produkte werden im Kapitel "Projektspezifisches V-Modell" des Projekthandbuchs dokumentiert. Die Gründe, die zu dieser Entscheidung führten, werden als Streichbedingungen im Kapitel "Übersicht" des Projekthandbuchs (markiert mit "AT") aufgenommen.

Während des Projektverlaufes ist es sinnvoll, noch weitere Freiräume für das Weglassen von Aktivitäten und Produkte zuzulassen. Im Rahmen der Aktivität PM 4 "Feinplanung" werden für den bevorstehenden Planungsabschnitt die generell für das Projekt vorgesehenen Aktivitäten und Produkte identifiziert. Unter bestimmten Gründen (situationsbedingte Gründe) können einzelne Aktivitäten und Produkte wegfallen. Diese Form der Anpassung wird Technisches Tailoring genannt. Die Gründe (markiert mit "TT") sind bereits zu Beginn des Projekts festzulegen, damit unbegründete und willkürliche Abweichungen während des Projektverlaufs gegenüber den Projektvorstellungen ausgeschlossen sind. Diese Gründe sind als Streichbedingungen im Kapitel "Übersicht" des Projekthandbuchs festzuhalten.

Abbildung T.2 skizziert die Anwendungsumgebung des Tailoring. Die einmalige Anwendung der Tailoringverfahren zu Beginn des Projektes − das sogenannte Ausschreibungsrelevante Tailoring − führt zur Festlegung des projektspezifischen V-Modells und zur Festlegung der für das Technische Tailoring relevanten Streichbedingungen. Das Technische Tailoring wird dann auf der Basis der TT-Streichbedingungen innerhalb der Feinplanung des Projekts wiederholt durchgeführt.

Die zwei Verfahren zur Bestimmung der für das Projekt relevanten Aktivitäten und Produkte

1.	Standardisiertes Vortailoring und

2.	Tailoring mit Streichbedingungen

werden im weiteren näher vorgestellt. Voraussetzung für diese Verfahren ist die Berücksichtigung der Mindestanforderungen.

Abbildung T.2: Anwendung des Tailoring


Berücksichtigung der Mindestanforderungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.1	Berücksichtigung der Mindestanforderungen

Bei der Auswahl der projektspezifischen Aktivitäten und Produkte wird vorausgesetzt, daß bestimmte Mindestanforderungen eingehalten werden, so daß die entsprechenden Aktivitäten im allgemeinen Falle nicht durch Tailoring entfallen können. Liegen die von einer Aktivität geforderten Produkte bereits vor, so kann die Aktivität gestrichen werden, ohne die Mindestanforderungen zu verletzen.

Die Mindestanforderungen ergeben sich aus dem grundsätzlichen Verständnis der Regelungen für die Auftragsabwicklung sowie z. B. aus Forderungen der ISO 900x. Abweichungen von den Mindestanforderungen sind projektspezifisch zu begründen.

Hinweis:
Wenn im folgenden Aktivitäten des V-Modells aufgeführt werden, die als Mindestanforderungen in jedem Projekt durchzuführen sind, so ist dabei die Angemessenheit der Durchführung zu beachten. Das bedeutet, daß in kleinen Projekten die Durchführung zwar erforderlich ist, aber der Aufwand nicht aufgebläht werden darf. Insbesondere werden in diesem Falle die resultierenden Produkte ein angemessen geringes Volumen haben.

Im folgenden werden die Mindestanforderungen für die vier Submodelle aufgeführt:

SE 1.2	Anwendungssystem beschreiben Die Anwenderforderungen repräsentieren die Sicht des Anwenders auf das geplante System. Insofern bilden sie den einzigen Bezugspunkt für die Zielerreichung der gesamten Systementwicklung. Sie sind auch die Grundlage für die Abnahme des Systems.
SE 2.1	System technisch entwerfen Die Festlegung einer technischen Struktur des Systems ist in jedem Projekt erforderlich. Die Zerlegung des Systems führt zu kleineren Bausteinen und trägt somit zu einer Reduzierung der Komplexität bei.
SE 3.4	Anforderungen an die Qualität der SW-/HW-Einheit definieren Anforderungen an die Qualität sind Voraussetzung dafür, daß Produktprüfungen überhaupt sinnvoll durchgeführt werden können: Jede Prüfung soll schließlich die Erfüllung definierter Forderungen nachweisen.
SE 4.1-SW	SW-Architektur entwerfen Eine definierte SW-Architektur ist Voraussetzung für die Anwendung erfolgreicher Teststrategien wie Schnittstellentest, Whitebox-Test, Fehlerfortpflanzungsanalyse.
SE 6-SW	SW-Implementierung Die eigentliche Erzeugung ablauffähigen Codes ist grundsätzlich unverzichtbar, auch wenn hier als Hilfsmittel Codegeneratoren eingesetzt werden, d. h. die Aktivitäten SE 6.1-SW und/oder SE 6.2-SW sind durchzuführen.
SE 7.3-SW	Zur SW-Einheit integrieren Die Zusammenführung der in Aktivität SE 4.1-SW definierten Elemente zu einer SW-Einheit muß in einem nachvollziehbaren Prozeß geschehen, damit die Bestandteile des integrierten Objekts jederzeit hinsichtlich Versionsstand, Testzustand u. ä. identifiziert werden können.
SE 8.1	Zum System integrieren Die Notwendigkeit dieser Aktivität ergibt sich analog Aktivität SE 7.3-SW.
Tabelle T.1:	Mindestanforderungen im Submodell SE

QS 1.1	QS-Plan erstellen Der QS-Plan bildet die Grundlage für die Qualitätssicherung und ist somit für jedes Projekt unerläßlich.
QS 2.1	Prüfmethoden und -kriterien festlegen Eine ordnungsgemäße Prüfung von Dokumenten ist nur anhand definierter Prüfkriterien möglich. Mindestens sind Prüfkriterien zur Prüfung der Anwenderforderungen und Systemarchitektur erforderlich.
QS 2.3	Prüffälle festlegen Eine ordnungsgemäße Prüfung von Software ist nur anhand definierter Prüffälle möglich. Mindestens ist das fertiggestellte System zu prüfen.
QS 4.2	Produkt inhaltlich prüfen Anwenderforderungen, Systemarchitektur und System sind mindestens zu prüfen. Die Ergebnisse der Prüfungen sind in Prüfprotokollen zu dokumentieren.
KM 1.1	KM-Plan erstellen Der KM-Plan bildet die Grundlage für das gesamte Konfigurationsmanagement und ist somit unerläßlich für jedes Projekt.
PM 1.3	Projektspezifisches V-Modell erstellen Eine sinnvolle Anwendung des V-Modells ist nur möglich, wenn eine projektspezifische Anpassung erfolgt. Dies wird im Projekthandbuch dokumentiert. Das Projekthandbuch ist als Grundlage zur Projektsteuerung unerläßlich.
PM 1.4	Toolset-Management durchführen Die Festlegung von Methoden und Werkzeugen sowie Standards und Richtlinien im Projekthandbuch ist Grundlage für die gesamte Projektabwickung.
PM 1.5	Grobplan erstellen Eine nachvollziehbare Projektplanung ist Voraussetzung für jegliche strukturierte Vorgehensweise im Projekt, insbesondere auch für die Erfolgskontrolle an definierten Meilensteinen. Die erforderliche Detaillierung der Planung hängt von den Projektgegebenheiten ab. Es müssen aber in jedem Falle die Aspekte "Gesamtplanung / Meilensteinplanung" und "Planung einzelner Aufgaben" berücksichtigt werden.
PM 4	Feinplanung Die Planung ist im Projektverlauf fortzuschreiben.
PM 8	Projektkontrolle und -steuerung Ohne Projektfortschrittskontrollen sind keinerlei Aussagen über den tatsächlichen Projektzustand möglich. Sie sind deshalb als regelmäßig (periodisch) durchzuführende Aktivität unverzichtbar. Darüber hinaus müssen alle Maßnahmen, die der Anpassung der Projektabwicklung an eine veränderte Situation dienen, in nachvollziehbarer Weise durchgeführt werden.
Tabelle T.2:	Mindestanforderungen in den Submodellen QS, KM und PM.

Hinweis:
Die Tailoringverfahren "Standardisiertes Vortailoring" und "Tailoring mit Streichbedingungen", die in den weiteren Abschnitten beschrieben sind, berücksichtigen die o. g. Mindestanforderungen.


Standardisiertes Vortailoring
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.2	Standardisiertes Vortailoring

Dieser Ansatz geht von der Idee aus, daß sich Vorhaben mit ähnlichen Charakteristiken in Vorhabenklassen zusammenfassen lassen.

Folgende Vorhabenklassen sind definiert:

−	Administrative Vorhaben,

−	Technisch-wissenschaftliche Vorhaben,

−	Auswahl, Beschaffung und Anpassung von Fertigprodukten.

Um zu einer für das Standardisierte Vortailoring geeigneten Typisierung zu kommen, ist es für die ersten beiden Klassen erforderlich, die Vorhabengröße zu unterscheiden.

Damit ergeben sich die folgenden Vorhabentypen, für die derzeit ein standardisiertes Vortailoring existiert:

−	kleine administrative IT-Vorhaben

−	mittlere administrative IT-Vorhaben

−	große administrative IT-Vorhaben

−	kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

−	große technisch-wissenschaftliche IT-Vorhaben

−	Auswahl, Beschaffung und Anpassung von Fertigprodukten

Diese Vorhabentypen werden in Abschnitt T.3 "IT-Vorhabentypen" näher charakterisiert und beschrieben.

Die folgende Abbildung verdeutlicht die Aufteilung:

Abbildung T.3: Klassifizierung der Vorhabentypen

Ziel des Standardisierten Vortailoring ist es, durch Anwendung vorgegebener Formblätter auf möglichst einfache Weise unter Berücksichtigung von Vorhabentyp und spezifischen Ergänzungen den maßgeschneiderten Regelungsumfang zu ermitteln. Es werden Formblätter zur Verfügung gestellt (siehe Abschnitt T.3.6), für deren Auswahl lediglich der Vorhabentyp für das gerade zu bearbeitende Vorhaben ausgewählt werden muß.

Die in den Formblättern enthaltenen Basisregelungen können für folgende Situationen ergänzt werden (vgl. Abschnitt T.3.1 "Merkmale mit ihren Quantifizierungen"):

a)	Es ist eine Kritikalitätsstufung (mit mindestens zwei Stufen) vorgenommen worden.

b)	Es werden Datenbanken eingesetzt.

c)	Es liegt eine besonders hohe Komplexität der Funktionalität vor.

d)	Die Datenstrukturen sind besonders komplex.

e)	Die Wartbarkeitsanforderungen sind besonders hoch.

In den Formblättern sind für die einzelnen Ergänzungen Zusatzregelungen angegeben. Durch die Auswahl des Vorhabentyps und der notwendigen Ergänzungen kann in erster Näherung ein PHb erstellt werden.

Es wird empfohlen, den so definierten Regelungsumfang nochmals vor dem Hintergrund der konkreten Projektsituation zu prüfen und gegebenenfalls begründete Streichungen oder Erweiterungen vorzunehmen.


Tailoring mit Streichbedingungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.3	Tailoring mit Streichbedingungen

Anhand einer aus der Erfahrung aufgestellten Menge von Streichbedingungen kann das Tailoring von Aktivitäten und Produkten durchgeführt werden. Weitere Streichbedingungen können jederzeit hinzugenommen werden. Ziel ist es, die Auswahl der Aktivitäten und Produkte begründet festzuhalten. Eine Streichbedingung besteht u. a. aus:

−	Bezug auf Aktivität bzw. Produkt (Verweis)

−	Streichgrund (Text)

Beispiel: Ausschreibungsrelevante Streichbedingung

SE 1.6 ("Bedrohung und Risiko analysieren") ist im V-Modell als Aktivität aufgeführt. Im aktuellen
Projekt muß diese Aktivität nicht beachtet werden, da grundsätzlich die Regelungen des
Grundschutzes beachtet werden (z. B. auf der Ebene der Anwenderorganisation generell
sichergestellt) und weder eingestufte noch personenbezogene Daten verarbeitet werden.

Im Kapitel "Übersicht" des PHb wird folgendes dokumentiert:

SE 1.6 Bedrohung und Risiko analysieren

AT	entfällt, weil:
Die Regelungen des Grundschutzes werden beachtet (auf der Ebene der Anwenderorganisation
generell sichergestellt), und weder eingestufte noch personenbezogene Daten werden verarbeitet.

Beispiel: Technische Streichbedingung

SE 5.2-SW ("Betriebsmittel- und Zeitbedarf analysieren") wurde zu Projektbeginn als prinzipiell
sinnvoll eingestuft und in das Kapitel "Projektspezifisches V-Modell" des Projekthandbuches
aufgenommen. Die im aktuellen Planungsabschnitt zu entwickelnden SW-Module verwenden
nur einen geringen Bruchteil der vorhandenen Ressourcen. Offensichtlich ist es nicht sinnvoll,
Aktivität SE 5.2-SW für diese SW-Module auszuführen. Um abweichend vom PHb auf
Aktivität SE 5.2-SW verzichten zu können, wurde dort vermerkt, daß Aktivität SE 5.2-SW
zwar prinzipiell (z. B. weil für einige Fälle bereits absehbar) für die angemessene
Projektabwicklung notwendig ist, aber im Fall offensichtlich ausreichender Ressourcen
entfallen kann. Dies verhindert eine "Über-Regelung" des Projekts und vermeidet sinnlose
Dokumente.

Im Kapitel "Übersicht" des PHb wird folgendes dokumentiert:

SE 5.2-SW Betriebsmittel- und Zeitbedarf analysieren

TT	entfällt, wenn:
Das betrachtete SW-Modul beansprucht die vorhandenen Ressourcen nur in geringem Maße,
und dies wird im Rahmen der Moduldokumentation (SW-Entwurf) nachvollziehbar plausibel
gemacht (z. B. durch eine kurze Erläuterung).

Bei der Verwendung der Streichbedingungen wird der Grad der Zustimmung bzw. die Ablehnung des Streichgrunds für das Projekt festgelegt. Nachstehende Fälle werden unterschieden:

a)	Wird der Grund zur Streichung einer Aktivität für das Projekt verwendet, so ist er im Kapitel "Übersicht" des Projekthandbuchs mit "AT" markiert aufzunehmen. Die Aktivität wird im projektspezifischen V-Modell gestrichen.

b)	Soll der Grund zur Streichung einer Aktivität während des Projektverlaufes verwendet werden können, so ist er im Kapitel "Übersicht" des Projekthandbuchs mit "TT" markiert aufzunehmen. Die Aktivität ist in das projektspezifische V-Modell zu übernehmen.

c)	Wird der Grund nicht zur Streichung einer Aktivität für das Projekt verwendet, so kann er im Kapitel "Übersicht" mit "—" (nicht AT und nicht TT) markiert angegeben werden (optional), um eine Abgrenzung zu den zutreffenden Gründen mit zu berücksichtigen. Die Aktivität ist für das Projekt relevant und ist in das projektspezifische V-Modell aufzunehmen.

Ähnliche Aussagen gelten auch für Produkte. Können die Streichgründe aus Abschnitt T.4 aus der Sicht des Projekts nicht verwendet werden, so sind eigene anzugeben.

Abbildung T.4 zeigt den zeitlichen Verlauf bei der Auswahl der relevanten Streichbedingungen für ein Projekt.

Abbildung T.4: Anwendung der Streichbedingungen


Berücksichtigung von Entwicklungsstrategien beim Tailoring
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.4	Berücksichtigung von Entwicklungsstrategien beim Tailoring

Das V-Modell ermöglicht die Anwendung einer Reihe von alternativen Entwicklungsstrategien (siehe Handbuch "SZ"). Die Entwicklungsstrategie hat Einfluß auf die wiederholte Ausführung von Aktivitäten und damit auch auf die zunehmende Vervollständigung von Produkten. Sie hat jedoch wenig Einfluß auf die Auswahl der Aktivitäten. Wird durch die Wahl einer Entwicklungsstrategie eine Aktivität wiederholt ausgeführt, so ist die Aktivität im Projekthandbuch nur einmal aufzunehmen. Die wiederholte Ausführung der Aktivität muß jedoch in den Planungsaktivitäten des Submodells PM berücksichtigt werden.

Im folgenden wird die Auswirkung der Entwicklungsstrategie auf die durch die Mindestanforderungen geforderte Auswahl der Aktivitäten kurz dargestellt:

Inkrementelle Entwicklung: 	Keine

Grand Design:	Keine

Einsatz von Fertigprodukten:	Die Aktivitäten PM 2 und SE 1.7 müssen durchgeführt werden. Gegebenenfalls müssen auch Änderungen der Anwenderforderungen und der Systemarchitektur möglich sein. Je nach Art des Fertigprodukts entfallen bestimmte SE-Aktivitäten.

Objektorientierte Entwicklung:	Keine

Wissensbasierte Systeme:	Keine

Pflege und Änderung:	Ergänzung wichtiger KM-Aktivitäten (KM 1.2 und KM 3)

Bei den in diesem Handbuch vorgestellten Tailoringmechanismen spielt die Komplexität der Funktionen und der Daten eine wichtige Rolle. Funktionen und Daten werden getrennt voneinander betrachtet. Bei der Anwendung der objektorientierten Entwicklungsstrategie ist es eine Zielsetzung, eine Kapselung von Funktionen und Daten in Klassen und Objekten vorzunehmen und diese Trennung zu überwinden. Für die Komplexitätseinstufung ist es jedoch möglich, beide Aspekte weiterhin getrennt voneinander zu betrachten. Zur Einschätzung der Komplexität der Funktionalität können die den Klassen zugeordneten Operationen betrachtet werden. Für die Komplexität der Daten sind es die Klassen als Einheiten und ihre Attribute.


Anwendung der Tailoringverfahren
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.1	Erstellung des projektspezifischen V-Modells

T.2.1.5	Anwendung der Tailoringverfahren

Für die Erstellung des projektspezifischen V-Modells wird unter Verwendung der Tailoringverfahren folgendes Vorgehen vorgeschlagen:

1.	Vorhabenklasse ermitteln
Es ist festzustellen, zu welchem der drei Vorhabentypen das Vorhaben gehört:

−	administrative IT-Vorhaben,

−	technisch-wissenschaftliche IT-Vorhaben oder

−	Auswahl und Beschaffung von Fertigprodukten (Standardanwendungen).

Paßt keiner dieser Vorhabentypen auf das Vorhaben, so ist das Tailoring mit Streichbedingungen anzuwenden (weiter mit Punkt 5).

2.	Vorhabengröße ermitteln
Anhand der Klassifizierungsmerkmale für Vorhabengrößen ist festzustellen, welche Vorhabengröße vorliegt.

3.	Zugehöriges Formblatt auswählen
Das zum Vorhabentyp und der Vorhabengröße passende Formblatt ist auszuwählen (Abschnitt T.3.6). Damit sind zugleich die Basis-Aktivitäten und -Produkte festgelegt.

4.	Ergänzungen aus dem Formblatt wählen
Es ist zu prüfen, ob eine der Durchführungsbedingungen (Kritikalität größer, Datenbankanwendung, Funktions- und Datenkomplexität höher, Wartbarkeitsanforderungen höher) zutrifft. Entsprechend sind die zusätzlichen Aktivitäten und Produkte aus den zugehörigen Spalten/Zeilen zu entnehmen (weiter mit Punkt 7).

5.	Tailoring mit Streichbedingungen verwenden
Ist kein Vorhabentyp auswählbar bzw. sind noch weitere Modifikation notwendig, so können die Streichbedingungen aus Abschnitt T.4 herangezogen werden.

6.	Entwicklungsstrategie festlegen
Die Entwicklungsstrategie (siehe Handbuch "SZ") ist festzulegen.

7.	Projektspezifisches V-Modell prüfen
Die Gründe, die zu dem projektspezifischen V-Modell führten, sind auf ihre Nachvollziehbarkeit zu prüfen. Das Modell selbst ist auf seine Konsistenz im Sinne der "Ausführbarkeit" zu untersuchen (siehe Abschnitt T.2.2 "Prüfung des projektspezifischen V-Modells"). Es ist weiterhin festzustellen, ob die Mindestanforderungen aus Abschnitt T.2.1.1 "Berücksichtigung der Mindestanforderungen" eingehalten sind.

8.	Projektspezifisches V-Modell dokumentieren
Die für das Vorhaben als sinnvoll bzw. notwendig eingestuften Aktivitäten und Produkte sind in das zu erstellende Projekthandbuch (Kapitel "Projektspezifisches V-Modell") zu übernehmen. Hinweise auf Art und Weise der Dokumentation werden in Abschnitt T.2.3.1 "Aktivitäten- und Produktbeschreibungen" gegeben.

9.	Projektspezifische Streichbedingungen dokumentieren
Sowohl die Streichbedingungen, die zum projektspezifischen V-Modell führten, als auch die technischen Streichbedingungen für die Projektdurchführung sind im Kapitel "Übersicht" des Projekthandbuchs zu dokumentieren (siehe Abschnitt T.2.3.2 "Aufzeichnung der Streichbedingungen für das Projekt".

Die Vorgehensweise wird in Abbildung T.5 illustriert. Dabei ist anzumerken:

−	Die technischen Streichbedingungen werden nur durch das Verfahren "Tailoring mit Streichbedingungen" festgelegt. Werden keine technischen Streichungen für das Projekt bestimmt, werden keine weiteren Arbeitsfreiräume bei der Projektdurchführung zugelassen. Das V-Modell schreibt das Technische Tailoring nicht verbindlich vor.

−	Das Standardisierte Vortailoring kann zur ersten Auswahl der Aktivitäten und Produkte verwendet werden. Eine weitere Anpassung kann dann − falls notwendig − durch das Verfahren "Tailoring mit Streichbedingungen" erfolgen.

−	In dem Fall, in dem kein Vorhabentyp für das Projekt ausgewählt werden kann, ist das Verfahren "Tailoring mit Streichbedingungen" anzuwenden. Damit können gleichzeitig die ausschreibungsrelevanten und die technischen Streichbedingungen bestimmt werden.

Abbildung T.5: Erstellung, Prüfung und Dokumentation des projektspezifischen V-Modells

Die Verfahren Standardisiertes Vortailoring und Tailoring mit Streichbedingungen führen dazu, die für ein Projekt/Vorhaben sinnvollen bzw. notwendigen Aktivitäten und Produkte herauszufinden. Das Tailoring mit Streichbedingungen geht von der Maximalmenge der im V-Modell festgelegten Aktivitäten und Produkte aus. Es identifiziert die relevanten Streichgründe. Um das Tailoring für die häufigsten Projekttypen zu erleichtern, wurden für sechs Standard-Projekttypen Tailoringvorschläge vorgegeben, die als Ausgangspunkt für eine beschleunigte Projekthandbuch-Erstellung dienen können.

Abbildung T.6 macht deutlich, daß beide Verfahren bei gleicher Ausgangsposition prinzipiell zu demselben Ergebnis (projektspezifisches V-Modell) führen. Ziel der Streichbedingungen im Abschnitt T.4 ist es, mögliche Gründe für die Streichungen von Aktivitäten und Produkten eines Projekts bzw. eines Projekttyps anzugeben.

Das Tailoring mit Streichbedingungen zeichnet sich durch hohe Flexibilität aus, da durch die Streichbedingungen eine nahezu unbegrenzte Menge individueller Konstellationen berücksichtigt werden kann.

Das Standardisierte Vortailoring ist weniger flexibel (es ist nur für die "vorgedachten" Vorhabentypen anwendbar), aber durch die Verwendung der Formblätter ist es sehr einfach durchzuführen.

Abbildung T.6: Darstellung der unterschiedlichen Tailoringverfahren


Prüfung des projektspezifischen V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.2	Prüfung des projektspezifischen V-Modells

Die Prüfung des projektspezifischen V-Modells besteht aus mehreren Schritten:

−	Prüfung der Streichgründe
Die Gründe zum Weglassen von Aktivitäten und Produkten im Projekt müssen objektiv und nachvollziehbar sein. Die Gründe haben sich aus der Charakterisierung des Projekts und des Entwicklungsgegenstands entsprechend der "Projektbeschreibung" (Kapitel im Projekthandbuch) abzuleiten. Diese Prüfung ist eine inhaltliche Prüfung und kann daher nicht von einem Werkzeug ersetzt werden.

Die Streichungen von Aktivitäten und Produkten sind u. a. durch gewisse Standards und Richtlinien, die im Projekt zu berücksichtigen sind, nicht zugelassen. Im öffentlichen Bereich und hier speziell bei Vorhaben des Haushalts-, Kassen- und Rechnungswesens haben die Rechnungshöfe des Bundes und der Länder konkrete Vorstellungen zur Durchführung von IT-Vorhaben entwickelt. Diese wurden als "Mindestanforderungen der Rechnungshöfe des Bundes und der Länder zum Einsatz der Informationstechnik (IT-Mindestanforderungen)" (siehe Handbuch "BRH") veröffentlicht.

Die Gründe, die zu Verletzung der in Abschnitt T.2.1.1 angegebenen Mindestanforderungen führen, sind besonders auf Nachvollziehbarkeit zu prüfen.

−	Prüfung der Auswirkungen von Streichungen
Die Streichungen von Aktivitäten haben i. d. R. Auswirkungen auf weitere Aktivitäten und Produkte. Wird z. B. eine Aktivität gestrichen, weil bereits das Produkt vorliegt, welches die Aktivität erstellt, so kommt das Produkt von "extern". Andere Produkte fallen nach Streichung einer Aktivität auch weg. Eine nähere Beschreibung der Auswirkungen erfolgt in Abschnitt T.4 "Streichbedingungen". Die Auswirkungen der Streichungen sind sowohl bei der Angabe von Streichbedingungen im Kapitel "Übersicht" des Projekthandbuchs als auch bei der Beschreibung der Produktflüsse und der Abwicklungstexte (falls im Kapitel "Projektspezifisches V-Modell" des Projekthandbuchs beschrieben) zu berücksichtigen.

−	Konsistenzprüfung des V-Modells
In dem Fall, bei dem das projektspezifische V-Modell auch die Produktflüsse berücksichtigt und bei dem es in ein Workflow-System abgebildet werden soll, ist die Prüfung der Ausführbarkeit von Bedeutung. Dabei sind u. a. folgende Prüfungen notwendig:

•	Produktflußprüfung bei Aktivitäten (z. B. wird ein Eingangsprodukt einer Aktivität auch wirklich von einer anderen Aktivität produziert bzw. modifiziert?)

•	Prüfung der Zustandsänderungen bei Produkten

•	Vermeidung von isolierten (Teil-) Produkten und (Teil-) Aktivitäten

Aus Konsistenzgründen sind gegebenenfalls Anpassungen der Produktflüsse und der Streichungen von Aktivitäten und Produkten notwendig.


Dokumentation des projektspezifischen V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.3	Dokumentation des projektspezifischen V-Modells

Ein projektspezifisches V-Modell wird beschrieben und dokumentiert durch:

−	Aktivitäten und Produkte

−	Streichbedingungen für das Projekt

Die nächsten Abschnitte geben Hinweise hierzu.


Aktivitäten- und Produktbeschreibungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.3	Dokumentation des projektspezifischen V-Modells

T.2.3.1	Aktivitäten- und Produktbeschreibungen

Es werden zwei Möglichkeiten für die Dokumentation der Aktivitäten und Produkte angeboten:

−	Die Aktivitäten und Produkte des projektspezifischen V-Modells verweisen auf die Beschreibungen des generischen V-Modells.

−	Die Beschreibungstexte aus dem V-Modell werden für die Aktivitäten und Produkte übernommen. Diese sind u. a. die Abwicklungstexte der Aktivitäten und die Produktmuster.

Für die textuelle Anpassung von Aktivitätenbeschreibungen sind folgende Regeln einzuhalten:

Die V-Modell-Aktivitätenbeschreibungen enthalten Fallbeschreibungen und -unterscheidungen aller möglichen Projektszenarien und -umstände. In einem konkreten Projekt können diese Fallunterscheidungen entfallen; die Beschreibungen können auf konkrete Projektbedingungen Bezug nehmen.

Dies heißt, daß alle nicht relevanten Teile der Beschreibungstexte der Aktivitäten, Empfehlungen und Erläuterungen gestrichen werden können. Aus solchen Streichungen kann die Notwendigkeit resultieren, daß sprachliche Formulierungen angepaßt werden müssen. Die verbleibenden Textteile können mit konkreten Projektbezügen ergänzt werden, wie z. B. Bezüge auf Voruntersuchungen, bestehende Ergebnisse, Aufwendungshinweise, Vereinbarungen oder Hinweise, für wen (AG, HAN oder UAN) die Aktivität relevant ist. Letzteres ist besonders dann sinnvoll, wenn für HAN und UAN nur ein gemeinsames Projekthandbuch geschrieben werden soll.

Voraussetzung für die Modifikation der Aktivitätentexte ist, daß der V-Modell-Originaltext und der ergänzte Text visuell (z. B. durch verschiedene Schrifttypen) unterscheidbar ist.

Im folgenden Beispiel (siehe Abbildung T.7) werden anhand der Aktivität SE 1 "System-Anforderungsanalyse"

−	Streichungen von nicht zutreffenden Teilen der Aktivitätenbeschreibung vorgenommen,

−	notwendige sprachliche Anpassungen vorgenommen,

−	für den Projektverlauf wichtige Anwendungshinweise ergänzt,

−	der Durchführende der Aktivität benannt und

−	projektspezifische Ergänzungen optisch gekennzeichnet.

Abbildung T.7: Beispiel einer Aktivitätenanpassung


Aufzeichnung der Streichbedingungen für das Projekt
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.2	Projektspezifische Anpassung des V-Modells

T.2.3	Dokumentation des projektspezifischen V-Modells

T.2.3.2	Aufzeichnung der Streichbedingungen für das Projekt

Die Auswahlentscheidung des Vorhabentyps und die Streichbedingungen, die für das Projekt Gültigkeit haben, sind in das Kapitel "Übersicht" des Projekthandbuchs aufzunehmen.

Aktivität/Produkt des generischen V-Modells	Streichung	Streichgrund (entfällt, weil bzw. entfällt, wenn)
Aktivität- bzw. Produktname	AT	Streichgrund für die generelle Streichung
Aktivität- bzw. Produktname	TT	Streichgrund für das Technische Tailoring
Aktivität- bzw. Produktname	—	d. h. es liegt kein Streichgrund vor.
Eine tabellarische Darstellungsmöglichkeit, bei der für die nicht gestrichenen Aktivitäten die Methoden und Werkzeuge zugeordnet sind, wird in Teil 1 "Regelungsteil" in Abschnitt 8 "Produktmuster" unter "PHb_3 Übersicht" des Projekthandbuchs beschrieben.


IT-Vorhabentypen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

Im folgenden werden die Vorhabentypen beschrieben, für die derzeit ein Standardisiertes Vortailoring existiert. Als Grundlage für die Typisierung werden die Merkmale benutzt, die im nächsten Abschnitt beschrieben sind.

Allgemeine Annahmen

Bei allen Vorhabentypen werden bei der Auswahl der Aktivitäten und Produkte folgende Annahmen getroffen:

−	Es besteht keine Kritikalitätsstufung beim geplanten Vorhaben. D. h. alle Softwareanteile werden  hinsichtlich der einzusetzenden Methoden zur Erstellung und Prüfung gleich behandelt.

−	Es ist keine Datenbankentwicklung vorgesehen.

Treffen diese Annahmen bei einem geplanten konkreten Vorhaben nicht zu, so sind unter Heranziehung der Durchführungsbedingungen der Tailoring-Formblätter (Abschnitt T.3.6 "Tailoring-Formblätter") zusätzliche Aktivitäten und Produkte auszuwählen.

Die Durchführungsbedingungen sind auch dann zu beachten, wenn für eines der vorhabenspezifischen Merkmale

−	Komplexität von Funktionen

−	Komplexität von Daten

−	Wartbarkeitsanforderungen

der im zugehörigen Vorhabentyp festgelegte Merkmalswert vom Merkmalswert eines geplanten konkreten Vorhabens abweicht.


Merkmale mit ihren Quantifizierungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.1	Merkmale mit ihren Quantifizierungen

Für die Definition von Vorhabentypen sind Merkmale und ihre Quantifizierung notwendig. Die Merkmale "Projektgröße", "Komplexität" und "Wartbarkeitsanforderungen" werden in den Kategorien "gering/klein", "mittel" und "hoch/groß" beschrieben.


Projektgrößeneinstufung
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.1	Merkmale mit ihren Quantifizierungen

T.3.1.1	Projektgrößeneinstufung

IT-Projekte haben unterschiedlichen Umfang. Dies muß bei der Auswahl von Aktivitäten und Produkten berücksichtigt werden. Als Einteilungsmaß für die Projektgröße wird der Aufwand für ein Projekt (in Personenjahren, PJ) und die Anzahl der Projektmitarbeiter verwendet.

Die Größe eines Projekts wird nach dem folgendem Schema eingestuft:

In den Fällen, in denen die Projektgröße nach obigem Schema nicht eindeutig festgelegt wird, ist die größere Projektgröße zu wählen. Z. B. bei einem Projekt mit 2 Mitarbeitern (führt zur Einstufung "klein") und 3 PJ Aufwand (führt zur Einstufung "mittel") ist die Einstufung "mittel" zu wählen.


Komplexitätseinstufung von Funktionen und Daten
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.1	Merkmale mit ihren Quantifizierungen

T.3.1.2	Komplexitätseinstufung von Funktionen und Daten

In den Produkten "Anwenderforderungen" und "Technische Anforderungen" werden die Funktionen und Daten beschrieben und fachlich strukturiert. Die in diesen Dokumenten beschriebenen Funktionen und Daten sind anhand ihrer fachlichen Strukturierung hinsichtlich ihrer Komplexität zu klassifizieren. Die Bewertung der Komplexität erfolgt durch eine zahlenmäßige Bewertung von geeigneten Indikatoren.

Da die Ermittlung der Komplexität mit mathematischen Verfahren mit vertretbarem Aufwand nur mit einem Softwarewerkzeug erfolgen kann, wird hier ein vereinfachtes Verfahren zur Komplexitätseinstufung von Funktionen und Daten vorgeschlagen. Zur Bewertung wird dabei die in den oben genannten Anforderungsdokumenten erfaßte Strukturierung der Funktionen und Daten herangezogen.

−	Auf System-, Segment- und SW-Einheiten-Ebene wird die Komplexität anhand der erwarteten Anzahl der Subfunktionen und der Anzahl der internen Schnittstellen klassifiziert.

−	Auf Komponenten- und Modulebene erfolgt die Komplexitätsbewertung anhand der Codelänge.

−	Die Komplexität von Daten, die sich in einer sequentiellen bzw. Entity-Relationship-Struktur darstellen lassen, wird anhand der Anzahl von Entitäten und der Anzahl der internen Verkettungen (Relationen oder Hierarchiestufen) klassifiziert.

Im folgenden werden die Indikatoren für die drei Komplexitätsklassen angegeben.


Quantifizierung der Wartbarkeitsanforderungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.1	Merkmale mit ihren Quantifizierungen

T.3.1.3	Quantifizierung der Wartbarkeitsanforderungen

Die Wartbarkeitseinstufungen werden folgendermaßen quantifiziert:


Kleine administrative IT-Vorhaben
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.2	Administrative IT-Vorhaben

T.3.2.1	Kleine administrative IT-Vorhaben

1.	Projektbeschreibung

Das Projekt wird meist von einem oder zwei Mitarbeitern durchgeführt. Häufig ist der Ersteller der Software auch deren Anwender. Die Anwendung selbst läuft häufig auf einem PC.

2.	Projektgröße

Nicht mehr als 0,5 Personenjahre bei 1 bis 2 Mitarbeitern.

3.	Komplexität

Die Komplexität sowohl der Funktionen als auch der Daten ist gering.

4.	Wartbarkeitsanforderungen

Gering

5.	Beispiele für kleinere administrative Vorhaben:

−	Statistikprogramme

−	Businessgrafik

−	dBase-Applikationen mit Auswertungen


Mittlere administrative IT-Vorhaben
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.2	Administrative IT-Vorhaben

T.3.2.2	Mittlere administrative IT-Vorhaben

1.	Projektbeschreibung

Das Projekt wird von einer kleineren Gruppe von Mitarbeitern durchgeführt. Die Anwendung läuft häufig in einem PC-Netz.

2.	Projektgröße

Der veranschlagte Aufwand ist nicht größer als 5 Personenjahre oder die Anzahl der Projektmitarbeiter nicht mehr als fünf.

3.	Komplexität

Die Komplexität sowohl der Funktionen als auch der Daten ist mittel.

4.	Wartbarkeitsanforderungen

Mittel

5.	Beispiele für mittlere administrative Vorhaben:

−	Reisekostenabrechnung im Auswärtigen Amt (3 Arbeitsplätze)

−	EUROTELEFON im Wirtschaftsministerium (2−3 Arbeitsplätze)


Große administrative IT-Vorhaben
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.2	Administrative IT-Vorhaben

T.3.2.3	Große administrative IT-Vorhaben

1.	Projektbeschreibung

Es handelt sich um ein großes Projekt, das von einer größeren Anzahl von Mitarbeitern (mehr als fünf) durchgeführt wird. Beispiele derartiger Systeme sind Fachinformationssysteme (z. B. Personalverwaltungen, Materialverwaltungen, Organisationsaufgaben, Aktenverwaltungen, Registratur).

2.	Projektgröße

Der veranschlagte Aufwand ist größer als 5 Personenjahre, oder das Projekt wird von mehr als 5 Mitarbeitern durchgeführt.

3.	Komplexität

Die Komplexität sowohl der Funktionen als auch der Daten ist mittel.

4.	Wartbarkeitsanforderungen

Mittel

5.	Beispiele für große administrative IT-Vorhaben:

−	Kraftfahrtbundesamt (Kfz-Daten)

−	Bundesverwaltungsamt (Ausländerzentralregister, ca. 200 Bildschirme)

−	IMIS-Umweltprojekt

−	Patentinformationssystem des Deutschen Patentamts PATIS


Kleine/mittlere technisch-wissenschaftliche IT-Vorhaben
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.3	Technisch-wissenschaftliche IT-Vorhaben

T.3.3.1	Kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

1.	Projektbeschreibung

Es handelt sich um ein kleines bis mittleres Projekt, in dem der Schwerpunkt die technisch-wissenschaftliche Datenverarbeitung ist. Dies sind z. B. Modell- und Simulationsrechnungen, Grafik, Bildverarbeitung, Statistik, Festigkeitsberechnungen usw. Das Projekt wird von nicht mehr als 5 Mitarbeitern durchgeführt.

2.	Projektgröße

Nicht mehr als 5 Personenjahre oder nicht mehr als 5 Mitarbeitern.

3.	Komplexität

Die Komplexität der Funktionen ist mittel; die Komplexität der Daten ist gering.

4.	Wartbarkeitsanforderungen

Gering

5.	Beispiele:

−	Tidensimulation

−	Meßwerterfassung


Große technisch-wissenschaftliche IT-Vorhaben
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.3	Technisch-wissenschaftliche IT-Vorhaben

T.3.3.2	Große technisch-wissenschaftliche IT-Vorhaben

1.	Projektbeschreibung

Es handelt sich um ein großes Projekt mit dem Schwerpunkt technisch-wissenschaftliche Datenverarbeitung. Dies sind z. B. besonders umfangreiche Modell- und Simulationsrechnungen, Grafik, Bildverarbeitung, Statistik, Festigkeitsberechnungen usw. Das Projekt wird von mehr als 5 Mitarbeitern durchgeführt.

2.	Projektgröße

Der veranschlagte Aufwand ist größer als 5 Personenjahre, oder das Projekt wird von mehr als 5 Mitarbeitern durchgeführt.

3.	Komplexität

Die Komplexität der Funktionen ist mittel; die Komplexität der Daten ist gering.

4.	Wartbarkeitsanforderungen

Gering

5.	Beispiele:

−	Wettervorhersagen

−	Anwendungen der Flugsicherung (Radardatendarstellung)


Auswahl, Beschaffung und Anpassung von Fertigprodukten
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.4	Auswahl, Beschaffung und Anpassung von Fertigprodukten

1.	Projektbeschreibung

Bei diesem Vorhabentyp sind nur wenige V-Modell-Aktivitäten und Produkte erforderlich, da mit dem Fertigprodukt bereits ein großer Teil der Funktionalität existiert.

2.	Projektgröße

Der Aufwand ist nicht mehr als 0,5 Personenjahre bei nicht mehr als 2 Mitarbeitern.

3.	Komplexität

Die Komplexität sowohl der Funktionen als auch der Daten der Ergänzungen bzw. Modifikationen ist gering.

4.	Wartbarkeitsanforderungen

Mittel

5.	Beispiele:

−	Bürokommunikationseinrichtungen

−	Telekommunikationseinrichtungen


Darstellung der Vorhabentypen im Überblick
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.5	Darstellung der Vorhabentypen im Überblick

Die nachstehende Matrix gibt eine zusammenfassende Darstellung der Beziehungen von Vorhabentypen und Merkmalswerten.

Abbildung T.8: Vorhabentypen und Merkmalswerte


Anwendung der Formblätter
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.6	Tailoring-Formblätter

T.3.6.1	Anwendung der Formblätter

Für die Systemerstellung, für die Qualitätssicherung, für das Konfigurationsmanagement und für das Projektmanagement eines jeden Vorhabentyps gibt es eigene Formblätter. Der prinzipielle Aufbau dieser Tailoring-Formblätter wird in Abbildung T.9 gezeigt. Einzelne Bereiche sind durch Zahlen besonders gekennzeichnet.

Abbildung T.9: Prinzipieller Aufbau der Tailoring-Formblätter

Zu Bereich 1: Aktivitätenzeilen

Alle Aktivitäten des jeweiligen Submodells werden in den Zeilen angegeben.

Zu Bereich 2: Produktspalten

Alle Produkte des jeweiligen Submodells werden in den Spalten angegeben.

Zu Bereich 3: Zuordnung von Produkten und Aktivitäten

Die vertikalen Kästchen (ohne Berücksichtigung ihrer Füllung) geben an, welche Aktivitäten zur Erstellung eines Produktes beitragen. (Beispiel: die Aktivitäten 2 bis 7 erstellen Produkt P1, Aktivität 8 und 9 erstellen Produkt P2.)

Zu Bereich 4: Basis-Anforderungen und Durchführungsbestimmungen

Die Kästchen sind als Indikatoren zu verstehen, die auf die im Bereich 1 in der gleichen Zeile stehenden Aktivitäten verweisen. Diese Indikatoren haben die folgende Bedeutung.

a)	Indikatoren der Basis-Anforderungen

Die Indikatoren der Basis-Anforderungen (schwarze Kästchen) verweisen auf die Aktivitäten, die für den betreffenden Vorhabentyp immer durchzuführen sind. Tragen solche Aktivitäten zur Erstellung eines Produkts bei, so sind im Bereich 3 die entsprechenden Kästchen für die Teilprodukte schwarz ausgefüllt.

(Beispiel: Die Aktivitäten 3, 5 und 9 sind zwingend durchzuführen. Dabei sind zwei Teilprodukte für Produkt P1 und ein Teilprodukt für Produkt P2 zu erstellen.)

Basis-Anforderungen berücksichtigen die Mindestanforderungen aus Abschnitt T.2.1.1.

b)	Indikatoren der Durchführungsbedingungen

Die Indikatoren der Ergänzungen (unterlegte Kästchen) verweisen auf die Aktivitäten, die für den betreffenden Vorhabentyp dann zusätzlich durchzuführen sind, wenn Durchführungsbedingungen zutreffen. Tragen solche Aktivitäten zur Erstellung eines Produkts bei, so sind im Bereich 3 die entsprechenden Kästchen für die Teilprodukte unterlegt.

(Beispiel: Treffen die Bedingungen B1 und B2 zu, so sind die Aktivitäten 6 und 7 zusätzlich zu den Aktivitäten 3, 5 und 9 durchzuführen. Dabei ist − aufgrund der Bedingung B1 − jeweils ein Teilprodukt für Produkt P1 und Produkt P2 zu erstellen.)

Sind in den Formblättern mehrere Durchführungsbedingungen in einer Zeile markiert, so ist dies als "Oder"-Verknüpfung zu interpretieren.

Bemerkung: Die Indikatoren im Bereich 4 können Ziffern enthalten, die in den Tailoring-Formblättern Fußnoten betreffen. Diese Fußnoten geben zusätzliche Hinweise, die bei der Durchführung der Aktivitäten, auf die ein solcher Indikator verweist, zu beachten sind.


Formblattsammlung
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.3	IT-Vorhabentypen

T.3.6	Tailoring-Formblätter

T.3.6.2	Formblattsammlung

Für jeden Vorhabentyp gibt es je ein separates Formblatt für Systemerstellung und für Qualitätssicherung und Konfigurationsmanagement. Außerdem gibt es für kleine und mittlere Projekte sowie für große Projekte je ein Formblatt für Projektmanagement.

Anmerkungen zu den Fußnoten der Formblätter:

a)	Die Fußnoten auf den Formblättern zur Systemerstellung geben in der Regel zusätzliche Bedingungen zur Ausführung der Aktivitäten, auf die die Indikatoren verweisen. Diese Fußnoten sind selbsterklärend.

b)	Die Fußnoten auf den Formblättern zu Qualitätssicherung und Konfigurationsmanagement geben Einschränkungen bei der Durchführung der Aktivitäten an, auf die die Indikatoren verweisen. (Beispiel: Verweist ein Indikator mit Fußnote "für die Produkte x, y und z" auf eine Aktivität, so ist diese Aktivität nur für die Produkte x, y und z, nicht aber für weitere mögliche Produkte durchzuführen.)

Liste der Formblätter:

−	SE für kleine administrative IT-Vorhaben (Abbildung T.10)

−	SE für mittlere administrative IT-Vorhaben (Abbildung T.11)

−	QS und KM für kleine und mittlere administrative IT-Vorhaben (Abbildung T.12)

−	SE für große administrative IT-Vorhaben (Abbildung T.13)

−	QS und KM für große administrative IT-Vorhaben (Abbildung T.14)

−	SE für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben (Abbildung T.15)

−	QS und KM für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben (Abbildung T.16)

−	SE für große technisch-wissenschaftliche IT-Vorhaben (Abbildung T.17)

−	QS und KM für große technisch-wissenschaftliche IT-Vorhaben (Abbildung T.18)

−	SE für Auswahl, Beschaffung und Anpassung von Fertigprodukten (Abbildung T.19)

−	QS und KM für Auswahl, Beschaffung und Anpassung von Fertigprodukten (Abbildung T.20)

−	PM für kleine und mittlere IT-Vorhaben (Abbildung T.21)

−	PM für große IT-Vorhaben (Abbildung T.22)

Matrixeinträge:

	immer erforderlich		nur Daten bzw. Datenbank beschreiben
	unter den geg. Umständen erforderl.
	nicht erforderlich
Abbildung T.10: SE für kleine administrative IT-Vorhaben

Matrixeinträge:

	immer erforderlich		nur Daten bzw. Datenbank beschreiben
	unter den geg. Umständen erforderl.
	nicht erforderlich
Abbildung T.11: SE für mittlere administrative IT-Vorhaben

Matrixeinträge:

	immer erforderlich		für die Produkte:		für die Produkte:		für die Produkte:
	unter den geg. Umständen erforderl.		Anwenderforderungen		SW-Komponente		SW-Einheit
	nicht erforderlich		Systemarchitektur		SW-Modul/Datenbank		Segment (falls vorhanden)
			Technische Anforderungen				System
			SW-Einheit
			Segment (falls vorhanden)
			System
Abbildung T.12: QS und KM für kleine und mittlere administrative IT-Vorhaben

Matrixeinträge:

	immer erforderlich		nur Daten bzw. Datenbank beschreiben
	unter den geg. Umständen erforderl.
	nicht erforderlich
Abbildung T.13: SE für große administrative IT-Vorhaben

Matrixeinträge:

	immer erforderlich		für die Produkte:		für die Produkte:		für die Produkte:
	unter den geg. Umständen erforderl.		Anwenderforderungen		SW-Komponente		SW-Einheit
	nicht erforderlich		Systemarchitektur		SW-Modul/Datenbank		Segment (falls vorhanden)
			Technische Anforderungen				System
			SW-Einheit
			Segment (falls vorhanden)
			System
Abbildung T.14: QS und KM für große administrative IT-Vorhaben

Matrixeinträge:

	immer erforderlich		nur Daten bzw. Datenbank beschreiben
	unter den geg. Umständen erforderl.
	nicht erforderlich
Abbildung T.15: SE für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Matrixeinträge:

	immer erforderlich		für die Produkte:		für die Produkte:		für die Produkte:
	unter den geg. Umständen erforderl.		Anwenderforderungen		SW-Komponente		SW-Einheit
	nicht erforderlich		Systemarchitektur		SW-Modul/Datenbank		Segment (falls vorhanden)
			Technische Anforderungen				System
			SW-Einheit
			Segment (falls vorhanden)
			System
Abbildung T.16: QS und KM für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Matrixeinträge:

	immer erforderlich		nur Daten bzw. Datenbank beschreiben
	unter den geg. Umständen erforderl.
	nicht erforderlich
Abbildung T.17: SE für große technisch-wissenschaftliche IT-Vorhaben

Matrixeinträge:

	immer erforderlich		für die Produkte:		für die Produkte:		für die Produkte:
	unter den geg. Umständen erforderl.		Anwenderforderungen		SW-Komponente		SW-Einheit
	nicht erforderlich		Systemarchitektur		SW-Modul/Datenbank		Segment (falls vorhanden)
			Technische Anforderungen				System
			SW-Einheit
			Segment (falls vorhanden)
			System
Abbildung T.18: QS und KM für große technisch-wissenschaftliche IT-Vorhaben

Matrixeinträge:

	immer erforderlich		Zu beschaffendes Fertigprodukt ist SW-Einheit
	unter den geg. Umständen erforderl.		Zu beschaffendes Fertigprodukt ist SW-Komponente/-Modul/Datenbank
	nicht erforderlich
Abbildung T.19: SE für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Matrixeinträge:

	immer erforderlich		für die Produkte:		für die Produkte:		für die Produkte:
	unter den geg. Umständen erforderl.		Anwenderforderungen		SW-Komponente		SW-Einheit
	nicht erforderlich		Systemarchitektur		SW-Modul/Datenbank		Segment (falls vorhanden)
			Technische Anforderungen				System
			SW-Einheit
			Segment (falls vorhanden)
			System
Abbildung T.20: QS und KM für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Matrixeinträge:

	immer erforderlich		wenn Aufträge (Beschaffung/Entwicklungstätigkeiten) vergeben werden
	unter den geg. Umständen erforderl.		wenn Arbeitsumgebung der Mitarbeiter neu definiert wird
	nicht erforderlich
Abbildung T.21: PM für kleine und mittlere IT-Vorhaben

Matrixeinträge:

	immer erforderlich		wenn Aufträge (Beschaffung/Entwicklungstätigkeiten) vergeben werden
	unter den geg. Umständen erforderl.		wenn Arbeitsumgebung der Mitarbeiter neu definiert wird
	nicht erforderlich
Abbildung T.22: PM für große IT-Vorhaben


Vorbemerkungen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.1	Vorbemerkungen

Eine Streichbedingung besteht aus nachstehenden Angaben:

−	Bezug auf Aktivität bzw. Produkt (Verweis)

−	Streichgrund (Text)

−	Zu berücksichtigende Auswirkung bei Streichung (Text)

Im weiteren sind die allgemeinen Auswirkungen von Streichungen angegeben. Eine Streichbedingung kann sowohl für das Ausschreibungsrelevante Tailoring (AT) als auch für das Technische Tailoring (TT) verwendet werden. Die folgende Tabelle zeigt die Auswirkungen für Aktivitäten. Für Produkte sind ähnliche Auswirkungen zu beobachten.

Aktivitäten und Ergebnisse	Unterstützende Tailoringmethode	Auswirkung/Hinweise
Eine Aktivität ist für das Projekt nicht notwendig.	AT	Aktivität ist unter Angabe der Begründung zu streichen. Die von ihr erzeugten Informationen (Produkte bzw. Teilprodukte) sind nicht relevant; sie sind zu streichen.
Eine Aktivität ist für das Projekt generell notwendig, kann jedoch unter Umständen während der Projektdurchführung gestrichen werden.	TT	Aktivität kann bei Projektdurchführung unter Angabe der Begründung gestrichen werden. Die von ihr erzeugten Informationen (Produkte bzw. Teilprodukte) sind nicht relevant; sie sind zu streichen.
Die Ergebnisse einer Aktivität sind für das Projekt notwendig und können komplett in Form und Inhalt von einem vorhergehenden Projekt übernommen werden.	AT, TT	Die Aktivität ist zu streichen; die vorhandenen Ergebnisse werden übernommen. Produkte kommen von "extern".
Die Ergebnisse einer Aktivität sind für das Projekt notwendig und können von einem vorhergehenden Projekt zum größten Teil übernommen werden.	AT, TT	Die Aktivität kann mit dem Hinweis der Anpassungsnotwendigkeit gestrichen werden. Es werden nur geringfügige Anpassungen erwartet.
Eine Aktivität ist für das Projekt notwendig, wird jedoch außerhalb des Projekts erledigt.	keine	Aktivität kann nicht gestrichen werden. Ein Verweis auf die ausführenden Organisations- einheit kann aufgenommen werden.


Konventionen
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.2	Konventionen

Die Streichbedingungen werden tabellarisch angegeben. Die beiden ersten Spalten nehmen die Relevanz der Streichbedingung für eine der Tailoringmethoden auf. Sind Einträge "—" in den Spalten AT oder TT vorhanden, bedeutet dies, daß die Aktivität entsprechend der Tailoringmethode nicht gestrichen werden soll.

AT	TT	Aktivität/Streichgrund	Auswirkungen
—	—	Aktivität	Aktivität darf nicht gestrichen werden.
		Aktivität	Aktivität ist im AT und TT streichbar.
	—	Aktivität	Aktivität ist im AT streichbar.
—		Aktivität	Aktivität ist im TT streichbar.
Bei der folgenden Behandlung der Streichbedingungen wird für Produkte das Standard-Kapitel "1 Allgemeines" nicht separat aufgeführt. Dieses Kapitel ist immer dann relevant, wenn das Produkt oder auch nur eines seiner Kapitel zu erstellen ist.

Kapitel von Produkten entfallen, wenn die sie erzeugenden Teilaktivitäten entfallen.


Streichen von Aktivitäten
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.3	Streichen von Aktivitäten

Eine Aktivität kann unter Angabe einer Begründung gestrichen werden. Die im folgenden genannten beispielhaften Streichbedingungen sind − sofern zutreffend − projektspezifisch als AT- oder TT-Streichbedingung zu klassifizieren. Weitere eigene Begründungen sind bei Bedarf zu ergänzen. Sind zu Aktivitäten keine Streichbedingungen angegeben, so heißt das nicht, daß sie nicht gestrichen werden dürfen. Bei einer Streichung ist eine projektspezifische Begründung anzugeben.

Die Streichbedingungen verwenden u. a. die in Abschnitt T.3.1 eingeführten Merkmale mit ihren Quantifizierungen. Sie werden entlang den Submodellen Projektmanagement, Qualitätssicherung, Konfigurationsmanagement und Systemerstellung genannt.

Die Aufzählungen der Begründungen sind dabei als "Oder"-Verknüpfungen zu interpretieren.


Submodell PM
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.3	Streichen von Aktivitäten

T.4.3.1	Submodell PM

AT	TT	Aktivität/Begründung zur Streichung	Auswirkungen
—	—	PM 1 Projektinitialisierung
—	—	PM 1.1 Projekt einrichten
		PM 1.2 Projektkriterien und Entwicklungsstrategie festlegen
		Es handelt sich um ein Pflege-/Änderungsprojekt und die Projektbeschreibung liegt vor.	Der Kapitelinhalt "PHb.Projektbeschreibung" ist vorgegeben.
	—	PM 1.3 Projektspezifisches V-Modell erstellen
		Projektspezifisches V-Modell kann aus ähnlichem Projekt (gleiche Charakteristika) übernommen werden.	Die Kapitelinhalte "PHb.Übersicht" und "PHb.Projektspezifisches V-Modell" sind vorgegeben.
		PM 1.4 Toolset-Management durchführen
		Es handelt sich um ein Pflege-/Änderungsprojekt und das Projekthandbuch des Erstellungsprojekts liegt vor. SEU, Methoden und Standards werden aus ähnlichem Projekt (gleiche Charakteristika) übernommen. SEU, Methoden und Standards sind vom AG vorgegeben.	Die Kapitelinhalte "PHb.Methoden/Werkzeuge", "PHb.Standards/Richlinien" sind vorgegeben.
—	—	PM 1.5 Grobplan erstellen
	—	PM 2 Vergabe/Beschaffung
		Für das Projekt sind keine Produkte/Dienstleistungen zu beschaffen.	Die Produkte "Ausschreibungsunterlagen", "Angebot", "Angebotsbewertung" und "Vertrag" entfallen.
	—	PM 3 Auftragnehmer-Management
		Es handelt sich um ein Projekt ohne Beteiligung von Auftragnehmern. Die Beziehungen zu Auftragnehmern sind wohl definiert, Abweichungen und Konflikte werden nicht erwartet. Die Koordination der Auftraggeber erfolgt somit im Rahmen der Projektkontrolle und -steuerung.	—
—	—	PM 4 Feinplanung
		PM 5 Kosten-/Nutzenanalyse
		Es handelt sich um ein Projekt, dessen Lösungsvorschlag verbindlich vorgegeben ist. Es existieren keine finanziellen Einschränkungen in Erstellung und Einsatz des Systems.	Das Produkt "Kosten-/Nutzenanalyse" entfällt.
		PM 6 Durchführungsentscheidung
		Der zu entwickelnde Baustein (System, Segment, usw.) besitzt keine Kritikalität und nur geringe Wartbarkeitsanforderungen. Bei Aktivitäten mit geringem Entwicklungsrisiko reichen die QS-Maßnahmen aus.	—
		PM 7 Risikomanagement
		Die Projektleitung besitzt ausreichende Erfahrung, um während der Projektabwicklung Risiken zu erkennen und Maßnahmen im Rahmen der Feinplanung einzuleiten. Es existieren nur wenige restriktive Soll-Vorgaben (Aufwand, Termine, Finanzen). Es handelt sich um ein kleines oder mittleres Projekt ohne erkennbare Entwicklungsrisiken. Risiken sind durch entsprechende Erfahrungen und Know-how nahezu ausschließbar.	Das Kapitel "PPl.Risikobetrachtungen" entfällt.
—	—	PM 8 Projektkontrolle und -steuerung
		PM 9 Informationsdienst/Berichtswesen
		Als Sachberichte dienen Entwicklungsergebnisse der anderen Submodelle.	—
		PM 10 Schulung/Einarbeitung
		Das Projekt ist ein Pflege-/Änderungsprojekt und wird vom Entwicklungsteam durchgeführt. Die Projektmitarbeiter besitzen entsprechende Erfahrungen/Kenntnisse in Technologie und Anwendungsproblematik.	—
		PM 11 Bereitstellung der Ressourcen
		Das Projekt ist ein Pflege-/Änderungsprojekt und die Infrastruktur ist vorhanden. Die Einsatzmittel haben sich im Vergleich zur zuletzt durchgeführten Aktivität nicht geändert.	—
		PM 12 Vergabe von Arbeitsaufträgen
		Es handelt sich um ein Projekt mit wenigen Mitarbeitern (kleines/mittleres Projekt).	Das Produkt "Arbeitsauftrag" entfällt.
		PM 13 Einweisung der Mitarbeiter
		Für die auszuführenden Aktivitäten sind bei den Mitarbeitern entsprechende Informationen vorhanden.	—
		Fehlende Informationen werden mit dem Arbeitsauftrag zugestellt.	Aktivität PM 12 darf nicht gestrichen werden.
—	—	PM 14 Projektabschluß


Submodell QS
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.3	Streichen von Aktivitäten

T.4.3.2	Submodell QS

AT	TT	Aktivität/Begründung zur Streichung	Auswirkungen
—	—	QS 1 QS-Initialisierung
—		QS 1.1 QS-Plan erstellen
		Es handelt sich um ein Pflege-/Änderungsprojekt und der QS-Plan liegt vor. QS-Plan kann von ähnlichem Projekt (gleiche Charakteristika) übernommen werden.	Das Produkt "QS-Plan" kommt von extern.
		QS 1.2 Prüfplan erstellen
		Die QS-Regelungen sind vollständig im Projektplan beschrieben.	Das Produkt "Prüfplan" entfällt.
—		QS 2 Prüfungsvorbereitung
		Prüfplan und Prüfspezifikation können aus ähnlichem Projekt (gleiche Charakteristika) übernommen werden.	—
—		QS 2.1 Prüfmethoden und -kriterien festlegen
		Prüfspezifikation des Prüfgegenstands kann aus ähnlichem Projekt (gleiche Charakteristika) übernommen werden. Die Prüfmethoden und -kriterien sind durch den AG vorgegeben.	Das Produkt "Prüfspezifikation" kommt von extern.
		QS 2.2 Prüfumgebung definieren
		Prüfumgebung kann von ähnlichem (gleiche Charakteristika) Projekt übernommen werden.	Der Kapitelinhalt "PrPl.Ressourcen" ist vorgegeben.
		Der Prüfgegenstand ist ein Dokument (d. h. ungleich SW-Modul, Datenbank, SW-Komponente, SW-Einheit, Segment oder System.).	Das Kapitel "PrPl.Ressourcen" entfällt.
		QS 2.3 Prüffälle festlegen
		Der Prüfgegenstand ist ein Dokument (d. h. ungleich SW-Modul, Datenbank, SW-Komponente, SW-Einheit, Segment oder System). Der Prüfgegenstand ist eine SW-Komponente, ein SW-Modul oder eine Datenbank; jedoch hat er keine Kritikalität und nur geringe Wartbarkeitsanforderungen.	Das Kapitel "PrSpez.Prüffälle" entfällt.
		QS 2.4 Prüfprozedur erstellen
		Der Prüfgegenstand ist ein Dokument (d. h. ungleich SW-Modul, Datenbank, SW-Komponente, SW-Einheit, Segment oder System). Die Prüfung ist so weit rechnergestützt, daß keine manuellen Eingriffe nötig sind. Die Prüfprozedur ist trivial. Der Prüfgegenstand ist eine SW-Komponente, ein SW-Modul oder eine Datenbank; jedoch hat er keine Kritikalität und nur geringe Wartbarkeitsanforderungen.	Das Produkt "Prüfprozedur" entfällt.
		QS 3 Prozeßprüfung von Aktivitäten
		Die vorgegebenen Vorgehensweisen und das V-Modell sind bei den Projektbeteiligten hinreichend bekannt und bereits in zurückliegenden Projekten angewandt (Streichbedingung gilt nicht für sicherheitskritische Systeme).	—
—	—	QS 4 Produktprüfung
		QS 4.1 Prüfbarkeit feststellen
		Für den Prüfgegenstand ist keine Prüfung im QS-Plan vorgesehen (Prüfungen sind mindenstens für Anwenderforderungen, Systemarchitektur und System gefordert).	—
		Die Feststellung der Prüfbarkeit erfolgt informell bei der Entgegennahme des Prüfgegenstandes.
—		QS 4.2 Produkt inhaltlich prüfen
		Für den Prüfgegenstand ist keine Prüfung im QS-Plan vorgesehen (Prüfungen sind mindenstens für Anwenderforderungen, Systemarchitektur und System gefordert).	—
		QS 5 QS-Berichtswesen
		Das QS-Berichtswesen wird vom PM-Berichtswesen übernommen.	Aktivität PM 9 darf nicht gestrichen werden.


Submodell KM
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.3	Streichen von Aktivitäten

T.4.3.3	Submodell KM

AT	TT	Aktivität/Begründung zur Streichung	Auswirkungen
—		KM 1 KM-Planung
		Es handelt sich um ein kleines Projekt und der Projektleiter übernimmt die Erstellung von KM-Regeln und die Ablage.	KM-Regeln sind in die Produkte PHb oder PPl aufzunehmen.
		Der organisatorische Rahmen (KM-Plan und KM-Infrastruktur) ist festgelegt (z. B. bei einem SWPÄ-Projekt). Die KM-Regelungen sind durch die Organisation festgelegt.	Das Produkt "KM-Plan" kommt von extern.
		KM 1.1 KM-Plan erstellen
		Der KM-Plan kann aus ähnlichem Projekt (d. h. gleiche Charakteristika) übernommen werden.	Das Produkt "KM-Plan" kommt von extern.
		KM 1.2 KM einrichten
		KM-Infrastruktur und KM-Organisation sind entsprechend den Regelungen des Projektplans und des KM-Plans vorhanden und können genutzt werden.	—
—	—	KM 2 Produkt- und Konfigurationsverwaltung
		KM 2.1 Produkt initialisieren
		Reduzierte KM-Verwaltung; Initialisierung nicht erforderlich.	—
—		KM 2.2 Konfiguration initialisieren
		Die betrachtete Einheit existiert bereits in einer ersten Version. Das KID der Einheit ist nur noch fortzuschreiben (siehe Aktivität KM 2.4).	—
—	—	KM 2.3 Produkt verwalten
—	—	KM 2.4 Konfiguration fortschreiben
		KM 2.5 Zugriffsrechte verwalten
		Es handelt sich um ein Projekt, bei dem jeder Projektmitarbeiter alle unter KM-gehaltenden Produkte einsehen und verändern kann.	Diese Regelung ist in den KM-Plan aufzunehmen.
		KM 3 Änderungsmanagement (Konfigurationssteuerung)
		Die Planung, Steuerung und Kontrolle der Arbeiten werden nicht formal gehandhabt und vom Projektleiter mit übernommen.	Die Produkte ÄVor, ÄAuf, ÄMit entfallen. Die Änderungsstatusliste ist innerhalb des Projektplans zu führen.
		KM 3.1 Änderung bewerten
		Die Änderung bezieht sich auf ein in der Entwicklung befindliches Produkt. Die Planung, Steuerung und Kontrolle der Arbeiten werden vom Projektleiter mit übernommen.	Das Produkt ÄVor entfällt.
		KM 3.2 Änderungsvorgehen entscheiden und Änderung einleiten
		Die Änderung bezieht sich auf ein in der Entwicklung befindliches Produkt. Die Planung, Steuerung und Kontrolle der Arbeiten werden vom Projektleiter mit übernommen.	Die Produkte ÄVor, ÄAuf und ÄMit entfallen.
		KM 3.3 Änderung abschließen
		Die Änderung erfolgt innerhalb der Entwicklung (AN-intern). Ihre Behandlung ist bereits in der Feinplanung berücksichtigt oder ist in der Projekthistorie bereits dokumentiert.	—
	—	KM 4 KM-Dienste
		Die KM-Dienste werden projektübergreifend durchgeführt.	—
	—	KM 4.1 Daten administrieren
		Es gibt keinen übergreifenden Datenkatalog.	—
		KM 4.2 SW-/HW-Produkte katalogisieren
		Im Projekt werden nur Dokumente (d. h. kein/e SW-Modul, Datenbank, SW-Komponente, SW-Einheit, Segment oder System) erzeugt.	—
		KM 4.3 Schnittstellen koordinieren
		Das zu entwickelnde System weist keine komplexen Schnittstellen auf.	—
		KM 4.4 Ergebnisse sichern
		Es existiert eine zentrale Stelle, deren Aufgabe die Datensicherung ist (regelmäßig und auf Weisung). Die Datensicherung wird in regelmäßigen Abständen automatisch vom KM-Werkzeug oder von der Projektbibliothek selbst ausgeführt.	—
		KM 4.5 KM-Dokumentation führen
		KM-Dokumentation nicht erforderlich.	KM-Dokumentation entfällt.
		KM 4.6 Release-Management durchführen
		Es exisitiert keine Menge von Einheiten, die in Konfigurationen fortgeschrieben werden.	—
		KM 4.7 Projekthistorie führen
		Es handelt sich um ein kleines Projekt ohne erkennbare Entwicklungsrisiken.	Das Produkt "Projekthistorie" entfällt. Die wesentlichen Entscheidungen des Projektes sind in Berichtsdokumenten festzuhalten.


Submodell SE
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.3	Streichen von Aktivitäten

T.4.3.4	Submodell SE

AT	TT	Aktivität/Begründung zur Streichung	Auswirkungen
—	—	SE 1 System-Anforderungsanalyse
		SE 1.1 Ist-Aufnahme/-Analyse durchführen
		Es handelt sich um ein Pflege/Änderungs-Projekt. Der Ist-Zustand hat keinen Einfluß auf die Neuentwicklung.	Das Kapitel "AnwFo.Ist-Aufnahme und Ist-Analyse" entfällt.
		SE 1.2 Anwendungssystem beschreiben
		Die externen Vorgaben erfüllen inhaltlich und formal das Produktmuster "AFo.Grobe Systembeschreibung" und "AFo.IT-Sicherheitsziel".	Die Kapitel "AFo.Grobe Systembeschreibung" und "AFo.IT-Sicherheitsziel" entfallen.
		SE 1.3 Kritikalität und Anforderungen an die Qualität definieren
		Neben der Funktionalität des zu entwickelnden Systems sind keine weiteren Qualitätsanforderungen relevant. Das System dient als Prototyp für den Nachweis der Machbarkeit. Eine Kritikalitätsbetrachtung ist nicht erforderlich.	Die Kapitel "AFo.Qualitätsforderungen" und "AFo.Kritikalität des Systems" entfallen.
		SE 1.4 Randbedingungen definieren
		Es werden keine technischen oder organisatorischen Randbedingungen aus fachlicher Sicht erwartet. Forderungen technischer Art werden ausreichend im Produkt "Technische Anforderungen" beschrieben.	Das Kapitel "AFo.Randbedingungen" entfällt.
		SE 1.5 System fachlich strukturieren
		Die externen Vorgaben erfüllen inhaltlich und formal das Produktmuster "AFo.Organisatorische Einbettung", "AFo.Nutzung" und "AFo.Beschreibung der Funktionalität".	Die Kapitel "AFo.Organisatorische Einbettung", "AFo.Nutzung" und "AFo.Beschreibung der Funktionalität" entfallen.
		SE 1.6 Bedrohung und Risiko analysieren
		Der Bedrohungsaspekt ist nicht relevant; bei Fehlverhalten des System werden nur geringe Risiken erwartet. Die Regelungen des Grundschutzes werden beachtet (auf der Ebene der Anwenderorganisation generell sichergestellt) und weder eingestufte noch personenbezogene Daten werden verarbeitet.	Die Kapitel "AFo.Bedrohungs- und Risikoanalyse" und "AFo.IT-Sicherheit" entfallen.
		SE 1.7 Forderungscontrolling durchführen
		Die Forderungen sind wirtschaftlich realisierbar.	—
		SE 1.8 Software-Pflege- und Änderungs-Konzept erstellen
		Es handelt sich um ein Pflege/Änderungsprojekt und das Produkt "SWPÄ-Konzept" liegt vor.	Das Produkt "SWPÄ-Konzept" kommt von extern.
—	—	SE 2 System-Entwurf
—	—	SE 2.1 System technisch entwerfen
		SE 2.2 Wirksamkeitsanalyse durchführen
		Sicherheitsaspekte sind nicht relevant.	Das Kapitel "SysArc.IT-Sicherheitskonzept" entfällt.
		SE 2.3 Realisierbarkeit untersuchen
		Es existiert nur eine Lösung, die aus ausreichender Erfahrung in Anwendungsproblematik entstanden ist. Die Einsatz- und Entwicklungsumgebung ist bekannt und kann unter geringem Entwicklungsrisiko genutzt werden. Die Lösungsansatz ist vorgegeben bzw. durch Vorstudien bereits ermittelt.	Das Kapitel "SysArc.Realisierbarkeitsuntersuchungen" entfällt.
—		SE 2.4 Anwenderforderungen zuordnen
		Die Zuordnung der Anwenderforderungen ergibt sich aus der Beschreibung des technischen Aufbaus in Aktivität SE 2.1.	—
—		SE 2.5 Schnittstellen beschreiben
		Das zu entwickelnde System weist keine komplexen Schnittstellen auf.	Das Produkt "Schnittstellenbeschreibung" entfällt.
—		SE 2.6 System-Integration spezifizieren
		Die Integration ist aus dem Produkt "Systemarchitektur" ableitbar und benötigt keine weiteren Erläuterungen.	Das Produkt "Integrationsplan" entfällt.
		SE 3 SW-/HW-Anforderungsanalyse
		Beauftragter Gegenstand ist eine SW-Einheit/HW-Einheit, und die externen Vorgaben erfüllen inhaltlich und formal das Produktmuster "Technische Anforderungen".	Das Produkt "Technische Anforderungen" kommt von extern.
—		SE 3.1 Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren
		Allgemeine Anforderungen sind bereits in Aktivität SE 2.1 ausreichend berücksichtigt.	Aktivität SE 2.1 darf nicht gestrichen werden.
—		SE 3.2 Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren
		Die Schnittstellen sind bereits in Aktivität SE 2.5 ausreichend beschrieben.	Aktivität SE 2.5 darf nicht gestrichen werden.
		SE 3.3 Anforderungen an die Funktionalität definieren
		Beauftragter Gegenstand ist eine SW-Einheit/HW-Einheit, und die externen Vorgaben erfüllen inhaltlich und formal das Kapitel 5.2 des Produktmusters "Technische Anforderungen".	Die Anforderungen an die Funktionalität kommen von extern.
—		SE 3.4 Anforderungen an die Qualität der SW-/HW-Einheit definieren
		Qualitätsanforderungen wurden bereits im Produkt "Anwenderforderungen" für die Elemente des Systems ausreichend beschrieben.	Das Kapitel "TA.Qualitätsanforderungen" entfällt.
—		SE 3.5 Anforderungen an Entwicklungs- und SWPÄ-Umgebung definieren
		Anforderungen an die Entwicklungs- und SWPÄ-Umgebung sind bereits in Aktivität SE 2.1 ausreichend beschrieben.	Aktivität SE 2.1 darf nicht gestrichen werden.
		SE 4-SW SW-Grobentwurf
		SW-Einheit wird durch ein Fertigprodukt realisiert.	Das Produkt "SW-Architektur" entfällt.
—	—	SE 4.1-SW SW-Architektur entwerfen
—		SE 4.2-SW SW-interne und -externe Schnittstellen entwerfen
		Die Schnittstellen sind bereits in den Aktivitäten SE 2.5, SE 3.2 bzw. SE 4.1-SW ausreichend beschrieben.	—
—		SE 4.3-SW SW-Integration spezifizieren
		Die Integration ist aus dem Produkt "SW-Architektur" ableitbar und benötigt keine weiteren Erläuterungen.	Die Beschreibung der Integrationsmaßnahmen im Produkt "Integrationsplan"   hinsichtlich der SW-Einheit entfällt.
		SE 5-SW SW-Feinentwurf
		SW-Einheit wird durch ein Fertigprodukt realisiert. Die Algorithmik wurde bereits in der SW-Architektur ausreichend beschrieben.	Das Produkt "SW-Entwurf" entfällt.
—		SE 5.1-SW SW-Komponente/-Modul/Datenbank beschreiben
		Die Realisierung (in Form einer Programmiervorgabe) der SW-Komponente/SW-Modul/Datenbank ist bereits in dem Produkt "SW-Architektur" beschrieben, und die SW-Komponente/SW-Modul/Datenbank ist weder kritisch noch komplex.	Das Kapitel "SwEnt.Beschreibung" entfällt.
—		SE 5.2-SW Betriebsmittel- und Zeitbedarf analysieren
		Das betrachtete Modul beansprucht die vorhandenen Ressourcen nur in geringem Maße und dies wird im Rahmen der Moduldokumentation (SW-Entwurf) nachvollziehbar plausibel gemacht (z. B. durch kurze Erläuterung).	Das Kapitel "SwEnt.Kenngrößen" entfällt.
		SE 6-SW SW-Implementierung
		SW-Einheit wird durch ein Fertigprodukt realisiert.	Das Produkt "Implementierungsdokumente" entfällt.
—	—	SE 6.1-SW SW-Module codieren
—	—	SE 6.2-SW Datenbank realisieren
		SE 6.3-SW Selbstprüfung des SW-Moduls/der Datenbank durchführen
		Die Selbstprüfung obliegt dem Entwickler und wird nicht vom Projektleiter im Produkt "Projektplan" berücksichtigt (Zuordnung von Zeit und Ressourcen).	—
		SE 7-SW SW-Integration
		SW-Einheit wird durch ein Fertigprodukt realisiert.	Die SW-Integration entfällt.
—		SE 7.1-SW Zur SW-Komponente integrieren
		Die SW-Architektur sieht keine SW-Komponenten vor.	—
		SE 7.2-SW Selbstprüfung der SW-Komponente durchführen
		Die Selbstprüfung obliegt dem Entwickler und wird nicht vom Projektleiter im Produkt "Projektplan" berücksichtigt (Zuordnung von Zeit und Ressourcen).	—
—	—	SE 7.3-SW Zur SW-Einheit integrieren
		SE 7.4-SW Selbstprüfung der SW-Einheit durchführen
		Die Selbstprüfung obliegt dem Entwickler und wird nicht vom Projektleiter im Produkt "Projektplan" berücksichtigt (Zuordnung von Zeit und Ressourcen).	—
—	—	SE 8 System-Integration
—		SE 8.1 Zum System integrieren
		Das System besteht nur aus einer SW-Einheit.	—
		SE 8.2 Selbstprüfung des Systems durchführen
		Die Selbstprüfung obliegt dem Entwickler und wird nicht vom Projektleiter im Produkt "Projektplan" berücksichtigt (Zuordnung von Zeit und Ressourcen).	—
—	—	SE 8.3 Produkt bereitstellen
—	—	SE 9 Überleitung in die Nutzung
		SE 9.1 Beitrag zur Einführungsunterstützung leisten
		Eine Einführungsunterstützung ist nicht erforderlich.	—
		SE 9.2 System installieren
		Das System wird bereits in der Zielumgebung entwickelt.	—
—	—	SE 9.3 In Betrieb nehmen


Streichen von Produkten
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.4	Streichbedingungen

T.4.4	Streichen von Produkten

Nachdem die Aktivitäten zur Streichung markiert sind, können noch (Teil-) Produkte gestrichen werden. Dies ist nicht der Regelfall, da mit der Streichung von Aktivitäten auch die Streichung ihrer Ergebnisse (beschrieben in der Spalte "Auswirkungen") einhergeht.

Die Streichung der (Teil-) Produkte hat ebenso begründet zu erfolgen. Es folgen einige Beispiele:

AT	TT	Produkt/Begründung zur Streichung	Auswirkungen
		Produkt "Arbeitsauftrag"
		Die Vergabe von Arbeitsaufträgen erfolgt mündlich.	Aktivität PM 12 wird nicht gestrichen.
		Produkt "Systemarchitektur.Lösungsvorschläge"
		Der Entwurf ist durch Voruntersuchungen vorgegeben.	Das Kapitel "SysArc.Lösungsvorschläge" entfällt.


Aktivitäten- und Produkte-Auswahlformblatt
Teil 3	Vorgehensmodell / Handbuchsammlung

T	Tailoring und projektspezifisches V-Modell

T.5	Aktivitäten- und Produkte-Auswahlformblatt

Hinweise zur Anwendung der Formblätter:
Die beim Tailoring ausgewählten Aktivitäten und Produkte werden markiert. Produkte sind als Ergebnis derjenigen Aktivitäten angegeben, die das betreffende Produkt fertigstellen.

Submodell SE

Submodell QS

Submodell KM

Submodell PM


Abbildungsverzeichnis AU250/3 - T
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - T)

A.1	Abbildungsverzeichnis

Abbildung T.1:	Beispiel für die unterschiedliche Relevanz von Regelungen

Abbildung T.2:	Anwendung des Tailoring

Abbildung T.3:	Klassifizierung der Vorhabentypen

Abbildung T.4:	Anwendung der Streichbedingungen

Abbildung T.5:	Erstellung, Prüfung und Dokumentation des projektspezifischen V-Modells

Abbildung T.6:	Darstellung der unterschiedlichen Tailoringverfahren

Abbildung T.7:	Beispiel einer Aktivitätenanpassung

Abbildung T.8:	Vorhabentypen und Merkmalswerte

Abbildung T.9:	Prinzipieller Aufbau der Tailoring-Formblätter

Abbildung T.10:	SE für kleine administrative IT-Vorhaben

Abbildung T.11:	SE für mittlere administrative IT-Vorhaben

Abbildung T.12:	QS und KM für kleine und mittlere administrative IT-Vorhaben

Abbildung T.13:	SE für große administrative IT-Vorhaben

Abbildung T.14:	QS und KM für große administrative IT-Vorhaben

Abbildung T.15:	SE für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Abbildung T.16:	QS und KM für kleine/mittlere technisch-wissenschaftliche IT-Vorhaben

Abbildung T.17:	SE für große technisch-wissenschaftliche IT-Vorhaben

Abbildung T.18:	QS und KM für große technisch-wissenschaftliche IT-Vorhaben

Abbildung T.19:	SE für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Abbildung T.20:	QS und KM für Auswahl, Beschaffung und Anpassung von Fertigprodukten

Abbildung T.21:	PM für kleine und mittlere IT-Vorhaben

Abbildung T.22:	PM für große IT-Vorhaben


Tabellenverzeichnis AU250/3 - T
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - T)

A.2	Tabellenverzeichnis

Tabelle T.1:	Mindestanforderungen im Submodell SE

Tabelle T.2:	Mindestanforderungen in den Submodellen QS, KM und PM


Zielsetzung des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.1	Zielsetzung des V-Modells

Ziel des V-Modells ist es, die bei der Entwicklung und bei Pflege- und Änderungsmaßnahmen von IT-Systemen entstehenden Produkte gewissen Standards zu unterwerfen. Dadurch soll eine Mindestqualität der Ergebnisse sichergestellt werden und der Weg eines Produktes von der Anforderungsdefinition bis zur Fertigstellung besser nachvollziehbar sein. Präzise Festlegungen erleichtern die Kommunikation zwischen den Beteiligten und machen das Projekt besser steuerbar.

Das V-Modell regelt die Tätigkeiten und Ergebnisse im Entwicklungsprozeß. Dabei wird nicht nur der Erstellungsprozeß im engeren Sinn beschrieben, sondern Qualitätssicherung, Konfigurationsmanagement und Projektmanagement werden als integraler Bestandteil mit betrachtet.

Das V-Modell berücksichtigt die verschiedenen Besonderheiten, wie sie bei der Entwicklung von IT-Systemen in der Bundesverwaltung gegeben sind:

−	Besonderheiten kritischer Realzeit-Software, die sich zum einen aus der Struktur der Systeme, wo die Software nur ein Teil eines komplexen Ganzen ist, zum anderen aus der Struktur der Entwicklungsvorhaben selbst ergeben, da hier für das Management auf der oberen Ebene die softwarespezifischen Aspekte nicht transparent werden.

−	Erfordernisse, die bei einer Zertifizierung von vertrauenswürdiger Software nach den IT-Sicherheitskriterien erfüllt sein müssen.

−	Besonderheiten detaillierter Informationsmodellierung, wie sie bei der Entwicklung von Informationssystemen erforderlich ist.

−	Wechselwirkung zwischen Software und Hardware, wie sie bei der Entwicklung von Echtzeitsystemen die Vorgehensweise beeinflußt.

−	Wechselwirkung zwischen Software und Verfahrensdefinition, wie sie bei der Entwicklung von Informationssystemen im Vordergrund steht.

−	Besonderheiten, die sich aus hohen Anforderungen an die zu realisierende Software hinsichtlich Zuverlässigkeit, Änderbarkeit, Übertragbarkeit und Wiederverwendbarkeit ergeben.

Das V-Modell beschreibt den Entwicklungsprozeß aus rein funktionaler Sicht. Spezielle Organisationsformen werden nicht behandelt, da es in unterschiedlichen Behörden/Firmen/Einrichtungen zum Einsatz kommen soll. Deshalb muß zu Beginn eines Projekts eine Zuordnung der Aktivitäten und Rollen des V-Modells auf die organisatorischen Einheiten und auf die Verantwortlichen erfolgen.

Durch diese Beschränkung auf rein technische Regelungen ist es möglich, dieses Modell, nach Anpassungen an organisatorische Gegebenheiten, auch bei internationalen Vorhaben bzw. als Firmenstandard einzusetzen.

Bei der Erarbeitung des V-Modells wurden die Erfahrungen und Standardisierungsbemühungen im nationalen und internationalen Umfeld soweit wie möglich berücksichtigt.


Anwendung des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.2	Anwendung des V-Modells

Die Verwendungsformen des V-Modells sind in Abschnitt UMF.8 beschrieben.

Ergänzend zu den dort beschriebenen Verwendungen ist darauf hinzuweisen, daß das V-Modell auch Unterstützung bietet

−	als Leitfaden,

−	als Checkliste und

−	für die Qualitätszieldefinition.


Verwendung als Leitfaden
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.2	Anwendung des V-Modells

UMF.2.1	Verwendung als Leitfaden

Das V-Modell wurde allgemeingültig formuliert, damit es auf Projekte mit sehr unterschiedlichen Charakteristiken angewendet werden kann.

Dies macht für jedes Projekt, das nach dem V-Modell abgewickelt wird, die "Extrahierung" (Tailoring) eines projektspezifischen konkreten V-Modells aus der umfassenden Gesamtdarstellung erforderlich. Diese Extrahierung wird nicht vollständig durch Angabe objektivierbarer Kriterien automatisierbar sein, da Projekte sich nicht bis ins Detail schematisch klassifizieren lassen. Deshalb ist für die Festlegung des Projekthandbuchs ein fundiertes Verständnis der Abhängigkeiten im Projektablauf erforderlich.

Das V-Modell verdeutlicht diese Abhängigkeiten und hilft bei der Bewertung der Projekt-Charakteristika.


Verwendung als Checkliste
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.2	Anwendung des V-Modells

UMF.2.2	Verwendung als Checkliste

Im jeweiligen Projekt muß anhand des V-Modells festgelegt werden,

−	welche Produkte erforderlich sind,

−	welche Zustände ein Produkt durchlaufen muß,

−	welche Inhalte ein Produkt haben muß und

−	wer was wann im Projekt zu erledigen hat.

Für die Verwendung als Checkliste enthält das V-Modell vollständige Aufstellungen der entsprechenden Sachverhalte.


Verwendung als Qualitätszieldefinition
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.2	Anwendung des V-Modells

UMF.2.3	Verwendung als Qualitätszieldefinition

Anhand des V-Modells werden die qualitativen Eigenschaften der zu erstellenden Zwischen- und Endprodukte so definiert, daß eine Überprüfung mit vertretbarem Aufwand möglich ist.

Grundsätzlich sind hier zu unterscheiden:

−	Kriterien, deren Erfüllung formal, z. B. im Rahmen der Produkt-Abnahme, geprüft werden kann.

Beispiel: Existenz bestimmter Zwischenprodukte, Verwendung vorgegebener Formulare.

−	Kriterien, deren Erfüllung nur durch einen "Beurteilungsprozeß" bewertet werden kann.

Im Gegensatz zu den erstgenannten Kriterien sind hier "Ja/Nein-Entscheidungen" nicht immer möglich.

Beispiel: Konsistenz zwischen Architektur und Anwenderforderungen.

Diese Unterscheidung zwischen den Arten der Kriterien ist erforderlich, da sich in Abhängigkeit davon unterschiedliche Auswirkungen auf die Formulierung des Prüfprozesses ergeben:

Während eine formale Prüfung durch einen (oft trivialen) Soll-Ist-Vergleich abzuhandeln ist, müssen bei einem "Beurteilungsprozeß" Erfolgskriterien vorgegeben werden, anhand derer die Beurteilung durchgeführt wird. Ziel des V-Modells ist es, die qualitativen Eigenschaften der zu erstellenden Produkte so zu definieren, daß einerseits formale Prüfungen mit möglichst geringem Aufwand (gegebenenfalls maschinell) erledigt werden können, andererseits die notwendigerweise aufwendigen Beurteilungsprozesse effizient durchgeführt werden können und objektive Ergebnisse liefern.

Insgesamt können die Regelungen zur Qualitätszieldefinition erfolgen über

−	Produktmuster,

−	Formulare,

−	Prüfvorschriften.


Unterschiedliche Einsatzsituationen
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.3	Unterschiedliche Einsatzsituationen

Für den Einsatz des V-Modells entsprechend einer der beschriebenen Verwendungsformen müssen folgende Situationen unterschieden werden:

a)	Es handelt sich um eine Neuentwicklung einschließlich der Verwendung von Fertigprodukten im Rahmen eines neu aufzusetzenden Projektes.

b)	Es handelt sich um ein bereits laufendes Projekt, bei dem als Richtlinie bisher nicht das V-Modell angewandt wurde.

c)	Es handelt sich um ein SWPÄ-Projekt, wobei die Entwicklung und evtl. vorangegangene SWPÄ-Projekte nach anderen Richtlinien oder einer Vorversion des V-Modells durchgeführt wurden.

Bei diesen genannten drei verschiedenen Ausgangssituationen beim Einsatz des V-Modells sind ergänzend zu den immer erforderlichen Schritten

−	Abbildung der Submodelle und Rollen des V-Modells auf die jeweils zugrundeliegende Behörden-/Unternehmensstruktur bzw. Modifikation der bestehenden Aufbau- und Ablauforganisation

−	Tailoring des V-Modells auf die produkt- und projektspezifischen Gegebenheiten

−	Schulung der Mitarbeiter in der Anwendung des V-Modells und Aufzeigen der zu beachtenden Unterschiede zu bislang eingesetzten Standards

 noch jeweils spezielle Untersuchungen und Initialisierungsaktivitäten durchzuführen:

Fall a:	Neuentwicklung in einem neuen Projekt:

Das V-Modell ist als Entwicklungsrichtlinie und -standard einzusetzen. Es sind keine speziellen Initialisierungsmaßnahmen erforderlich.

Fall b:	Laufendes Projekt unter einer anderen Richtlinie:

1.	Zuordnung der Produkte und Aktivitäten zwischen dem V-Modell und der bisher eingesetzten Richtlinie.

2.	Ermitteln von

−	bereits geleisteter Vorarbeit für V-Modell-Aktivitäten und -Produkte und

−	noch ausstehender Arbeit für V-Modell-Aktivitäten und -Produkte.

3.	Definieren eines geeigneten Aufsetzpunktes für das V-Modell.

4.	Nachziehen der für den Richtlinienwechsel erforderlichen Arbeiten und evtl. Transformation von Produkten gemäß den Richtlinien des V-Modells (Nachdokumentation).

5.	Eingehende QS-Prüfung der nun vollständig vorliegenden Ergebnisse für den nachfolgenden Einsatz des V-Modells.

6.	Weiterentwicklung im Projekt nach den Regelungen des V-Modells.

Fall c:	Neu startendes oder laufendes SWPÄ-Projekt (bisher andere Richtlinie oder Vorversion des V-Modells eingesetzt)

Es ist analog Fall b) vorzugehen, wobei in Arbeitsschritt 2 nur die noch ausstehende Arbeit zu ermitteln ist und Arbeitsschritt 3 ganz entfällt.


Adressaten des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.4	Adressaten des V-Modells

Das V-Modell betrifft die folgenden Adressaten.

a)	Querschnittliche Einrichtungen

Sie sind für Einführung von Verfahren und Methoden in ihrem jeweiligen Bereich zuständig. Ihre Aufgaben in bezug auf das V-Modell sind:

−	Verteilung

−	Schulung

−	Sammlung von Erfahrungen/Anregungen der Anwender

−	Fortschreibung

b)	Anwender, IT-Referate und vertragsführende Stellen

Ihnen dienen V-Modell und Projektstandards als Grundlage für die

−	Spezifikation der Anwenderforderungen

Der Anwender definiert und verfeinert seine Forderungen an das System und spezielle Anteile. Das V-Modell dient als Richtlinie für die Spezifikation dieser Forderungen.

−	Vertragsgestaltung

Hier dient das V-Modell als Referenzinstrument für die Technische Leistungsbeschreibung. Die Festlegung von Art und qualitativen Eigenschaften der zu liefernden Produkte ist anhand des V-Modells durchzuführen.

−	Projektsteuerung/Projektbegleitung

Hierunter sind Planung, Kontrolle und Koordination der durchzuführenden Aufgaben zu verstehen.

Das V-Modell unterstützt dabei

•	die Festlegung der erforderlichen Aktivitäten/Produkte,

•	die Auswahl geeigneter Hilfsmittel,

•	die Abschätzung erforderlicher Ressourcen,

•	die Festlegung des zeitlichen Projektablaufs,

•	die Initiierung der erforderlichen Aktivitäten zum günstigsten Zeitpunkt.

−	Produktabnahme

Während im Rahmen der Vertragsgestaltung Art und qualitative Eigenschaften der zu liefernden Produkte festgelegt werden, ist bei der Abnahme die Einhaltung dieser vertraglichen Vereinbarungen zu überprüfen.

−	SW-Pflege und -Änderung (SWPÄ)

Hier liefert das V-Modell den Orientierungsrahmen, der eine möglichst effiziente Einarbeitung in die zu pflegenden Produkte gewährleisten soll. Außerdem legt das V-Modell bzgl. SWPÄ eine Vorgehensweise analog zum Entwicklungsprozeß nahe.

−	Entwicklung

Für bestimmte Vorhaben werden im Behördenbereich selbst Entwicklungsaktivitäten durchgeführt. In diesem Fall ist dieselbe Verwendungsart des V-Modells relevant wie unter c) beschrieben.

c)	Institutionen, die mit der Entwicklung beauftragt sind

Das V-Modell gibt einen Rahmen für den gesamten technischen Entwicklungsprozeß bei einem Auftragnehmer. Dazu gehört

−	die Vorgabe von Vorgehensweisen bei der Entwicklung durch Festlegung von Art, Umfang und Abfolge der Aktivitäten,

−	die Vorgabe von Inhalt, Form und qualitativen Eigenschaften der zu erstellenden Produkte,

−	die Behandlung aller im Entwicklungsgang entstehenden Produkte durch PM, QS und KM.

Damit wird jeder Entwickler hinsichtlich seiner Tätigkeit derart geführt, daß die reibungslose Übernahme von Produkten durch den Auftraggeber auch im Hinblick auf SWPÄ-Maßnahmen so gut wie möglich gewährleistet wird.


Konzeption des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.5	Konzeption des V-Modells

Das V-Modell wird von folgenden Prinzipien bestimmt:

−	Methoden- und Werkzeugunabhängigkeit,

−	Organisationsunabhängigkeit,

−	Trennung in vier "Submodelle",

−	Orientierung an Aktivitäten und Produkten,

−	Anpaßbarkeit des Modells.

Die Gründe und Absichten dieser speziellen Konzeption sind in der Zusammenfassung wie folgt:

Methoden- und Werkzeugunabhängigkeit

Das V-Modell selbst hat die Anforderung zu erfüllen, in verschiedensten Projekten und Entwicklungsumgebungen einsetzbar zu sein, und muß sich daher in seinen Regelungen von Festlegungen bestimmter Methoden oder Werkzeugen fernhalten. (Eine Standardisierung der einzusetzenden und anwendbaren Methoden hat separat zu erfolgen.)

Organisationsunabhängigkeit

Im V-Modell wird grundsätzlich nur von Funktionen und Rollen gesprochen, nicht aber von Instanzen und organisatorischen Einheiten. Dies hat seine Ursache darin, daß das V-Modell in unterschiedlichen Organisationsformen zum Einsatz kommen soll. Die verschiedenen Organisationen weisen erstens unterschiedliche Strukturen und Terminologie auf, sind zweitens nicht von vornherein alle in ihren verschiedenen Ausprägungen bekannt und sind drittens im Laufe der Zeit selbst Änderungen unterworfen. Nur durch Organisationsunabhängigkeit kann deshalb das V-Modell stabil und universell einsetzbar bleiben.

Trennung in vier "Submodelle"

Im V-Modell werden Funktionen/Aktivitäten mit gleicher Thematik in sogenannte Submodelle zusammengefaßt. Das V-Modell gliedert sich in vier solcher Submodelle:

−	Submodell SE (Systemerstellung) mit konstruktiven, entwickelnden Tätigkeiten,

−	Submodell QS (Qualitätssicherung) mit prüfenden Tätigkeiten,

−	Submodell KM (Konfigurationsmanagement) mit produktverwaltenden und änderungs-verfolgenden Tätigkeiten,

−	Submodell PM (Projektmanagement) mit planenden und steuernden Tätigkeiten.

Orientierung an Aktivitäten und Produkten

Das V-Modell weist nicht, wie viele andere Modelle, eine Orientierung an Phasen auf. Phasen geben immer eine zeitliche Einteilung wieder, die den Projektfortschritt zu starr reglementieren. Das V-Modell orientiert sich deshalb an den in einem Projekt durchzuführenden Aktivitäten und zu behandelnden Produkten.

Eine Einordnung der durchzuführenden Aktivitäten in den zeitlichen Phasenablauf eines Projekts muß jeweils projektspezifisch vorgenommen werden.


Das Richtlinienumfeld des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.6	Das Richtlinienumfeld des V-Modells

Neben dem V-Modell sind in einem Projekt in der Regel noch weitere Richtlinien und Standards zu berücksichtigen. Es handelt sich hierbei um

−	nationale und internationale Normen und Standards,

−	Produkt- bzw. Projektstandards,

−	bereichsspezifische Standards (z. B. AU 220 im BMVg-Bereich, Phasenmodell nach BVB im Bereich der Bundesverwaltung),

−	Firmenstandards.

Solche Standards auf unterschiedlichen Ebenen sind nur teilweise untereinander kompatibel. Im Falle von Inkompatibilität sind projektspezifisch Präferenzen festzulegen.

Von Firmenstandards auftragnehmender Firmen, die bei der Projektabwicklung eingesetzt werden sollen, wird verlangt, daß sie mit dem V-Modell kompatibel sind. Kompatibilität bedeutet dabei die eindeutige Zuordenbarkeit aller Aktivitäten/Teilaktivitäten einschließlich zugehöriger Produkte des V-Modells zu Beschreibungselementen des Firmenstandards.

Kompatibilität schließt dabei nicht aus, daß die Regelungen des Firmenstandards einen über das V-Modell hinausgehenden Detaillierungsgrad aufweisen.


V-Modell und Phasenmodelle
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.7	V-Modell und Phasenmodelle

Das V-Modell stellt eine Beschreibung aller Tätigkeiten (Aktivitäten) und Ergebnisse für die Entwicklung von IT-Systemen dar. Die Aktivitätenbeschreibungen bestehen aus Handlungsanweisungen. Es besteht kein Zwang, die Aktivitäten in einer bestimmten zeitlichen Reihenfolge auszuführen. Die zeitliche Anordnung der V-Modell-Aktivitäten kann jedoch durch andere Modelle vorgegeben werden. Die bekanntesten dieser Modelle sind z. B. das Wasserfallmodell, das in neuerer Zeit sehr favorisierte Spiralmodell und, bedingt durch administrative Vorgaben, Phasenmodelle wie z. B. der AU 220 im Geltungsbereich des BMVg und das Phasenmodell nach BVB (zukünftig EVB) im Bereich der Bundesverwaltung.

Abbildung UMF.1: Beispiel eines zeitlichen Aktivitätenverlaufs

Um keine Verwirrung entstehen zu lassen, wird daher im V-Modell nie die Bezeichnung "Phase" verwendet, sondern lediglich die Bezeichnung "Aktivität". Aktivitäten können sich überlappen, sie können iterativ oder rekursiv ausgeführt werden. Die Reihenfolge und Auswahl der V-Modell-Aktivitäten wird durch das zugeordnete (Phasen-) Modell bestimmt.

Phasenmodelle erzwingen einen zeitlich linearen Ablauf der Phasen. Wiederholtes Durchlaufen von Phasen ist prinzipiell möglich, jedoch durch den bestehenden Formalismus beim Phasenübergang in der Praxis nicht üblich.

Jede Phase enthält eine Reihe von groben Ausführungsanweisungen und endet mit einer Entscheidungsvorlage. In ihr sollen alle Ergebnisse/Erkenntnisse einer jeden Phase zusammengefaßt werden, so daß anhand dieser Vorlage entschieden werden kann, ob die Ziele der gegenwärtigen Phase erreicht wurden und ob ein Übergang zur nächsten Phase begonnen werden kann.


Verwendungsformen des V-Modells
Teil 3	Vorgehensmodell / Handbuchsammlung

UMF	Einordnung des V-Modells in sein Umfeld

UMF.8	Verwendungsformen des V-Modells

Für das V-Modell sind im wesentlichen zwei Verwendungsformen vorgesehen:

−	als Vertragsgrundlage

−	als Arbeitsanleitung

In beiden Verwendungsformen kommt es sowohl im Behörden-/Amtsbereich als auch in der Industrie zum Einsatz. Abbildung UMF.2 zeigt die Einsatzbereiche mit Hauptauftragnehmer (HAN) und Unterauftragnehmer (UAN).

Abbildung UMF.2: V-Modell-Einsatz in unterschiedlichen Situationen

1.	Anwendung im Behörden-/Amtsbereich bei der Abwicklung eines Vorhabens.

Hier ist zu unterscheiden:

a)	Entwicklungsaktivitäten laufen im Behörden-/Amtsbereich selbst.

b)	Durch den Behörden-/Amtsbereich werden lediglich projektbegleitende Funktionen wahrgenommen, die Entwicklung selbst erfolgt durch industrielle Auftragnehmer.

In beiden Fällen ist ein Projekthandbuch (PHb) für den gesamten Projektverlauf durch Tailoring abzuleiten, wobei im Fall b) lediglich die behördlichen Begleitfunktionen (in der Regel PM und QS) zu berücksichtigen sind.

Abbildung UMF.3: Geltungsbereich des Gesamt-Projekthandbuchs

In den Fällen, in denen das Projekthandbuch als Entwicklungsrichtlinie eingesetzt wird, sind ergänzend zu den reinen Methoden- und Werkzeugfestlegungen gegebenenfalls detaillierte Arbeitsanleitungen zum methodenbasierten Vorgehen anzugeben.

2.	Anwendung als Vertragsgrundlage zwischen AG (Behörde/Amt) und HAN (Hauptauftragnehmer)

Hier stehen die Vereinbarungen zwischen AG und HAN bzgl.

−	der Streichbedingungen des Technischen Tailoring,

−	durchzuführenden Aktivitäten und Produkten der Submodelle,

−	anzuwendenden Methoden und Werkzeuge,

−	anzuwendenden Standards und Richtlinien und

−	der Projektregeln

im Vordergrund.

Da ein Gesamtprojekt in mehreren Verträgen abgewickelt werden kann (u. U. auch mit unterschiedlichen Hauptauftragnehmern), sind entsprechend mehrere Projekthandbücher, jeweils für einen Abschnitt des Gesamtprojekts, durch Tailoring abzuleiten:

Abbildung UMF.4: Geltungsbereich zweier HAN-Projekthandbücher

In diesem Zusammenhang ist zu beachten, daß jede nachträgliche Änderung der Tailoringergebnisse Auswirkungen auf den Vertrag hat. Entsprechend sollten Aussagen über den Detaillierungsgrad der Abwicklung nur insoweit festgeschrieben werden, als sie tatsächlich für die Vertragsabwicklung erforderlich sind.

3.	Anwendung für Vertragsgestaltung zwischen HAN und UAN:

Die Situation entspricht weitgehend derjenigen zwischen Behörde/Amt und Hauptauftragnehmer, wobei allerdings ein HAN gleichzeitig/überlappend Vertragsverhältnisse zu mehreren UAN unterhalten kann. Für die Erstellung der Projekthandbücher bieten sich mehrere Alternativen an:

−	jeweils ein separates Projekthandbuch je UAN, wobei jedes UAN-Projekthandbuch eine Teilmenge des HAN-Projekthandbuchs ist,

oder

−	ein gemeinsames Projekthandbuch für jeden HAN und seine UANs, wobei kenntlich zu machen ist, welche Aktivitäten und Produkte für den jeweiligen UAN verbindlich sind.

Abbildung UMF.5 zeigt diesen Sachverhalt.

Abbildung UMF.5: Geltungsbereich der Projekthandbücher

4.	Anwendung als Entwicklungsrichtlinie bei HAN/UAN

Die in Fällen 2. und 3. im Projekthandbuch vertraglich vereinbarten generischen Aktivitäten und Produkte sind durch das Technische Tailoring hinsichtlich der Festlegung des Detaillierungsgrades zu präzisieren. Mit der Beauftragung der Arbeitspakete sind gegebenenfalls Verweise auf firmeninterne Regelungen zur Arbeitsabwicklung zu ergänzen. Hierbei ist aber streng auf Konsistenz mit den bereits getroffenen Festlegungen des Projekthandbuchs zu achten.

In dieser Situation ist auch zu beachten, daß für die firmeninterne Entwicklungstätigkeit durchaus Produkte, die vom AG beim Tailoring als "nicht relevant" eingestuft wurden, für interne Zwecke wieder zu einem verbindlichen Zwischenergebnis des Entwicklungsprozesses definiert werden können. Damit ist die als Vertragsbasis herbeigeführte Tailoringentscheidung nicht in Frage gestellt!


Abbildungsverzeichnis AU250/3 - UMF
Teil 3	Anhang zur Handbuchsammlung  (AU250/3 - UMF)

A.1	Abbildungsverzeichnis

Abbildung UMF.1:	Beispiel eines zeitlichen Aktivitätenverlaufs

Abbildung UMF.2:	V-Modell-Einsatz in unterschiedlichen Situationen

Abbildung UMF.3:	Geltungsbereich des Gesamt-Projekthandbuchs

Abbildung UMF.4:	Geltungsbereich zweier HAN-Projekthandbücher

Abbildung UMF.5:	Geltungsbereich der Projekthandbücher


Wann ist das V-Modell anzuwenden?
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.1	Wann ist das V-Modell anzuwenden?

Das V-Modell regelt im Geschäftsbereich des BMVg die Entwicklung, Regeneration, Integration und Migration sowie die Pflege und Änderung von IT-Systemen 1). Für das V-Modell werden nur die Systeme betrachtet, deren Aufgabenerfüllung vorwiegend durch den Einsatz von IT realisiert wird. Dazu zählen neben den IT-Systemen auch IT/DV-Anteile in anderen Systemen (siehe Teil 1, Abschnitt 1).

1)	IT-Systeme sind entsprechend ISO 12207 definiert als ein einheitliches Ganzes, das aus einem oder mehreren Prozessen, Hardware, Software, Einrichtungen und Personen besteht, das die Fähigkeit besitzt, vorgegebene Forderungen oder Ziele zu befriedigen.

Gemäß der "Leitlinie für Einsatz/Nutzung der Informationstechnik" (IT-Leitlinie) umfaßt die Informationstechnik (IT) SW-, HW- und Kommunikationsanteile. Entsprechend umfassen IT-Anteile neben den SW- und HW-Einheiten auch die Kommunikationsanteile, während DV-Anteile nur aus HW- und SW-Einheiten bestehen.

Das V-Modell verwendet nur den Begriff "IT-Anteil".

Zentrale Regelung für die Durchführung von Vorhaben sind die "Bestimmungen für die Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben" (AU 220). Sie beschreiben aufbau- und ablauforganisatorische Regelungen für das Management eines Vorhabens, wie beispielsweise die Festlegung bestimmter Aufgabenträger und deren Zuständigkeiten (z. B. Vorhabenmanager), die Einrichtung und Aufgabenverteilung bestimmter Gruppen (z. B. Studiengruppen) sowie die zeitliche Aufteilung eines Vorhabens in Phasen. Wesentlich ist der Gesichtspunkt, Vorhaben in die Bundeswehr-Planung einzubinden und die Zuständigkeiten und Verantwortlichkeiten der einzelnen Vorhabenbeteiligten und der beteiligten Gremien festzulegen.

Die Entwicklung, Regeneration, Integration und Migration sowie die Pflege und Änderung von IT-Systemen bzw. IT/DV-Anteilen in Systemen erfolgt gemäß AU 220 in Verbindung mit dem AU 250 (siehe Abbildung 1.1).

Bei DV-Vorhaben, die die Entwicklung/Bereitstellung von Funktionalitäten zum Ziel haben, ist das V-Modell in jedem Fall anzuwenden (siehe Abschnitt 1.2). Bei Wehrmaterial ist das V-Modell für die Entwicklung, Regeneration, Integration und Migration der IT/DV-Anteile sowie deren Pflege und Änderung einzusetzen (siehe Abschnitt 1.3).

Der im V-Modell verwendete Begriff "Projekt" ist mit dem im Bundeswehrsprachgebrauch üblichen Begriff "Vorhaben" gleich zu setzen. Die Aktivitäten des Submodells Projektmanagement werden im Rahmen des Vorhabenmanagements durchgeführt.

Abbildung 1.1: Zuordnung von Wehrmaterial und DV-Vorhaben zu AU 220 und AU 250


Anwendung des V-Modells bei DV-Vorhaben
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.2	Anwendung des V-Modells bei DV-Vorhaben

Neben dem V-Modell und dem AU 220 (EEDV) sind im Umfeld von DV-Vorhaben weitere Regelungen zu beachten. Oberste Regelung sind die IT-Richtlinien der Bundesregierung und darauf basierende Folgedokumente im Geschäftsbereich des BMVg.

Insbesondere IT-Konzepte sind die Planungsdokumente zur Festlegung der Soll-Vorstellungen bezüglich der IT-Unterstützung der Dienststellen bzw. Dienststellentypen. In ihnen werden die aufgabenorientierten Planungen der relevanten DV-Vorhaben mit den organisationsorientierten Planungen der Dienststelle verknüpft und zwar unter Berücksichtigung der vorhandenen bzw. geplanten IT-Infrastruktur. Aus der Differenz ergibt sich der noch nicht gedeckte IT-Ausstattungsbedarf auf Dienststellenebene. Relevante DV-Vorhaben können organisationsbereichsbezogen (z. B. innerhalb einer TSK) oder organisationsbereichsübergreifend für den gesamten Geschäftsbereich des BMVg sein.

Das V-Modell gilt in Ergänzung zum AU 220 als technische Richtlinie, in der die Entwicklung, Regeneration, Integration und Migration von IT-Systemen detailliert geregelt wird.

Der AU 220 bildet den übergeordneten Gesamtrahmen für ein Vorhaben, das V-Modell stellt in diesem Rahmen ein Element der Entwicklungsfeinsteuerung dar (für den Bereich der Entwicklung, Regeneration, Integration und Migration von IT-Systemen). Für weitere Spezialdisziplinen, z. B. IT-Sicherheit und IT-Infrastruktur, existieren eigene Standards.

Abbildung 1.2 illustriert die Zusammenhänge zwischen IT-Leitlinie, AU 220 (Teil III, EEDV) und AU 250.


Entwicklung von DV/IT-Anteilen im Kontext der Systementwicklung
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.3	Anwendung des V-Modells im Rahmen des EBMat

1.3.1	Entwicklung von DV/IT-Anteilen im Kontext der Systementwicklung

Bei Wehrmaterial ist im allgemeinen zu Beginn einer Systementwicklung nicht bekannt, ob das zu entwickelnde System einen DV/IT-Anteil enthält. Die Entwicklung beginnt gemäß den im AU 220 (EBMat) definierten Arbeitsschritten des Phasenvorlaufs. Die Anwendung des V-Modells setzt ein, sobald ein DV/IT-Anteil identifiziert worden ist. Die für den DV/IT-Anteil relevanten fachlichen Anforderungen sind in den Anwenderforderungen festzulegen. Die bereits existierende Dokumentation kann als Anwenderforderungen im Sinne des V-Modells verwendet werden, sofern sie alle relevanten Informationen enthält.

Ist aufgrund erster Architekturvorstellungen und Erfahrungen aus ähnlichen Vorhaben die Existenz eines DV/IT-Anteils zu erwarten, ist die Anwendung des V-Modells bereits zu Beginn sicherzustellen. Die Entscheidung trifft die Studiengruppe.


Erfordernis einer übergeordneten Einheitlichkeit
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.3	Anwendung des V-Modells im Rahmen des EBMat

1.3.2	Erfordernis einer übergeordneten Einheitlichkeit

Die Durchführung von Vorhaben erfordert eine systematische Vorgehensweise sowohl im eigentlichen Entwicklungsbereich als auch bei den begleitenden Tätigkeiten wie Projektmanagement (PM), Qualitätssicherung (QS) und Konfigurationsmanagement (KM).

Bei DV/IT-Anteilen in Systemen sind die Aktivitäten, die sich aus der Anwendung des V-Modells ergeben, eingebunden in den Prozeßablauf, der sich aus der Steuerung des übergeordneten Systems ergibt (z. B. Waffensystem). Eine erfolgreiche Systementwicklung erfordert eine aufeinander abgestimmte Entwicklung von DV/IT-Anteilen (gemäß V-Modell) und von Nicht-IT-Anteilen/Nicht-DV-Anteilen.

Bei Systemen mit DV/IT-Anteil stellt sich die Aufgabe, die Tätigkeiten insbesondere von PM, QS und KM in einheitlicher Weise für das System (DV/IT-Anteil und Nicht-IT-Anteil/Nicht-DV-Anteil) festzulegen, so daß innerhalb des Vorhabens eine homogene Abwicklung entsteht. Hierzu sind zwei Ansätze möglich:

−	Die bereits auf der Ebene des Nicht-IT-Anteils/Nicht-DV-Anteils spezifizierten Maßnahmen werden auf die Entwicklung des DV/IT-Anteils übertragen; hierbei ist den Forderungen des V-Modells sinngemäß Rechnung zu tragen.

−	Auf der Basis der V-Modell-Vorgaben wird ein für das Gesamtsystem ausgelegtes Projekt-, Qualitäts- und Konfigurationsmanagement definiert, das die entsprechenden Aktivitäten und Produkte sowohl für den Entwicklungsprozeß des Nicht-IT-Anteils/Nicht-DV-Anteils als auch für den Entwicklungsprozeß des DV/IT-Anteils enthält. Die Festlegungen erfolgen zu Beginn des Vorhabens, die DV/IT-Anteile sind zu diesem Zeitpunkt notwendigerweise noch nicht identifiziert. Nachträgliche Änderungen bereits getroffener Festlegungen aufgrund der Identifikation von DV/IT-Anteilen sind zu vermeiden.

Abbildung 1.2: Zusammenhang IT-Leitlinie, AU 220 (Teil III, EEDV) und AU 250


Zuordnung der Rollen des V-Modells zu den Aufgabenträgern im Amtsbereich
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.4	Zuordnung der Rollen des V-Modells zu den Aufgabenträgern im Amtsbereich

Das V-Modell legt Rollen fest, deren Träger bestimmte Tätigkeiten (Aktivitäten) durchzuführen haben bzw. an der Durchführung beteiligt sind.

Die Rolle des Projektmanagers gemäß V-Modell wird je nach Phasenstand durch die Studiengruppe, den Vorhabenmanager bzw. den Nutzungsmanager wahrgenommen.

Die weiteren Rollen sind vorhabenspezifisch zu besetzen.

Der Anwender ist für die Erstellung der Anwenderforderungen verantwortlich. Die Erstellung der Anwenderforderungen ist bei einer inkrementellen Vorgehensweise nicht mit dem Phasenvorlauf abgeschlossen. Aktivität SE 1 "System-Anforderungsanalyse" ist somit gegebenenfalls auch in nachfolgenden Phasen unter der Verantwortung des Anwenders durchzuführen.


Vergabevorbereitung, Vertragsabschluß und Vertragsabwicklung
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

1	Anwendung des V-Modells in Vorhaben der Bundeswehr

1.5	Vergabevorbereitung, Vertragsabschluß und Vertragsabwicklung

Das V-Modell regelt den Systementwicklungsprozeß sowohl auf der AG- als auch auf der AN-Seite. Vergabevorbereitung, Vertragsabschluß und Vertragsabwicklung werden durch die Aktivitäten PM 2 "Vergabe/Beschaffung" und PM 3 "Auftragnehmer-Management" geregelt. Die beiden Aktivitäten werden im folgenden präzisiert. Es wird empfohlen, folgende Regelungen zu beachten (siehe Abbildung 1.3):

PM 2 "Vergabe/Beschaffung"

* Ausschreibung durchführen

Ziel ist es, kompetente Anbieter zur Angebotsabgabe aufzufordern.

Die Ausschreibungsunterlagen sind zu erstellen. Sie müssen den technischen Umfang und die administrativen Rahmenbedingungen (z. B. Meilensteine, Liefertermine, Preisgestaltung, Abrechnungsmodalitäten, allgemeine und besondere Vertragsbedingungen) klar und aussagekräftig beschreiben, damit das gleiche gemeinsame Verständnis aller Bewerber und eine eindeutige Vergleichbarkeit der eingehenden Angebote erreicht werden kann. Den potentiellen AN ist das Projekthandbuch (PHBAG) nach einer Prüfung durch die Vergabestelle zur Darstellung des Projektablaufs zu übergeben.

Basis der Leistungsbeschreibung sind die Anwenderforderungen. Die Anwenderforderungen sind auf der AG-Seite vor der Vergabe einer Prüfung zu unterziehen, an dem der Anwender beteiligt ist. Dabei ist insbesondere sicherzustellen, daß die Anwenderforderungen so definiert sind, daß ihre Erfüllung (im Rahmen der Abnahme) nachgewiesen werden kann. Bereits erstellte Anforderungs- und Spezifikationsdokumente sind als Referenz zu verwenden.

* Angebote erstellen

Der Bieter erstellt auf der Basis der Anwenderforderungen und des PHBAG im Rahmen seines Angebots einen eigenen Vorschlag für ein projektspezifisches PHB (PHBAN), das den spezifischen Beitrag (das Projekt) und die Zusammenarbeit mit dem AG regelt. Dabei hat der Bieter zu gewährleisten, daß bei Angebotsbearbeitung insbesondere

−	die Regeln des V-Modells beachtet werden und

−	die Vorgaben aus dem PHBAG geprüft und bestätigt bzw. Änderungs-/Verbesserungsvorschläge unterbreitet werden.

Der Bieter erstellt auf der Basis der Anwenderforderungen und des PHBAN einen QS-Plan, einen KM-Plan und einen Projektplan.

Der Bieter weist dem AG gegebenenfalls nach, daß er ein zertifiziertes QM-System gemäß ISO 900x betreibt.

* Angebote auswerten

Ziel ist die Auswahl des wirtschaftlichsten Angebots unter Berücksichtigung des gesamten Lebenswegs und damit die Entscheidung für einen Auftragnehmer. Hierzu werden die eingegangenen Angebote unter kaufmännischen, juristischen und fachtechnischen Aspekten geprüft. Grundlage der Bewertung ist das Verfahren (einschließlich der Kriterien), das innerhalb der Durchführung der Ausschreibung definiert wurde.

Sofern sich die Angebotsauswertung auf die Auswahl von Fertigprodukten bezieht, ist zu skizzieren, welche zusätzlichen Eingriffe (Parametrisierung, Ergänzungsprogrammierung, Anpassung, usw.) beim Einsatz der Fertigprodukte erforderlich sind. Erfüllt kein Fertigprodukt alle festgelegten Anforderungen, ist anhand einer Durchführungsentscheidung die Notwendigkeit der Durchführung eines Forderungscontrolling zu klären.

* Vertrag schließen

Ziel ist es, die Bedingungen für die künftige Leistungserbringung des ausgewählten Anbieters festzulegen. Der Umfang der zulässigen Verhandlungen zwischen der Vergabestelle und dem ausgewählten Anbieter über das Angebot richtet sich nach der Vergabeart und den diesbezüglich anzuwendenden Regelungen der VOL/A (insbes. § 24 VOL/A).

Gegebenenfalls wird hierzu das Angebot zwischen dem Auftraggeber und dem ausgewählten Anbieter verhandelt. Unklarheiten werden erörtert; gegebenenfalls muß das Angebot detailliert und präzisiert werden. Die Ergebnisse der Verhandlung sind festzuhalten, eventuell müssen Projekthandbuch, Projektplan, QS-Plan und KM-Plan modifiziert werden. Der Vertrag hat die künftigen Leistungen zu spezifizieren und muß mindestens folgende Elemente enthalten:

−	Leistungsbeschreibung inkl. Nennung der Liefergegenstände und deren Abnahmekriterien,

−	Termine, Zahlungsbedingungen und Zahlungsplan,

−	Vergütung,

−	Gewährleistungskonditionen und Nutzungsrechte,

−	Mitwirkung des AG (falls über die Festlegungen im Projekthandbuch hinausgehend),

−	Festlegung der geplanten Vorgehensweise in einem verbindlichen Projekthandbuch des Auftragnehmers (PHBAN), einem Projektplan, einem QS-Plan und gegebenenfalls einem KM-Plan.

PM 3 "Auftragnehmer-Management"

Änderungen der Leistungsbeschreibung, des Projekthandbuchs (PHBAN) und des QS-Plans sind durch Änderungsvertrag zu vereinbaren.

Die Anwenderforderungen sind Basis der Systemprüfung bei AN und AG und der Abnahme durch den AG. Eine AN-interne Prüfung des Systems gegen die Anwenderforderungen kann eine Abnahmeprüfung durch den AG nicht ersetzen. Sie ist jedoch Voraussetzung für die Abnahme.

Näheres regelt die "Arbeitsweisung Technik" (/AWT/).

Abbildung 1.3: Anwendung des V-Modells bei der Vergabe von Einzelaufträgen


Zusammenhang zwischen V-Modell und AU 220
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.1	Zusammenhang zwischen V-Modell und AU 220

V-Modell und AU 220 sind die zentralen Regelungen für die Realisierung von Vorhaben.

Für jedes Vorhaben muß die zeitliche Zuordnung von Aktivitäten und Produkten des V-Modells zu den Phasen des AU 220 projektspezifisch unter Beachtung der jeweils geltenden Aufgabenstellung vorgenommen werden. Eine allgemeine Zuordnung für einen Regelfall ist in Tabelle 2.1 dargestellt.

Die begleitenden Aktivitäten der Submodelle Qualitätssicherung, Konfigurationsmanagement und Projektmanagement sind aus Gründen der Übersichtlichkeit in Tabelle 2.1 nicht aufgeführt.

Die Zuordnung geht davon aus, daß im Phasenvorlauf die Architekturüberlegungen abgeschlossen sind und auf dieser Basis der Realisierbarkeitsnachweis und die Abschätzung der Lebenswegkosten durchgeführt werden.

Eine detaillierte Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220 ist Anhang A zu entnehmen.

Eine inkrementelle Vorgehensweise erfordert eine spezielle Erläuterung bezüglich der zu erstellenden Stufenentscheidungen/Phasendokumente.

Auf der Seite des V-Modells zeichnet sich eine inkrementelle Vorgehensweise durch die Fortschreibung von Dokumenten aus. In der Taktisch-Technischen Forderung/Organisatorisch-Technischen Forderung − also im Phasenvorlauf − ist mindestens der Gesamthorizont des Systems zu beschreiben. Die weiteren Ausbaustufen müssen deutlich werden. Die Fortschreibung der Anwenderforderungen im Rahmen des dargestellten Gesamthorizonts für weitere Ausbaustufen erfolgt in der Definitions- bzw. Entwicklungsphase. Werden Anforderungen definiert, die nicht durch den Gesamthorizont abgedeckt sind, so ist hierfür ein neues Vorhaben einzurichten. Das Vorhaben, welches den Gesamthorizont beschreibt, wird zum Leitvorhaben. Das neue Vorhaben ist dem Leitvorhaben untergeordnet. Einzelheiten sind dem AU 220 zu entnehmen.

Sofern eine Ausbaustufe durch Fertigprodukte realisiert wird, werden diese gemäß EEDV mittels Genehmigung der Teilinbetriebnahme (GTIB) in die Nutzung überführt. Eine Militärisch-Technisch-Wirtschaftliche Forderung / ein Realisierungsplan ist zu erstellen, sofern Ausbaustufen Entwicklungsarbeiten erfordern.

Die Entwicklungsphase endet nach Fertigstellung der letzten Ausbaustufe mit der Einführungsgenehmigung (EFG) für Serienmaterial bzw. Indienststellung/Inbetriebnahme für Nichtserienmaterial / Genehmigung der Inbetriebnahme (GIB). Der Abschlußbericht wird nach Beschaffung/Einführung der letzten Ausbaustufe erstellt.

Eine beispielhafte Zuordnung der SE-Aktivitäten zu den Phasen des EEDV bei einer inkrementellen Vorgehensweise ist in Abbildung 2.1 dargestellt. Der bei der Beschreibung des Gesamthorizonts in der OTF noch nicht berücksichtigte Bereich 4 ist durch ein neu einzurichtendes Vorhaben zu realisieren.

Phasen	SE- Aktivitäten	Stufenentscheidungen/ Phasendokumente Wehrmaterial	Stufenentscheidungen/ Phasendokumente DV-Vorhaben
Phasenvorlauf	−	− Militärische Bedarfs forderung (MBF)	− Bedarfsforderung/-fest- stellung
	SE 1, SE 2	− Taktisches Konzept (TaK) − Taktisch-Technische Forde- rung (TTF)	− Informationsversorgungs- konzept (IVK) − Organisatorisch-Technische  Forderung (OTF)
Definitions- phase	SE 3	− Endgültige Spezifikationen − Auswahl des gesamtverant- wortlichen Auftragnehmers  für die Entwicklungsphase − Militärisch-Technisch-Wirt- schaftliche Forderung  (MTWF)	− Auswahl des gesamtverant- wortlichen Auftragnehmers  für die Entwicklungsphase − Realisierungsplan
Entwicklungs- phase	SE 4-SW, SE 5-SW, SE 6-SW, SE 7-SW, SE 8	− Vorziehen von Maßnahmen  der Beschaffungsphase − Freigabe zum Bau − Erklärung der Funktionsbe- reitschaft und Betriebs- sicherheit − Erklärung der Versorgungs- reife − Erklärung der Technischen  Einführungsreife − Festlegung des Konstrukti- onsstandes − Erklärung der Truppenver- wendbarkeit − Einführungsgenehmigung  (EFG) für Serienmaterial − Indienststellung/Inbetrieb- nahme für Nichtserien- material	− Erklärung der Funktionsbe- reitschaft und Betriebs- sicherheit − Erklärung der Verwendbar- keit − Genehmigung der Teilinbe- triebnahme (GTIB) − Auswahl des gesamtverant- wortlichen Auftragnehmers  für die Einführungsphase − Genehmigung der Inbetrieb- nahme (GIB)
Beschaffungs-/ Einführungs- phase	SE 9  2)	− Auswahl des gesamtverant- wortlichen Auftragnehmers  für die Beschaffungsphase − Abschlußbericht (ASB)	− Abschlußbericht (ASB)
Nutzung	2
2)	SWPÄ-Maßnahmen werden gemäß den Regelungen des VModells durchgeführt.

Tabelle 2.1:	Regelzuordnung von Aktivitäten des V-Modells zu den Phasen des AU 220

Abbildung 2.1: SE-Aktivitäten und die Phasen des EEDV bei einer inkrementeller Entwicklung


Im Phasenvorlauf zu berücksichtigende Schnittstellen
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

Die Beschreibung der Schnittstellen zwischen AU 220 und V-Modell erfolgt im folgenden thematisch.


Initiierung eines Vorhabens
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.1	Initiierung eines Vorhabens

Die Initiierung eines Vorhabens erfolgt durch die Studiengruppe. Basierend auf dem Projekthandbuch sind Projektplan, QS-Plan und KM-Plan zu erstellen.

Bei Wehrmaterial beginnt die Anwendung des V-Modells, sobald ein DV/IT-Anteil identifiziert worden ist (siehe Abschnitt 1).


Definition der Anforderungen und der technischen Struktur des Systems
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.2	Definition der Anforderungen und der technischen Struktur des Systems

Verantwortlich für die Festlegung der groben Anforderungslage ist der Bedarfsträger (Anwender). Im Rahmen des Phasenvorlaufs ist in dem Dokument "Anwenderforderungen" der Gesamthorizont für die Funktionalität des Systems zu spezifizieren. Dies geschieht in der Form einer groben Systembeschreibung, die den Rahmen für alle weiteren Verfeinerungen und Ergänzungen der Anwenderforderungen bildet.

In der Praxis zeigt sich, daß bestimmte Standardthemenbereiche in unterschiedlichen Vorhaben vorkommen. Zur Vermeidung von Mehrfachaufwand werden im Geschäftsbereich des BMVg solche Themenbereiche von vorhabenübergreifendem Interesse identifiziert. Für diese Themenbereiche werden standardisierte Anforderungen definiert. Bei der Definition der Anwenderforderungen sind die vorhandenen standardisierten Anforderungen ebenso zu berücksichtigen wie existierende Planungsvorgaben. Hierzu sind die betreffenden querschnittlichen Fachreferate des BWB einzuschalten.

Auf der Basis der Anwenderforderungen ist ein Vorschlag für eine mögliche technische Struktur des Systems (Architekturvorschlag) zu erarbeiten.

Aufgabe der querschnittlichen Fachreferate im Rahmen der Architekturüberlegungen ist es, auf verwendbare Fertigproduktlösungen hinzuweisen (siehe Abschnitt 3). Grundlage hierfür sind die bereits existierenden IT-Ausstattungsvorgaben. Der Architekturvorschlag wird gemeinsam von BD und den betreffenden querschnittlichen Fachreferaten erarbeitet. Bei Bedarf schalten die querschnittlichen Fachreferate die für die IT-Ausstattungsvorgaben zuständigen Stellen ein.

Notwendige Anpassungen einsetzbarer Fertigprodukte sind in dem Architekturvorschlag aufzuzeigen.

Der Vorhabenmanager hat die Einhaltung der IT-Ausstattungsvorgaben schriftlich zu erklären. Abweichungen von den IT-Ausstattungsvorgaben sind mit dem zuständigen querschnittlichen Fachreferat abzustimmen. Die Begründung für die Abweichung muß von dem Fachreferat mitgetragen werden. Im Konfliktfall ist die Entscheidung gemäß AU 220 (in der Linie) herbeizuführen.


Forderungscontrolling
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.3	Forderungscontrolling

Forderungscontrolling beginnt bereits in den einzelnen Organisationsbereichen und setzt sich nachher in einem Wechselspiel zwischen BT und BD unter Beteiligung der querschnittlichen Fachreferate fort. Stimmen die Ersteller der Anwenderforderungen den Vorschlägen nicht zu, ist es Aufgabe der Studiengruppe/des Vorhabenmanagers, eine Entscheidung durch die entsprechenden verantwortlichen Instanzen herbeizuführen. Es ist sicherzustellen, daß die Modifikation/Reduzierung der Anforderungen die Erreichbarkeit der wesentlichen Projektziele nicht gefährdet.

Mögliche Ergebnisse des Forderungscontrolling sind in Abbildung 2.2 dargestellt.

Die Studiengruppe hat sicherzustellen, daß Forderungscontrolling vor Erstellung der TTF/OTF stattgefunden hat. Sofern im Rahmen einer inkrementellen Vorgehensweise die Anwenderforderungen für weitere Bereiche nach Abschluß des Phasenvorlaufs fortgeschrieben werden, ist Forderungscontrolling gegebenenfalls in den nachfolgenden Phasen zu wiederholen.

Abbildung 2.2: Forderungscontrolling


Prozeßplanung
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.4	Prozeßplanung

Im Rahmen der Prozeßplanung erfolgt eine projektspezifische Anpassung des V-Modells. Das Ergebnis wird im Projekthandbuch niedergelegt. Die Akquisitionsstrategie wird anhand definierter Auswahlkriterien festgelegt. Regelfall ist eine inkrementelle Akquisitionsstrategie.

Die einzelnen Ausbaustufen des Systems (Inkremente) sind zu planen und festzuschreiben.


Qualitätssicherung/Konfigurationsmanagement
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.2	Im Phasenvorlauf zu berücksichtigende Schnittstellen

2.2.5	Qualitätssicherung/Konfigurationsmanagement

Qualitätssicherung und Konfigurationsmanagment erfolgen gemäß den Regelungen des V-Modells. Der AU 220 sieht hierfür keine Regelungen vor.


Initiierung des Vorhabens in der Definitionsphase
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.3	Vom Vorhabenmanager zu berücksichtigende Schnittstellen

2.3.1	Initiierung des Vorhabens in der Definitionsphase

Mit Beginn der Definitionsphase ist der Vorhabenmanager für die Durchführung des Vorhabens verantwortlich. Seine erste Aufgabe ist die Fortschreibung von Projekthandbuch, Projektplan, QS-Plan und KM-Plan für die Definitionsphase.


Behandlung der Anforderungen
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.3	Vom Vorhabenmanager zu berücksichtigende Schnittstellen

2.3.2	Behandlung der Anforderungen

Die Realisierung von Systemen erfolgt im Regelfall inkrementell. Der Vorteil bei dieser inkrementellen Vorgehensweise liegt darin, daß durch die frühzeitige Nutzung einzelner Systemteile Erfahrungen durch den Nutzer gewonnen werden können, die dann wieder dazu dienen, die existierenden Anforderungen zu präzisieren bzw. zu vervollständigen und auch im Sinne eines Forderungscontrolling zu evaluieren. Dadurch wird gleichzeitig auch eine bessere Akzeptanz beim Nutzer erreicht, da er seine Erfahrungen in die Weiterentwicklung des Systems einbringen kann.

Eine inkrementelle Entwicklung macht es demzufolge erforderlich, auch in der Definitions- bzw. Entwicklungsphase die Anforderungen fortzuschreiben. Verantwortlich für die Anwenderforderungen bleibt auch in der Definitions- bzw. Entwicklungsphase der Anwender.


Qualitätssicherung/Konfigurationsmanagement
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.3	Vom Vorhabenmanager zu berücksichtigende Schnittstellen

2.3.3	Qualitätssicherung/Konfigurationsmanagement

Qualitätssicherung und Konfigurationsmanagment erfolgen gemäß den Regelungen des V-Modells.

In der Entwicklungsphase ist gemäß AU 220 zur "Erklärung der Funktionsbereitschaft und Betriebssicherheit" vom Bedarfsdecker zu prüfen, inwieweit das entwickelte System hinsichtlich seiner Leistungsfähigkeit die festgelegten Anforderungen erfüllt.

Zur "Erklärung der Verwendbarkeit" (EEDV) bzw. "Erklärung der Truppenverwendbarkeit" (EBMat) ist seitens des Bedarfsträgers die Verwendbarkeit des Systems unter Betriebsbedingungen festzustellen.

Sowohl die Prüfungen des Bedarfsdeckers als auch des Bedarfsträgers sind gemäß den Regelungen des Submodells QS durchzuführen.


Nutzung
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.3	Vom Vorhabenmanager zu berücksichtigende Schnittstellen

2.3.4	Nutzung

Der AU 220 definiert die Aufbauorganisation in der Nutzung und die Zuständigkeiten der Managementträger. Das Nutzungsmanagement entscheidet über die Durchführung von SWPÄ-Maßnahmen.

Die Durchführung der Änderungen erfolgt gemäß den Regelungen des V-Modells. Das operative Modul "Pflege/Änderung" in Abschnitt 6 dient der Vereinfachung der Planung und Durchführung von Pflege/Änderungsmaßnahmen.


Berücksichtigung technischer Produkte des V-Modells bei der Erstellung der Stufenentscheidungen/Phasendokumente
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.4	Phasenunabhängige Schnittstellen

2.4.1	Berücksichtigung technischer Produkte des V-Modells bei der Erstellung der Stufenentscheidungen/Phasendokumente

Stufenentscheidungen sowie Phasendokumente sind auf der Basis der technischen Produkte des V-Modells zu erstellen.

Im Rahmen der Aktivität PM 6 "Durchführungsentscheidung" wird die Erstellung einer Stufenentscheidung bzw. eines Phasendokuments initiiert und es wird festgelegt, welche Dokumente gemäß V-Modell für die Stufenentscheidungen/Phasendokumente zur Verfügung gestellt werden. Die Tabellen in Anhang A geben hierfür eine Anleitung.

Die Billigung der Stufenentscheidungen bzw. Phasendokumente ist im AU 220 geregelt.


Entscheidungsdokumentation
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.4	Phasenunabhängige Schnittstellen

2.4.2	Entscheidungsdokumentation

Getroffene Entscheidungen sind vom Vorhabensverantwortlichen (Studiengruppe, Vorhabenmanager) zu dokumentieren. Die Entscheidungsdokumentation wird im Rahmen der Aktivität PM 6 "Durchführungsentscheidung" geführt.


Vorhabenplanung und -steuerung
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

2	V-Modell und AU 220

2.4	Phasenunabhängige Schnittstellen

2.4.3	Vorhabenplanung und -steuerung

Der AU 220 fordert im Rahmen des Vorhabenmanagements folgende Planungs- und Steuerungsunterlagen:

−	Vorhabenstrukturplan,

−	Durchführungsplan,

−	Arbeitszeit- und Finanzplan,

−	Berichterstattung nach dem Daten- und Kostenmeldeverfahren,

−	Kontrollübersicht.

Der Bezug obiger Planungs- und Steuerungsunterlagen zum V-Modell wird im folgenden erläutert:

a)	Vorhabenstrukturplan

Der Vorhabenstrukturplan entspricht Kapitel 2.1 des Projektplans.

b)	Durchführungsplan

Der Durchführungsplan stellt die Reihenfolge, zeitliche Lage und Dauer der Tätigkeiten, die zur Realisierung eines Vorhabens unter Berücksichtigung der notwendigen und/oder verfügbaren Einsatzmittel erforderlich sind, dar. Als Grundlage dient der Strukturplan. Der Durchführungsplan ist Teil von Kapitel 3 des Projektplans.

c)	Arbeitszeit- und Finanzplan

Der Arbeitszeit- und Finanzplan (AZF-Plan) ist ein spezifisches Dokument im Geschäftsbereich des BMVg. Er ist im Rahmen der Aktivität PM 4 "Feinplanung" zu erstellen.

d)	Berichterstattung nach dem Daten- und Kostenmeldeverfahren

Entsprechend den Rahmenvereinbarungen zwischen der Industrie (BDI) und dem BMVg ist bei Vorhaben das Daten- und Kostenmeldeverfahren DAKOMEV anzuwenden. Die Anwendung von DAKOMEV entfällt, sofern mit der Industrie ein Festpreis vereinbart wurde.

Bezugsgrundlage für das Meldeverfahren sind Arbeitspakete auf der Ebene von Baugruppen bzw. von Bausteinen, die sich nach dem V-Modell aus dem Projektplan Kapitel 2.2 "Produktstrukturplan" ergeben.

Die notwendigen Ausgangsdaten sind aus dem Projektplan abzuleiten bzw. dort auszuweisen. Mit dem Auftragnehmer ist festzulegen,

−	für welche Arbeitspakete die nach DAKOMEV zu ermittelnden Daten zu melden sind und

−	mit welcher Häufigkeit die Ermittlung und Meldung erfolgt.

Die getroffenen Vereinbarungen sind im Projekthandbuch festzulegen.

Weitere Ausführungshinweise ergeben sich aus der Rahmenvereinbarung zu DAKOMEV und den zugehörigen Weisungen/Verfügungen.

e)	Kontrollübersicht

Die Kontrollübersicht ist ein spezifisches Dokument im Geschäftsbereich des BMVg. Sie ist im Rahmen der Aktivität PM 8 "Projektkontrolle und -steuerung" zu erstellen.

Obige Planungs- und Steuerungsunterlagen werden durch das Vorhaben "Integration der Vorhaben-Führungsmittel" (IVF) DV-technisch umgesetzt.


Erstellung von Prototypen
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

3	Erstellung von Prototypen

Prototypen verfolgen u. a. folgende Ziele:

−	Abbildung und Spezifikation von Anwenderforderungen,

−	Validierung der Anwenderforderungen,

−	frühzeitiges Erkennen von Risiken,

−	Klärung der Nutzungsmöglichkeiten von Fertigprodukten,

−	Präzisierung des zu erwartenden Realisierungsaufwands.

Entsprechend obiger Zielsetzung erfolgt die Erstellung von Prototypen insbesondere im Rahmen von im Phasenvorlauf durchgeführten Studien.

Die folgenden Arten von Prototyping lassen sich unterscheiden:

−	Beim explorativen Prototyping werden im direkten Meinungsaustausch mit dem Anwender die Anwenderforderungen verfeinert, ergänzt und geklärt.

−	Beim experimentellen Prototyping werden technische Eigenschaften eines Systems oder Systemteils ermittelt.

−	Beim evolutionären Prototyping wird auf der Basis einer ersten Version der Anwenderforderungen, die den funktionalen Systemkern beschreibt und den Gesamthorizont des Systems vorgibt, eine operative, erste Systemversion realisiert. Zukünftige Ergänzungen und Änderungen der Anwenderforderungen sind zu diesem Zeitpunkt nicht vollständig absehbar. Diese erste Systemversion wird in weiteren Ausbaustufen bis zum endgültigen System ausgebaut, wobei die Anwenderforderungen in allen Teilen ergänzt und geändert werden können.

Evolutionäres Prototyping (synonym für evolutionäre Akquisition) erfolgt grundsätzlich gemäß den Regelungen des V-Modells. Explorative und experimentelle Prototypen sind ihrer Natur nach "Wegwerf-Prototypen". Sie dienen lediglich dazu, bestimmte Erkenntnisse zu sammeln, die dann bei der Entwicklung des produktiv einzusetzenden Produkts verwertet werden. Dennoch zeigt die Praxis, daß existierende Prototypen, die allem Anschein nach die Erwartungen erfüllen, die an das Endprodukt gestellt werden, häufig in den produktiven Betrieb überführt werden, obwohl sie eigentlich als "Wegwerf-Prototyp" konzipiert wurden. Eine konsistente Dokumentation ist in solchen Fällen i. d. R. nicht vorhanden. Folge ist, daß diese "ehemaligen" Prototypen nicht wartbar sind und im Betrieb oft qualitative Probleme aufweisen.

Um in dieser Situation Abhilfe zu schaffen, ist es erforderlich, bereits während der Entwicklung des Prototypen eine gewisse Mindestdokumentation zu erstellen. Dies läßt sich dadurch erreichen, in dem der Prototyp als IT-System gemäß V-Modell realisiert wird, wobei die Mindestdokumentation gemäß Tabelle 3.1 zu berücksichtigen ist. Hierdurch wird auch für Prototypen eine gewisse Mindestqualität sichergestellt.

Mindestbedarf an Dokumentation für die Erstellung von Prototypen	Aktivität
Submodell SE
Anwenderforderungen Fachliche Anforderungen Randbedingungen Die Leistungsfähigkeit des Prototypen muß vor seiner Erstellung klar definiert werden. Die Eigenschaften, die der Prototyp in Übereinstimmung mit dem Endprodukt haben muß, sind ebenso zu beschreiben wie die Eigenschaften, auf die verzichtet wird. Beim explorativen Prototyping reicht zu Beginn der Entwicklung eine grobe Vorstellung von der Funktionalität des Prototypen aus. Es ist jedoch sicherzustellen, daß nach Fertigstellung des Prototyps die Anwenderforderungen dem realisierten Prototyp entsprechen.	SE 1.2, SE 1.4, SE 1.5
Systemarchitektur Technischer Aufbau des Systems Identifikation der Schnittstellen Im Rahmen der Systemarchitektur ist zu definieren, welchen Bestandteil des Systems der Prototyp ausmachen soll.	SE 2.1
Technische Anforderungen Technische Anforderungen an die Schnittstellen Qualitätsforderungen	SE 3.2, SE 3.4
SW-Architektur Modularisierung / Datenbankentwurf Mindestens als Übersicht, Einzelbeschreibungen und dynamisches Ablaufmodell optional.	SE 4.1-SW
Implementierungsdokumente Quellcode, Bindeprozeduren, Installationsprozeduren.	SE 6-SW, SE 7.3-SW, SE 8.1
Submodell QS
QS-Plan	QS 1.1
Prüfspezifikation	QS 2.1, QS 2.3
Prüfprotokoll	QS 4.2
Submodell KM
KM-Plan	KM 1.1
Konfigurations-Identifikationsdokument	KM 2
Submodell PM
Projekthandbuch Die Verwendung des Prototypen hinsichtlich weiterer Entwicklungs- aktivitäten als auch hinsichtlich einer späteren Einbindung in das produktiv  einzusetzende Endprodukt ist vor der Erstellung des Prototypen klar zu  definieren.	PM 1.3, PM 1.4
Projektplan	PM 1.5, PM 4
Berichtsdokumente	PM 8
Tabelle 3.1:	Mindestbedarf an Dokumentation für die Erstellung von Prototypen


Entscheidungsprozeß
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

4	Überleitungsstrategie

4.1	Entscheidungsprozeß

Die Überleitung von V-Modell August 1992 nach V-Modell Juni 1997 ist systemspezifisch zu entscheiden.

Es folgen beispielhaft einige Möglichkeiten der Überleitung:

−	Nach Abschluß der Aktivitäten SWE 1, SWE 2 und SWE 3 erfolgt die weitere Entwicklung gemäß V-Modell Juni 1997 (SE 4-SW − SE 9)

−	Sind die Aktivitäten SWE 1 und SWE 2 abgeschlossen, so erfolgt die weitere Bearbeitung gemäß Aktivität SWE 3. Nach Abschluß von Aktivität SWE 3 erfolgt die weitere Entwicklung gemäß V-Modell Juni 1997 (SE 4-SW − SE 9).

−	Ist Aktivität SWE 1 abgeschlossen (Systemanforderungen und Systemarchitektur), erfolgt die weitere Entwicklung gemäß V-Modell Juni 1997 (Aktivitäten SE 3 − SE 9). Eine Nachdokumentation der Anwenderforderungen ist nicht erforderlich, aber es ist zu prüfen, inwieweit die erstellten Systemanforderungen die vom Produktmuster Anwenderforderungen geforderten Inhalte abdecken. Gegebenenfalls ist eine Vervollständigung der Systemanforderungen erforderlich. Tabelle 4.1 stellt den einzelnen Kapiteln der Anwenderforderungen die entsprechenden Kapitel der Systemanforderungen gegenüber.

Nach V-Modell 1992 geschlossene Verträge sind unverändert fortzuführen.

Anwenderforderungen	Systemanforderungen
AFo_2 Ist-Aufnahme und Ist-Analyse	2.1 Ist-Aufnahme/-Analyse
AFo_3 IT-Sicherheitsziel	3.5 DV-Sicherheit
AFo_4 Bedrohungs- und Risikoanalyse	2.2 Bedrohungs- und Risikoanalyse
AFo_5 IT-Sicherheit	3.5 DV-Sicherheit
AFo_6.1 Grobe Systembeschreibung	3.1 Gesamtfunktion des Systems
AFo_6.2 Organisatorische Einbettung	5.1.2 Organisatorische Einbettung
AFo_6.3 Nutzung	3.2 Anforderungen hinsichtlich der  Bedienung/Nutzung des Systems 5.1.3 Nutzung
AFo_6.4 Kritikalität des Systems	3.4 Kritikalität des Systems
AFo_6.5 Externe Schnittstellen	5.1.1 Technische Einsatzumgebung 5.2 Sonstige systemexterne Schnittstellen
AFo_6.6 Beschreibung der Funktionalität	6 Funktionsorientierte fachliche  Anforderungen an das System 7 Datenorientierte fachliche Anforderungen 8 Anforderungen an Funktionsabläufe/ Verfahren
AFo_6.7 Qualitätsforderungen	3.6 Anforderungen an sonstige  Qualitätsmerkmale des Systems
AFo_7 Randbedingungen	3)
3)	Gegebenenfalls können Beiträge aus Kapitel 3.3 "Anforderungen hinsichtlich der Realisierung interner Schnittstellen" übernommen werden.

Tabelle 4.1:	Gegenüberstellung Anwenderforderungen vs. Systemanforderungen


Durchführung der Überleitung von V-Modell August 1992 nach V-Modell Juni 1997
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

4	Überleitungsstrategie

4.2	Durchführung der Überleitung von V-Modell August 1992 nach V-Modell Juni 1997

Folgende Aspekte sind sowohl bei der bereichsspezifischen als auch der vorhabenspezifischen Überleitung zu berücksichtigen:

−	Anpassung der Rollenfestlegung

Bestehende Rollenfestlegungen gemäß V-Modell 1992 sind an die im V-Modell 1997 definierten Rollen anzupassen.

−	Anpassung der Methodenfestlegung

Bestehende Methodenfestlegungen sind an die im V-Modell 1997 definierten Aktivitäten und Produkte anzupassen.

−	Zuordnung der eingesetzten Werkzeuge zu den im V-Modell 1997 definierten Aktivitäten und Produkten

Es ist festzulegen, welche Aktivitäten und Produkte des V-Modells 1997 durch die eingesetzten Werkzeuge unterstützt werden.

−	Ausbildung

Alle Vorhabensbeteiligten sind je nach der von ihnen wahrgenommenen Rolle auszubilden.


Überleitung eines Produkts
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

4	Überleitungsstrategie

4.3	Überleitung eines Produkts

In konkreten Vorhaben stellt sich immer wieder die Frage, wie individuell erstellte Produkte (z. B. Prototypen) zu behandeln sind, die in eine Nutzung durch Dritte zu übernehmen sind. Bei einer Übernahme muß sichergestellt sein, daß eine gewisse Mindestdokumentation vorhanden ist und daß die Qualität des Produkts den Anforderungen entspricht.

Im folgenden wird davon ausgegangen, daß ein Produkt vorliegt, dessen Entwicklung nicht nach V-Modell erfolgt ist. Das Produkt ist nutzbar und durch Prüfungen wurde nachgewiesen, daß es für einen eingeschränkten produktiven Einsatz ausreichend stabil ist. Für diesen Fall wird der Weg von einem unzureichend dokumentierten Produkt zu einem wartungsfähigen System beschrieben ("Regeneration").

Dabei sind im wesentlichen folgende Fragestellungen zu beantworten:

−	Welche Mindestmaßnahmen sind erforderlich, um die mittelfristige Nutzbarkeit und die Wartbarkeit des Systems zu erreichen?

−	Welcher Entwicklungsstand muß erreicht werden, um z. B. eine Kampfwertsteigerung aufsetzen zu können?

Die folgenden Schritte sind bei einer Regeneration durchzuführen:

1.	Im Rahmen einer Ist-Aufnahme werden alle verfügbaren Informationen über das vorliegende Produkt gesammelt. Dabei werden sowohl die SW-/HW-Anteile als auch die Dokumentation betrachtet.

Beispiele:	Verzeichnisstrukturen, Quellcode, Compiler, Aufnahme von Dateistrukturen, Handbücher, Anforderungsdokumente (z. B. auch aus Protokollen), Prüfunterlagen, Nutzer-Feedback, Kurzbeschreibungen, Fehlermeldungen, Versionsübersichten, Aufstellung der Module/Datenbanken, Schnittstellenbeschreibungen.

2.	Unter Verwendung der Produktmuster des V-Modells als Checkliste werden die gesammelten Informationen strukturiert.

Im Regelfall sollte die Strukturierung über Verweise auf vorhandene Informationsquellen und nicht durch Nachdokumention erfolgen.

Eine unmotivierte Nachdokumentation sollte in jedem Fall vermieden werden. Die in Teil 3 "Handbuchsammlung" im Handbuch "Tailoring und projektspezifisches V-Modell" genannten Mindestanforderungen sind jedoch einzuhalten.

Eine sinnvolle Überleitung in die Nutzung, SWPÄ, Regeneration oder Weiterentwicklung ist ohne Vorhandensein dieser Mindestdokumentation nicht möglich.

3.	Der Nachweis der Tauglichkeit für die Nutzung wird durch entsprechende Funktionstests erbracht. Grundlage für die Kanalisierung des Prüfaufwands sind die durchgeführten Kritikalitätsbetrachtungen. Besondere Beachtung ist der Erfüllung der Sicherheitsanforderungen zu schenken.

Der Ablauf kann durch den Verweis auf entsprechende, bereits dokumentierte Prüfungen abgekürzt werden.


BMVg-spezifische Ausprägung des SWPÄ-Konzepts
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

5	V-Modell in der Nutzung

5.1	BMVg-spezifische Ausprägung des SWPÄ-Konzepts

Gemäß VM-Blatterlaß von 1989 (/VMBl 1989/) und der Arbeitsweisung zur Softwarepflege/-änderung im Bereich des BWB (/AW SWPÄ-BWB/) ist im Geschäftsbereich des BMVg ein SWPÄ-Konzept zu erstellen.

Das Produkt "SWPÄ-Konzept" ist im Teil 1 "Regelungsteil" definiert. Es wird für den Geschäftsbereich des BMVg erweitert (siehe Anhang B.1).


Planung und Durchführung von SWPÄ-Maßnahmen
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

5	V-Modell in der Nutzung

5.2	Planung und Durchführung von SWPÄ-Maßnahmen

Grundlage der Planung der SWPÄ-Maßnahmen sind Projekthandbuch, Projektplan, KM-Plan oder andere vorhandene Planungsunterlagen des Entwicklungsprojekts. Die Planung der SWPÄ-Maßnahmen erfolgt gemäß den Regelungen des V-Modells. Das Ergebnis wird im Projekthandbuch, Projektplan, KM-Plan und QS-Plan niedergeschrieben.

Die Durchführung von Änderungen erfolgt gemäß den Regelungen des V-Modells. Dies gilt auch dann, wenn die Entwicklung des Vorhabens nicht nach V-Modell erfolgt ist. In diesem Falle sind die Submodelle QS, KM und PM uneingeschränkt anzuwenden. Bezüglich der Systemerstellung ist die existierende Projektdokumentation als Grundlage zu verwenden. Aus Wirtschaftlichkeitsgründen ist im allgemeinen auf eine Umstellung auf die Dokumentation gemäß V-Modell zu verzichten. Die Entscheidung ist systemspezifisch zu treffen. Neuentwicklungen von Teilen des Vorhabens sind jedoch gemäß den Regelungen des V-Modells durchzuführen. Der entsprechende Aufsetzpunkt (z. B. Segment, SW-Einheit, HW-Einheit) ist festzulegen.

Das operative Modul "Pflege/Änderung" (siehe Abschnitt 5.3) dient der Vereinfachung der Planung und Durchführung von SWPÄ-Maßnahmen. Seine Anwendung ist optional.


Operatives Modul ”Pflege/Änderung”
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

5	V-Modell in der Nutzung

5.3	Operatives Modul "Pflege/Änderung"

Das operative Modul "Pflege/Änderung" (PÄ) (siehe Anhang B.2) behandelt die Aktivitäten zur Änderung von SE-Produkten aufgrund von Änderungsanträgen/Problemmeldungen an bereits in Nutzung befindlichen Systemen.

Eingehende Änderungen können einerseits zu einem eigenständigen Pflege/Änderungsprojekt führen (d. h. ein Projekt ist zu initialisieren, siehe Submodell PM) oder andererseits im Rahmen des Änderungsmanagements (Aktivität KM 3) eines bereits laufenden PÄ-Projekts abgearbeitet werden.

Die durch einen Änderungsantrag bzw. eine Problemmeldung betroffenen Produkte sind im Rahmen von Aktivität KM 3 zu identifizieren ("Änderungsumfeld"). Die Auswirkungen des Änderungsantrags/der Problemmeldung auf das bestehende System aus der fachlichen und technischen Sicht sind zu identifizieren und zu bewerten. Lösungsvorschläge sind als Entscheidungsgrundlage auszuarbeiten. Dabei sind die zu modifizierenden Produkte zu ermitteln.

Das operative Modul "Pflege/Änderung" definiert die Aktivitäten zur Modifikation der betroffenen SE-Produkte. Die Aktivitäten lassen sich wie folgt klassifizieren:

−	Die SE-Produkte sind zu überarbeiten. Die Aktivitäten orientieren sich einerseits an der Erzeugnisstruktur des bestehenden Systems und andererseits an den Prüf- und Integrationsaktivitäten (Aktivitäten PÄ 1 bis PÄ 8).

−	Das modifizierte System ist in die Nutzung zu überführen (Aktivität PÄ 9).

Die Übernahme der SE-Produkte aus dem Entwicklungsprojekt in das PÄ-Projekt ist Aufgabe des KM (Aktivität KM 2 "Produkt- und Konfigurationsverwaltung"). Die Bereitstellung der SEU für das PÄ-Projekt liegt in der Verantwortung von PM (Aktivität PM 1.4 "Toolset-Management durchführen").

Bei der Überarbeitung der Produkte sind generell zwei Vorgehensweisen möglich:

a)	Modifikation im Produkt vornehmen

Ergebnis: neues Produkt

b)	Modifikation in einem zusätzlichen Produkt mit Bezug zum ursprünglichen Produkt vornehmen

Ergebnis: Produkt plus Zusatzinformation

In beiden Fällen entsteht eine neue Version. Welche Vorgehensweise für das PÄ-Projekt gewählt wird, ist im KM-Plan des Projekts festzulegen. Die folgende Abbildung skizziert die Fortschreibung der Produkte in Versionen.

Abbildung 5.1: Vorgehensweisen bei der Produktfortschreibung

Entstehen bei der Modifikation eines Produkts Änderungsforderungen an andere Produkte, so werden diese im operativen Modul "Pflege/Änderung" über Berichtsdokumente den entsprechenden Aktivitäten zugeleitet.


Ziel des Einsatzes des AU 253
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.1	AU 253: Zuordnungshandbuch GAM-T17 (V2) - V-Modell

6.1.1	Ziel des Einsatzes des AU 253

Wenn IT-Systeme im Rahmen deutsch-französischer militärischer Kooperationsvorhaben zu entwickeln sind, findet auf deutscher Seite das V-Modell und auf französischer Seite die GAM-T17 (V2) Anwendung. Während das V-Modell die Entwicklung des gesamten IT-Systems regelt, ist die GAM-T17 (V2) ausschließlich auf Software beschränkt. Das Zuordnungshandbuch (AU 253) 4) behandelt den von GAM-T17 (V2) und V-Modell gemeinsam abgedeckten Regelungsbereich und dient dazu, die auf den beiden Standards beruhenden Entwicklungsprozesse der nationalen Teilentwicklungen so festzulegen, daß die Abläufe aufeinander abgestimmt sind und Struktur und Inhalt ihrer Ergebnisse auch den Erfordernissen der jeweils anderen Seite genügen. Dadurch können die Beurteilungen durch die nationalen Auftraggeber auf der Basis gleichwertiger Vorgaben durchgeführt werden.

4)	Die derzeitige Version des Zuordnungshandbuchs (Stand Februar 1997) berücksichtigt die Version August 1992 des VModells.

Der Entwicklungsprozeß muß auf der Grundlage des AU 253 in folgenden Fällen aufeinander abgestimmt werden:

1.	Bausteine beider Partner werden Bestandteil einer Konfiguration,

2.	das IT-System muß von beiden Partnern nach einheitlichen Qualitätsvorgaben erstellt werden,

3.	die Zuständigkeit für die Bausteine geht im Verlauf der Entwicklung oder bei Unterstützungsmaßnahmen von einem Partner auf den anderen über.


Einsatzumgebung des AU 253
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.1	AU 253: Zuordnungshandbuch GAM-T17 (V2) - V-Modell

6.1.2	Einsatzumgebung des AU 253

Der Phasenablauf eines Vorhabens und die dabei verfolgten Ziele sind auf französischer Seite durch /IG 1514/ und auf deutscher Seite durch den AU 220 geregelt. Tabelle 6.1 zeigt, wie die einzelnen Phasen der beiden Vorschriften und die Phasenabschlußdokumente einander zugeordnet werden können.

Auf deutscher Seite wird unterschieden zwischen der Realisierung von Wehrmaterial und DV-Vorhaben. Die Phasenziele sind in beiden Fällen vergleichbare Reifegrade des jeweiligen Vorhabens. Beide Fälle werden daher gemeinsam in einer Spalte dargestellt. Im Fall unterschiedlicher Bezeichnungen für Phasen bzw. Stufenentscheidungen/Phasendokumente wird die Bezeichung für DV-Vorhaben kursiv gedruckt.

Zur Durchführung der Aufgaben jeder Phase kann das amtliche Vorhabenmanagement die Unterstützung von Dienststellen und von der Industrie anfordern. Jede angeforderte Leistung muß in einer Leistungsbeschreibung (Cahier des charges) festgelegt werden, die die geforderten Produkte oder Dienste technisch beschreibt und die organisatorischen und prozeduralen Randbedingungen festlegt. Die Gültigkeitsdauer von Kooperationsvereinbarungen und Verträgen mit der Industrie wird durch die Phasen begrenzt.

Der Entwicklungsauftrag für das System wird zu Beginn der Entwicklungsphase des Vorhabenablaufes vergeben. Der wesentliche Anteil der vom Zuordnungshandbuch abgedeckten Aufgaben liegt in dieser Phase.

Deutsch	Französisch
Phasenvorlauf Taktisches Konzept Informationsversorgungskonzept	Phase préliminaire expression d'un besoin (Fiche de caractéristiques militaires exploratoire)
Taktisch-Technische Forderung Organisatorisch-Technische Forderung	Phase de faisabilité Dossier d'orientation
Definitionsphase Militärisch-Technisch-Wirtschaftliche Forderung Realisierungsplan	Phase de Définition Dossier de lancement du développment
Entwicklungsphase Einführungsgenehmigung Genehmigung der Inbetriebnahme	Phase de développement Dossier de lancement de production
Beschaffungsphase/Einführungsphase Abschlußbericht	Phase de production Mise en service
Nutzung	Utilisation
Tabelle 6.1:	Zuordnung der Phasen und der Stufenentscheidungen/Phasendokumente


Aufbau und Einsatz des AU 253
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.1	AU 253: Zuordnungshandbuch GAM-T17 (V2) - V-Modell

6.1.3	Aufbau und Einsatz des AU 253

Zur Unterstützung der binationalen Zusammenarbeit enthält das Zuordnungshandbuch GAM-T17 (V2) − V-Modell folgende Hilfsmittel:

−	In einem binationalen Glossar werden deutsche und französische Begriffe zu den Themen Softwareentwicklung und Projektmanagement erklärt und einander zugeordnet.

−	Die Darstellung des Kontextes der Softwareentwicklung zeigt die Vergleichbarkeit der Vorhabenrealisierungen auf deutscher und französischer Seite und im Falle binationaler Entwicklungen.

−	Die Basiskonzepte des Softwareentwicklungsprozesses und die Besonderheiten ihrer Realisierung in den beiden nationalen Standards werden dargestellt. Dadurch sind Unterschiede der beiden Standards einfach erkennbar.

−	Die Regelungen der beiden Standards werden einander detailliert zugeordnet. Wenn Zuordnungen nicht eindeutig zu treffen sind, werden Hinweise auf erforderliche Koordinierungsmaßnahmen für die Entwicklungsprozesse nach GAM-T17 (V2) und nach V-Modell gegeben.

−	Die Anwendungsprinzipien zeigen den Einsatz des Zuordnungshandbuches im Verlauf einer binationalen Vorhabenrealisierung.

Bei der Vorbereitung der binationalen Zusammenarbeit und der nationalen Entwicklungsanteile dient das Zuordnungshandbuch als Planungshilfe. Die für das Projekt gültigen Entwicklungsprozesse beider Seiten müssen von den jeweiligen Standards abgeleitet werden, so daß sie folgende Merkmale zeigen:

−	gleiches Verständnis bei der Gliederung der Prozesse in Aufgaben und deren Abhängigkeiten untereinander,

−	vereinbarte Zuordnungen für Dokumente,

−	vergleichbare Verantwortlichkeiten,

−	gleiches Verständnis des Informationsbedarfs.

Im weiteren Verlauf der Entwicklung dient das Zuordnungshandbuch als Querverweisliste zur Interpretation von Dokumenten des Partners und bei der Suche nach benötigter Information.


V-Modell und der Entwicklungsstandard des US-DoD: MIL-STD-498
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.2	V-Modell und der Entwicklungsstandard des US-DoD: MIL-STD-498

Die nachfolgenden Bezüge zwischen V-Modell und MIL-STD-498 und den zugehörigen Data Item Descriptions (DIDs) basieren auf einer Entsprechung in der jeweiligen Zielrichtung, in den Grundgedanken und der Konzeption, nicht jedoch auf einer exakten inhaltlichen Übereinstimmung. Bezüge zwischen den beiden Standards werden bezüglich der zugrundeliegenden Systemstruktur und der Aktivitäten dargestellt.


Systemstruktur
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.2	V-Modell und der Entwicklungsstandard des US-DoD: MIL-STD-498

6.2.1	Systemstruktur

MIL-STD-498	V-Modell
System  Subsystem  — Hardware Configuration Item (HWCI) — Computer Software Configuration Item (CSCI) — Software Unit Database	IT-System — Segment HW-Einheit HW-Komponente SW-Einheit SW-Komponente SW-Modul Datenbank


Aktivitäten
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

6	Internationale Vorhaben

6.2	V-Modell und der Entwicklungsstandard des US-DoD: MIL-STD-498

6.2.2	Aktivitäten

Requ.	MIL-STD-498	V-Modell	Aktivität
5.1	Project planning and oversight	Projektinitialisierung, QS-Initialisierung, KM-Planung	PM 1, QS 1, KM 1
5.1.1	Software development planning
5.1.2	CSCI test planning
5.1.3	System test planning
5.1.4	Software installation planning
5.1.5	Software transition planning
5.1.6	Following and updating plans
5.2	Establishing a software development environment
5.2.1	Software engineering environment	Toolset-Management durchführen	PM 1.4
5.2.2	Software test environment	Toolset-Management durchführen, Prüfumgebung definieren	PM 1.4, QS 2.2
5.2.3	Software development library	KM einrichten	KM 1.2
5.2.4	Software development files	KM einrichten	KM 1.2
5.2.5	Non-deliverable software	Toolset-Management durchführen	PM 1.4
5.3	System requirements analysis
5.3.1	Analysis of user input	System-Anforderungsanalyse	SE 1
5.3.2	Operational concept	System-Anforderungsanalyse	SE 1
5.3.3	System requirements	System-Anforderungsanalyse	SE 1
5.4	System design
5.4.1	System-wide design decisions	System technisch entwerfen	SE 2.1
5.4.2	System architectural design	System technisch entwerfen, Anwenderforderungen zuordnen	SE 2.1, SE 2.4
5.5	Software requirements analysis	SW-/HW-Anforderungsanalyse	SE 3
5.6	Software design
5.6.1	CSCI-wide design decisions	SW-Grobentwurf	SE 4-SW
5.6.2	CSCI architectural design	SW-Grobentwurf	SE 4-SW
5.6.3	CSCI detailed design	SW-Feinentwurf	SE 5-SW
5.7	Software implementation and unit testing
5.7.1	Software implementation	SW-Module codieren, Datenbank realisieren	SE 6.1-SW, SE 6.2-SW
5.7.2	Preparing for unit testing	Selbstprüfung des SW-Moduls/der Datenbank durchführen	SE 6.3-SW
5.7.3	Performing unit testing	Selbstprüfung des SW-Moduls/der Datenbank durchführen	SE 6.3-SW
5.7.4	Revision and retesting	Selbstprüfung des SW-Moduls/der Datenbank durchführen	SE 6.3-SW
5.7.5	Analysing and recording unit test results	Selbstprüfung des SW-Moduls/der Datenbank durchführen	SE 6.3-SW
5.8	Unit integration and testing
5.8.1	Preparing for unit integration and testing	SW-Integration	SE 7-SW
5.8.2	Performing unit integration and testing	SW-Integration	SE 7-SW
5.8.3	Revision and retesting	SW-Integration	SE 7-SW
5.8.4	Analysing and recording unit integration and test results	SW-Integration	SE 7-SW
5.9	CSCI qualification testing
5.9.1	Independence of CSCI qualification testing	Belegung der Rollen (Teil 3, Handbuch "Rollen")
5.9.2	Testing on the target computer system	Produktprüfung	QS 4
5.9.3	Preparing for CSCI qualification testing	Prüfungsvorbereitung	QS 2
5.9.4	Dry run of CSCI qualification testing	—
5.9.5	Performing CSCI qualification testing	Produktprüfung	QS 4
5.9.6	Revision and retesting	SW-Integration	SE 7-SW
5.9.7	Analysing and recording CSCI qualification test results	Produktprüfung	QS 4
5.10	CSCI/HWCI integration and testing
5.10.1	Preparing for CSCI/HWC integration and testing	System-Integration	SE 8
5.10.2	Performing CSCI/HWCI integration and testing	System-Integration	SE 8
5.10.3	Revision and retesting	System-Integration	SE 8
5.10.4	Analysing and recording CSCI/ HWCI integration and test results	System-Integration	SE 8
5.11	System qualification testing
5.11.1	Independence in system qualification testing	Belegung der Rollen (Teil 3, Handbuch "Rollen")
5.11.2	Testing on the target computer system	Produktprüfung	QS 4
5.11.3	Preparing for system qualification testing	Prüfungsvorbereitung	QS 2
5.11.4	Dry run of system qualification testing	—
5.11.5	Performing system qualification testing	Produktprüfung	QS 4
5.11.6	Revision and retesting	System-Integration	SE 8
5.11.7	Analysing and recording system qualification test results	Produktprüfung	QS 4
5.12	Preparing for software use
5.12.1	Preparing the executable software	Produkt bereitstellen	SE 8.3
5.12.2	Preparing version descriptions for user sites	Release-Management durchführen	KM 4.6
5.12.3	Preparing user manuals	Produkt bereitstellen	SE 8.3
5.12.4	Installation at user sites	Überleitung in die Nutzung	SE 9
5.13	Preparing for software transition
5.13.1	Preparing the executable software	Produkt bereitstellen	SE 8.3
5.13.2	Preparing source files	Produkt bereitstellen	SE 8.3
5.13.3	Preparing version descriptions for the support site	Release-Management durchführen	KM 4.6
5.13.4	Preparing the "as built" CSCI design and related information	Release-Management durchführen	KM 4.6
5.13.5	Updating the system design description	System technisch entwerfen	SE 2.1
5.13.6	Preparing support manuals	Produkt bereitstellen	SE 8.3
5.13.7	Transition to the designated support site	System installieren	SE 9.2
5.14	Software configuration management
5.14.1	Configuration identification	Produkt- und Konfigurationsverwaltung	KM 2
5.14.2	Configuration control	Änderungsmanagement (Konfigurationssteuerung)	KM 3
5.14.3	Configuration status accounting	KM-Dokumentation führen	KM 4.5
5.14.4	Configuration audits	Prozeßprüfung von Aktivitäten	QS 3
5.14.5	Packaging, storage, handling, and delivery	Ergebnisse sichern	KM 4.4
5.15	Software product evaluation
5.15.1	In-process and final software product evaluations	Produktprüfung	QS 4
5.15.2	Software product evaluation records	Produktprüfung	QS 4
5.15.3	Independence in software product evaluation	Belegung der Rollen (Teil 3, Handbuch "Rollen")
5.16	Software quality assurance
5.16.1	Software quality assurance evaluations	Prozeßprüfung von Aktivitäten, Produktprüfung, Durchführungsentscheidung	QS 3, QS 4, PM 6
5.16.2	Software quality assurance records	Prozeßprüfung von Aktivitäten, Produktprüfung, Durchführungsentscheidung	QS 3, QS 4 PM 6
5.16.3	Independence in software quality assurance	Belegung der Rollen (Teil 3, Handbuch "Rollen")
5.17	Corrective action
5.17.1	Problem/change reports	Änderungsmanagement (Konfigurationssteuerung)	KM 3
5.17.2	Corrective action system	Änderungsmanagement (Konfigurationssteuerung)	KM 3
5.18	Joint technical and management reviews
5.18.1	Joint technical reviews	Produktprüfung	QS 4
5.18.2	Joint management reviews	Prozeßprüfung von Aktivitäten	QS 3
5.19	Other activities
5.19.1	Risk management	Risikomanagement	PM 7
5.19.2	Software management indicators	—
5.19.3	Security and privacy	Bedrohung und Risiko analysieren, System technisch entwerfen	SE 1.6, SE 2.1
5.19.4	Subcontractor management	Auftragnehmer-Management	PM 3
5.19.5	Interface with software IV&V agents	—
5.19.6	Coordination with associate developers	—
5.19.7	Improvement of project processes	—


Zuordnung V-Modell zu STANAG 4159
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

7	Zuordnung V-Modell zu STANAG 4159

Der NATO-Standard STANAG 4159 beschreibt, wie Konfigurationsmanagement in multinationalen Kooperationsvorhaben durchzuführen ist. Die Anwendung nationaler KM-Regelungen kann vorhabenspezifisch vereinbart werden, sofern diese konsistent zur STANAG 4159 sind. Im folgenden wird die Konsistenz der Regelungen des V-Modells zur STANAG 4159 aufgezeigt.


Baselines
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

7	Zuordnung V-Modell zu STANAG 4159

7.1	Baselines

Die STANAG 4159 unterscheidet folgende Baselines:

−	Functional Baseline,

−	Development Baseline,

−	Product Baseline.

Tabelle 7.1 ordnet den Baselines die zugehörigen Produkte des V-Modells zu.

Baselines gemäß STANAG 4159	Produkte des V-Modells
Functional Baseline	Anwenderforderungen, Systemarchitektur, Prüfspezifikation
Development Baseline	Technische Anforderungen, Prüfspezifikation
Product Baseline	SW-Architektur, Schnittstellenübersicht, Schnittstellenbeschreibung, Integrationsplan, Datenkatalog, SW-Entwurf, Implementierungsdokumente, Betriebsinformationen, System, Betriebsinformationen, Prüfspezifikation
Tabelle 7.1:	Baselines gemäß STANAG 4159 und zugehörige Produkte des V-Modells


Konfigurationsmanagement-Plan
Teil 2	Vorgehensmodell / Behördenspezifische Ergänzungen

7	Zuordnung V-Modell zu STANAG 4159

7.2	Konfigurationsmanagement-Plan

Die STANAG 4159 unterscheidet mehrere Konfigurationsmanagement-Pläne, die untereinander kompatibel sein müssen:

−	Konfigurationsmanagement-Plan des Vorhabenmanagement,

−	Konfigurationsmanagement-Plan des/der Auftragnehmer,

−	Konfigurationsmanagement-Plan für die Nutzung.

Tabelle 7.2 stellt den Inhalt des Konfigurationsmanagement-Plans gemäß STANAG 4159 den Produkten des V-Modells gegenüber.

Die Unterscheidung in spezielle Konfigurationsmanagement-Pläne für Vorhabenmanagement und Auftragnehmer entspricht der in Abschnitt 1 beschriebenen Praxis bei der Vergabevorbereitung, dem Vertragsabschluß und der Vertragsabwicklung.

Konfigurationsmanagement-Plan gemäß STANAG 4159	Entsprechung im V-Modell
a) Introduction (Einführung)	KM-Plan (Kapitel 1)
b) Applicable documents (Dokumente)	Konfigurations-Identifikationsdokument
c) Configuration Management Organization  (KM-Organisation)	Projekthandbuch (Kapitel 7)
d) Configuration Identification and  Documentation (Konfigurationsidentifikation  und Dokumentation)	KM-Plan (Kapitel 2)
e) Configuration Control (Konfigurations- steuerung)	KM-Plan (Kapitel 3)
f) Configuration Status Accounting  (Konfigurationsnachweisführung)	—
g) Configuration Audits (Konfigurations- prüfungen)	QS-Plan (Kapitel 4), Prüfplan
h) Technical Reviews (Produktprüfungen)	QS-Plan (Kapitel 4), Prüfplan
i) Configuration Management Major  Milestones (KM relevante Meilensteine)	Projektplan (Kapitel 3)
Tabelle 7.2:	Konfigurationsmanagement-Plan gemäß STANAG 4159 und Entsprechung im V-Modell


DV-Anteile in Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

Die Tabellen in den folgenden Abschnitten betreffen die DV-Anteile in Wehrmaterial und beziehen sich deshalb auf die Regelungen nach Teil II des AU 220 (Kap. 5 − 11), den "Bestimmungen für Wehrmaterial (EBMat)". Sie beschreiben die Schnittstellen zwischen AU 220 (EBMat) und V-Modell. Die Tabellen enthalten in der Gegenüberstellung der Aktivitäten und Arbeitsschritte die Aussage, für welchen Arbeitsschritt nach EBMat Beiträge aus entsprechenden V-Modell Aktivitäten erwartet werden können. Die Gegenüberstellung der Kapitel der Stufenentscheidungen/Phasendokumente zu den Produkten des V-Modells zeigt an, wo Produkte des V-Modells Beiträge zu den Kapiteln der Stufenentscheidungen/Phasendokumente leisten können. Diese Inhalte können dann gegebenenfalls direkt oder in verkürzter Form übernommen werden.


Phasenvorlauf Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.1	Phasenvorlauf Wehrmaterial

Phasenvorlauf Wehrmaterial Teil 1

Die folgende Tabelle stellt für DV-Anteile in Wehrmaterial den Aktivitäten des V-Modells die Arbeitsschritte des Phasenvorlaufs Teil 1 nach EBMat gegenüber.

Aktivität V-Modell	Arbeitsschritt EBMat
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Analyse der Aufgabe
SE 1.2	Anwendungssystem beschreiben
	—	Beurteilen der Risikoentwicklung
SE 1.1	Ist-Aufnahme/-Analyse durchführen	Beschreiben und Bewerten der Ausrüstungslücke
	—	Durchführen einer technologischen Trendanalyse
	—	Erarbeiten und Bewerten taktischer Lösungsideen
SE 1.4 SE 1.5	Randbedingungen definieren System fachlich strukturieren	Erarbeiten und Bewerten militärischer Forderungen an das Wehrmaterial
PM 1.5	Grobplan erstellen	Planen des Phasenvorlaufs Teil 2
PM 4	Feinplanung
	—	Ermitteln des Haushaltsmittelbedarfs für Phasenvorlauf Teil 2
	—	Erarbeiten des Taktischen Konzepts
Tabelle A.1:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 1 (Regelfall)

Die folgende Tabelle stellt den Kapiteln des Taktischen Konzepts die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Taktisches Konzept (TaK)	Produkt V-Modell
1	Bezeichnung	—
2	Zuordnung zur Aufgabe gemäß Grundlagendokument	• Projekthandbuch.Projektbeschreibung • Anwenderforderungen.Grobe Systembeschreibung
3	Problemdarstellung
3.1	Risikoentwicklung	—
3.2	Konzeptionelle Vorgaben und Bewertung	—
3.3	Ausrüstung	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
3.4	Beschreibung der Ausrüstungslücke	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
4	Forderungen/Rahmenbedingungen
4.1	Einsatz
4.1.1	Kurzbeschreibung der geforderten taktischen Fähigkeiten	—
4.1.2	Haupt- und Nebenaufgabe(n)	• Anwenderforderungen.Beschreibung der  Funktionalität
4.1.3	Standardisierungserfordernisse in taktischer, technischer und logistischer Hinsicht	—
4.1.4	Einsatzgebiet	—
4.1.5	Personal	—
4.1.6	Logistik	—
4.1.7	Infrastruktur	—
4.1.8	Wachstumspotential	—
4.1.9	Aufwand in der Nutzung	—
4.1.10	Verwertung/Entsorgung	—
4.2	Bedarf
4.2.1	Bedarfsträger	—
4.2.2	Zahlenmäßiger Bedarf	—
4.3	Zeit
4.3.1	Beginn der Nutzung	—
4.3.2	Dauer der Indiensthaltung	—
5	Lösungsideen und taktisches Konzept
5.1	Darstellung und Bewertung alternativer taktischer Lösungsideen	—
5.2	Festlegung des taktischen Konzepts zur Schließung der Ausrüstungslücke	—
5.3	Begründung für die Konzeptauswahl	—
6	Plankosten für die weitere Behandlung des Vorhabens im Rahmen des Phasenvorlaufs	—
Tabelle A.2:	Taktisches Konzept und Produkte des V-Modells

Phasenvorlauf Wehrmaterial Teil 2

Die folgende Tabelle stellt für DV-Anteile in Wehrmaterial den Aktivitäten des V-Modells die Arbeitsschritte des Phasenvorlaufs Teil 2 nach EBMat gegenüber.

Aktivität V-Modell	Arbeitsschritt EBMat
PM 6	Durchführungsentscheidung	Anlegen der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Erarbeiten der Planungs- und Steuerungsunterlagen für das Vorhaben
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Berichtsverfahren / Berichterstattung
SE 2.1	System technisch entwerfen	Ermitteln von Lösungswegen
SE 2.3	Realisierbarkeit untersuchen
SE 2.3	Realisierbarkeit untersuchen	Durchführen von Marktanalysen
SE 2.3	Realisierbarkeit untersuchen	Durchführen von parametrischen Untersuchungen/ Experimentalstudien
PM 5	Kosten-/Nutzenanalyse	Schätzen der Lebenswegkosten
SE 2.3	Realisierbarkeit untersuchen	Durchführen von Realisierbarkeitsuntersuchungen
SE 2.3	Realisierbarkeit untersuchen	Erbringen des Realisierbarkeitsnachweises
SE 2.3	Realisierbarkeit untersuchen	Aufstellen von Bewertungskriterien
SE 2.1	System technisch entwerfen	Vergleichende Gesamtbewertung und Auswählen der Lösung
SE 2.3	Realisierbarkeit untersuchen
SE 1.5	System fachlich strukturieren	Präzisieren der militärischen und der weiteren Elemente
SE 1.6	Bedrohung und Risiko analysieren	Erstellen einer Sicherheitsanalyse
SE 2.1	System technisch entwerfen
SE 1.6	Bedrohung und Risiko analysieren	Erstellen des IT-Sicherheitskonzeptes
SE 2.1	System technisch entwerfen
	—	Erstellen einer Umweltverträglichkeitsanalyse
PM 4	Feinplanung	Fortschreiben Planungs- und Steuerungsunterlagen für Definition, Entwicklung und Beschaffung
	—	Ermitteln des Haushaltsmittelbedarfs insbesondere für die nächste Phase
	—	Erarbeiten der Taktisch-Technischen Forderung
PM 1.1	Projekt einrichten	Übergabe der Entscheidungsdokumentation sowie der Planungs- und Steuerungsunterlagen 1)
1)	Dieser Arbeitsschritt erfolgt im Rahmen der Projekteinrichtung (Aktivität PM 1.1) in der Definitionsphase.

Tabelle A.3:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 2 (Regelfall)

Die folgende Tabelle stellt den Kapiteln der Taktisch-Technischen Forderung die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Taktisch-Technische Forderung (TTF)	Produkt V-Modell
1	Bezeichnung	—
2	Zuordnung zur Aufgabe gemäß Grund-lagendokument	• Projekthandbuch.Projektbeschreibung • Anwenderforderungen.Grobe Systembeschreibung
3	Bezugsdokumente	—
4	Problemdarstellung
4.1	Risikoentwicklung und Ausrüstungslücke	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
4.2	Einsatzbedingungen	• Anwenderforderungen.Externe Schnittstellen
4.3	Einsatzkonzept	• Anwenderforderungen.Organisatorische  Einbettung
5	Forderungen
5.1	Forderungen an die militärischen Elemente	—
5.2	Forderungen an die technisch-wirtschaftlichen Elemente	• Anwenderforderungen.Externe Schnittstellen • Anwenderforderungen.Beschreibung der  Funktionalität
5.3	Forderungen an die weiteren Elemente	• Anwenderforderungen.Externe Schnittstellen
5.4	Forderungen zur Minimierung der Betriebskosten in der Nutzung	—
5.5	Wachstumspotential	—
5.6	Bedarf	—
5.7	Zeit	—
6	Auswahl der taktisch-technischen Lösung
6.1	Auswahlkriterien für die Bewertung der Lösungswege	• Systemarchitektur.Realisierbarkeits- untersuchungen
6.2	Beschreibung und Bewertung möglicher Lösungswege	• Systemarchitektur.Lösungsvorschläge • Systemarchitektur.Struktur des Systems • Systemarchitektur.Realisierbarkeits- untersuchungen
6.3	Begründung für die Auswahl der taktisch-technischen Lösung	• Systemarchitektur.Realisierbarkeits- untersuchungen
6.4	Kosten	—
7	Weitere Behandlung des Vorhabens
7.1	Abhängigkeit von anderen Vorhaben (Festlegung von Leitvorhaben)	—
7.2	Materialverantwortlicher	—
7.3	Verfahrensablauf	—
7.4	Zeitplanung für Definition, Entwicklung und Beschaffung	• Projektplan.Aufwands- und Terminplan
8	Bestandteile des Dokuments	—
Tabelle A.4:	Taktisch-Technische Forderung und Produkte des V-Modells


Definitionsphase Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.2	Definitionsphase Wehrmaterial

Die folgende Tabelle stellt für DV-Anteile in Wehrmaterial den Aktivitäten des V-Modells die Arbeitsschritte der Definitionsphase nach EBMat gegenüber.

Aktivität V-Modell	Arbeitsschritt EBMat
PM 6	Durchführungsentscheidung	Übernehmen / Fortschreiben der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Fortschreiben der Planungs- und Steuerungs-unterlagen
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Festlegen des Berichtsverfahrens
SE 3.1	Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren	Festlegen/Fortschreiben/Präzisieren der Forderungen
SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren
SE 3.3	Anforderungen an die Funktionalität definieren
SE 3.4	Anforderungen an die Qualität der SW-/HW-Einheit definieren
PM 2	Vergabe/Beschaffung	Erarbeiten der Leistungsbeschreibungen für Untersuchungen und Studien
	—	Festlegen von Bewertungskriterien
	—	Durchführen militärischer Einzeluntersuchungen
SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren	Durchführen von Einzeluntersuchungen zu den weiteren Elementen
	—	Durchführen technischer Einzeluntersuchungen
PM 5	Kosten-/Nutzenanalyse	Fortschreiben Lebenswegkosten/ Wirtschaftlichkeitsuntersuchungen
	—	Erstellen einer Definitionsstudie
	—	Bewerten der Untersuchungen und Studien
	—	Auswählen der Lösung
	—	Aufstellen der Endgültigen Spezifikationen
PM 2	Vergabe/Beschaffung	Auswählen des gesamtverantwortlichen Auftragnehmers für die Entwicklung
PM 4	Feinplanung	Fortschreiben Planungs- und Steuerungsunterlagen für Entwicklung und Beschaffung
	—	Erarbeiten des Versorgungsreifeplans
	—	Erstellen der MTWF
Tabelle A.5:	Aktivitäten und Arbeitsschritte in der Definitionsphase Wehrmaterial (Regelfall)

Die folgende Tabelle stellt den Kapiteln der Endgültigen Spezifikationen die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Endgültige Spezifikationen	Produkt V-Modell
1	Bezeichnung	—
2	Bezugsdokumente	—
3	Spezifikationen
3.1	Beschreibung (Einsatzmaterial und Zubehör)	—
3.2	Technische Eigenschaften, Leistungsmerkmale	• Technische Anforderungen
3.3	Erfordernisse für Betrieb und Material- erhaltung	—
3.4	Nachweise	—
Tabelle A.6:	Endgültigen Spezifikationen und Produkte des V-Modells

Die folgende Tabelle stellt den Kapiteln der Militärisch-Technisch-Wirtschaftlichen Forderung die inhaltlich entsprechenden Kapitel der V-Modell-Produkte gegenüber.

Militärisch-Technisch-Wirtschaftliche Forderung (MTWF)	Produkt V-Modell
1	Bezeichnung	—
2	Bezugsdokumente	—
3	Definition
3.1	Beschreibung und Begründung der Lösung
3.1.1	Einsatzkonzept	—
3.1.2	Leistungsmerkmale	• Technische Anforderungen
3.1.3	Bedarf	—
3.1.4	Personal	—
3.1.5	Ausbildung	• Sonstige Einsatzinformationen
3.1.6	militärische Sicherheit	—
3.1.7	Organisation	—
3.1.8	Logistik	• Sonstige Einsatzinformationen
3.1.9	Infrastruktur	• Sonstige Einsatzinformationen
3.1.10	Begründung der festgelegten Lösung	—
3.1.11	Realisierbarkeitsbeurteilung	—
3.2	Weitere Behandlung des Vorhabens	—
3.2.1	Stückzahlen	—
3.2.2	Termine	• Projektplan.Aufwands- und Terminplan
3.2.3	Preise	—
3.2.4	Kosten	—
4	Auswahl des gesamtverantwortlichen Auftragnehmers für die Entwicklungsphase	• Angebotsbewertung
5	Bestandteile des Phasendokuments	—
Tabelle A.7:	Militärisch-Technisch-Wirtschaftliche Forderung und Produkte des V-Modells


Entwicklungsphase Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.3	Entwicklungsphase Wehrmaterial

Die folgende Tabelle stellt für DV-Anteile in Wehrmaterial den Aktivitäten des V-Modells die Arbeitsschritte der Entwicklungsphase nach EBMat gegenüber.

Aktivität V-Modell	Arbeitsschritt EBMat
PM 6	Durchführungsentscheidung	Fortschreiben der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Fortschreiben der Planungs- und Steuerungs-unterlagen
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Anpassen des Berichtsverfahrens
PM 2	Vergabe/Beschaffung	Auswählen des gesamtverantwortlichen Auftragnehmers
PM 2	Vergabe/Beschaffung	Einleiten der Entwicklung, Erstellen der Leistungsbeschreibung für die Entwicklung, Abschluß des Entwicklungsvertrags
SE 4-SW	SW-Grobentwurf	Durchführen des Entwicklungsauftrags
SE 5-SW	SW-Feinentwurf
SE 6-SW	SW-Implementierung
SE 7-SW	SW-Integration
SE 8	System-Integration
	—	Freigabe zum Bau
	—	Bearbeiten der militärischen und der weiteren Elemente
QS 2	Prüfungsvorbereitung	Durchführen der Technischen Erprobung
QS 4	Produktprüfung
	—	Erklärung der Funktionsbereitschaft und Betriebssicherheit
	—	Durchführung des Truppenversuchs
	—	Zusammenlegung von Erprobung und Truppen- versuch
	—	Herstellen der Serienreife
	—	Erklärung zur Versorgungsreife
	—	Erklärung der Technischen Einführungsreife
	—	Festlegung des Konstruktionsstandes
PM 5	Kosten-/Nutzenanalyse	Fortschreiben Lebenswegkosten/ Wirtschaftlichkeitsuntersuchungen
	—	Erklärung der Truppenverwendbarkeit
PM 4	Feinplanung	Fortschreiben der Planungs- und Steuerungsunterlagen für die Beschaffung
	—	Vorziehen von Maßnahmen der Beschaffungsphase
	—	Erarbeiten der Einführungsgenehmigung
PM 3	Auftragnehmer-Management	Funktionsnachweis und Abnahme
	—	Übernahme
	—	Erarbeiten der Indienststellung/Inbetriebnahme
Tabelle A.8:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase Wehrmaterial (Regelfall)


Beschaffungsphase Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.4	Beschaffungsphase Wehrmaterial

In der Beschaffungsphase Wehrmaterial gilt das V-Modell für die Durchführung von SWPÄ-Maßnahmen an den DV-Anteilen (siehe Abschnitt 5).


Nutzung Wehrmaterial
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.1	DV-Anteile in Wehrmaterial

A.1.5	Nutzung Wehrmaterial

In der Nutzung gilt das V-Modell für die Durchführung von SWPÄ-Maßnahmen an den DV-Anteilen (siehe Abschnitt 5).

Wenn DV-Anteile nicht gemäß V-Modell, sondern nach anderen Regelungen entwickelt wurden, sind bei SWPÄ-Maßnahmen dennoch die Aktivitäten der Submodelle PM, KM und QS des V-Modells durchzuführen.


DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

Die Tabellen in den folgenden Abschnitten betreffen die DV-Vorhaben und beziehen sich deshalb auf die Regelungen nach Teil III des AU 220 (Kap. 12 − 17), den "Bestimmungen für Datenverarbeitungsvorhaben (EEDV)". Sie beschreiben die Schnittstellen zwischen AU 220 (EEDV) und V-Modell. Die Tabellen enthalten in der Gegenüberstellung der Aktivitäten und Arbeitsschritte die Aussage, für welchen Arbeitsschritt nach EEDV Beiträge aus entsprechenden V-Modell Aktivitäten erwartet werden können. Die Gegenüberstellung der Kapitel der Stufenentscheidungen/Phasendokumente zu den Produkten des V-Modells zeigt an, wo Produkte des V-Modells Beiträge zu den Kapiteln der Stufenentscheidungen/Phasendokumente leisten können. Diese Inhalte können dann gegebenenfalls direkt oder in verkürzter Form übernommen werden. Rote Schrift innerhalb der Tabellen zeigt vollständige Abdeckung eines Arbeitsschritts bzw. Kapitels einer Stufenentscheidungen/ eines Phasendokuments durch Aktivitäten bzw. Produkte des V-Modells an.


Phasenvorlauf DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

A.2.1	Phasenvorlauf DV-Vorhaben

Die folgende Tabelle stellt für DV-Vorhaben den Aktivitäten des V-Modells die Arbeitsschritte des Phasenvorlaufs nach EEDV gegenüber.

Aktivität V-Modell	Arbeitsschritt EEDV
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Analyse der Aufgabe
SE 1.2	Anwendungssystem beschreiben
SE 1.1	Ist-Aufnahme/-Analyse durchführen	Analyse des Umfeldes
SE 1.1	Ist-Aufnahme/-Analyse durchführen	Beschreiben und Bewerten des Informationsbedarfs
SE 1.2	Anwendungssystem beschreiben
SE 1.5	System fachlich strukturieren
PM 6	Durchführungsentscheidung	Anlegen der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Erarbeiten der Planungs- und Steuerungsunterlagen für den weiteren Phasenvorlauf
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Berichtsverfahren / Berichterstattung
SE 2.1	System technisch entwerfen	Erarbeiten und Bewerten von Lösungsalternativen
SE 2.3	Realisierbarkeit untersuchen
SE 1.2	Anwendungssystem beschreiben	Erarbeiten und Bewerten militärischer/
SE 1.5	System fachlich strukturieren	administrativer Forderungen an die Informationsversorgung und die Aufgabenunterstützung
SE 2.3	Realisierbarkeit untersuchen	Durchführen von Marktanalysen
SE 2.3	Realisierbarkeit untersuchen	Durchführen von parametrischen Untersuchungen/ Experimentalstudien
SE 2.3	Realisierbarkeit untersuchen	Durchführen von Realisierbarkeitsuntersuchungen
SE 2.3	Realisierbarkeit untersuchen	Aufstellen von Bewertungskriterien
SE 2.1	System technisch entwerfen	Auswählen der Lösung
SE 1.2	Anwendungssystem beschreiben	Präzisieren der militärischen/administrativen Elemente
SE 1.5	System fachlich strukturieren
SE 1.8	Software-Pflege- und Änderungs-Konzept erstellen
SE 1.6	Bedrohung und Risiko analysieren	Erstellen des IT-Sicherheitskonzeptes
SE 2.1	System technisch entwerfen
PM 5	Kosten-/Nutzenanalyse	Abschätzen der Lebenswegkosten und des Nutzens
	—	Erarbeiten des Informationsversorgungskonzepts (IVK)
PM 1.5	Grobplan erstellen	Erarbeiten der Zeit- und Kostenplanung für die nachfolgenden Phasen und die Nutzung
	—	Erarbeiten der Organisatorisch-Technischen Forderung (OTF)
PM 1.1	Projekt einrichten	Übergabe der Entscheidungsdokumentation sowie der Planungs- und Steuerungsunterlagen 2)
Tabelle A.9:	Aktivitäten und Arbeitsschritte im Phasenvorlauf DV-Vorhaben (Regelfall)

2)	Dieser Arbeitsschritt erfolgt im Rahmen der Projekteinrichtung (Aktivität PM 1.1) in der Definitionsphase.

Die folgende Tabelle stellt den Kapiteln des Informationsversorgungskonzepts die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Informationsversorgungskonzept (IVK)	Produkt V-Modell
1	Bezeichnung	—
2	Darstellung der Aufgabe	• Projekthandbuch.Projektbeschreibung • Anwenderforderungen.Grobe Systembeschreibung
3	Problemdarstellung
3.1	Darstellung des Umfeldes
3.1.1	Organisation	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
3.1.2	Informationsbedarf und Informations-beziehungen	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
3.1.3	Militärisches Risiko	—
3.2	Informationsversorgung/Aufgaben- unterstützung
3.2.1	Istzustand	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
3.2.2	Mängel und Schwachstellen	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
3.3	Konzeptionelle Vorgaben und Bewertung	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
4	Forderungen und Rahmenbedingungen
4.1	Kurzbeschreibung der geforderten Fähigkeiten der Informationsversorgung/Aufgaben- unterstützung	• Anwenderforderungen.Fachliche Anforderungen
4.2	Standardisierungserfordernisse	• Anwenderforderungen.Externe Schnittstellen
4.3	Einsatzgebiet	• Anwenderforderungen.Nutzung
4.4	Sicherheit (IT-Sicherheit und militärische Sicherheit)	• Anwenderforderungen.Bedrohungs- und  Risikoanalyse • Systemarchitektur.IT-Sicherheitskonzept
4.5	Personal	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
4.6	Ausbildung	• Sonstige Einsatzinformationen
4.7	Logistik/SWPÄ	• SWPÄ-Konzept
4.8	Infrastruktur	• Sonstige Einsatzinformationen
4.9	Militärisches Geowesen	—
4.10	Betriebsaufwand in der Nutzung	—
4.11	Bedarfsträger	—
4.12	Zahlenmäßiger Bedarf	—
4.13	Beginn der Nutzung	—
4.14	Dauer der Nutzung	—
5	Lösungsansätze und Konzept zur Informationsversorgung/Aufgaben- unterstützung
5.1	Darstellung und Bewertung unterschiedlicher Lösungsansätze	• Systemarchitektur.Lösungsvorschläge
5.2	Festlegung des Konzepts zur Informations-versorgung/Aufgabenunterstützung	• Systemarchitektur.Struktur des Systems
5.3	Begründung des Konzeptvorschlags	• Systemarchitektur.Realisierbarkeits- untersuchungen
6	Plankosten für die weitere Behandlung des Vorhabens	—
Tabelle A.10:	Informationsversorgungskonzept und Produkte des V-Modells

Die folgende Tabelle stellt den Kapiteln der Organisatorisch-Technischen Forderung die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Organisatorisch-Technische Forderung (OTF)	Produkt V-Modell
1	Bezeichnung	—
2	Darstellung der Aufgabe	• Projekthandbuch.Projektbeschreibung • Anwenderforderungen.Grobe Systembeschreibung
3	Bezugsdokumente	—
4	Problemdarstellung
4.1	Darstellung des Umfeldes und des Informationsbedarfs/Unterstützungsbedarfs	• Anwenderforderungen.Ist-Aufnahme und Ist- Analyse
4.2	Verwendungszweck	—
4.3	Konzept zur Informationsversorgung/ Aufgabenunterstützung	• Systemarchitektur.Struktur des Systems
5	Forderungen
5.1	Forderungen an die technisch-wirtschaftlichen Elemente	• Anwenderforderungen.Fachliche Anforderungen
5.2	Forderungen an die militärischen/ administrativen Elemente	—
5.3	Forderungen an die weiteren Elemente	• Anwenderforderungen.Externe Schnittstellen
5.4	Bedarf	—
5.5	Zeit	—
6	Auswahl der organisatorisch-technischen Lösung
6.1	Auswahlkriterien für die Bewertung der Lösungsalternativen	• Systemarchitektur.Realisierbarkeits- untersuchungen
6.2	Beschreibung und Bewertung möglicher Lösungsalternativen	• Systemarchitektur.Lösungsvorschläge
6.3	Begründung für die Auswahl der organisatorisch-technischen Lösung	• Systemarchitektur.Realisierbarkeits untersuchungen
6.4	Aufschlüsselung des Aufwands für Definition, Entwicklung und Einführung	• Projektplan.Aufwands- und Terminplan
6.5	Wirtschaftlichkeit	• Kosten-/Nutzenanalyse
7	Weitere Behandlung des Vorhabens
7.1	Einstufung	—
7.2	Nutzungsverantwortlicher	—
7.3	Vorhabenmanagement	• Projekthandbuch.Projektorganisation
7.4	Weiterer Ablauf des Vorhabens	• Projekthandbuch.Entwicklungsstrategie
		• Projektplan.Aufwands- und Terminplan
7.5	Zeitplanung für Definition, Entwicklung, Einführung und Nutzung	• Projektplan.Aufwands- und Terminplan
8	Bestandteile des Dokuments	—
Tabelle A.11:	Organisatorisch-Technische Forderung und Produkte des V-Modells


Definitionsphase DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

A.2.2	Definitionsphase DV-Vorhaben

Die folgende Tabelle stellt für DV-Vorhaben den Aktivitäten des V-Modells die Arbeitsschritte der Definitionsphase nach EEDV gegenüber.

Aktivität V-Modell	Arbeitsschritt EEDV
PM 6	Durchführungsentscheidung	Übernehmen und Fortschreiben der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Fortschreiben der Planungs- und Steuerungs-unterlagen
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Festlegen des Berichtsverfahrens
	—	Festlegen von Bewertungskriterien
SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren	Durchführen von technischen Einzeluntersuchungen
SE 3.3	Anforderungen an die Funktionalität definieren
SE 1.8	Software-Pflege- und Änderungs-Konzept erstellen	Präzisieren der militärischen/administrativen Elemente
SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren	Präzisieren der weiteren Elemente
	—	Untersuchen kritischer Komponenten
PM 2	Vergabe/Beschaffung	Leistungsbeschreibung für Untersuchungen in der Definitionsphase
	—	Festlegen der Lösung
SE 3.1	Allgemeine Anforderungen aus Sicht der SW-/HW-Einheit definieren	Aufstellen der Spezifikationen für die Entwicklung
SE 3.2	Anforderungen an die externen Schnittstellen der SW-/HW-Einheit präzisieren
SE 3.3	Anforderungen an die Funktionalität definieren
SE 3.4	Anforderungen an die Qualität der SW-/HW-Einheit definieren
PM 2	Vergabe/Beschaffung	Auswählen des gesamtverantwortlichen Auftragnehmers für die Entwicklungsphase
	—	Fortschreiben des AZF-Plans für die Folgephasen
	—	Erstellen des Phasendokuments "Realisierungsplan"
Tabelle A.12:	Aktivitäten und Arbeitsschritte in der Definitionsphase DV-Vorhaben (Regelfall)

Die folgende Tabelle stellt den Kapiteln des Realisierungsplans die inhaltlich entsprechenden V-Modell-Produkte gegenüber.

Realisierungsplan	Produkt V-Modell
1	Bezeichnung	—
2	Bezugsdokumente	—
3	Zielsetzung des Vorhabens	• Projekthandbuch.Projektbeschreibung • Anwenderforderungen.Grobe Systembeschreibung
4	Definitionsentscheidung
4.1	Beschreibung der technischen Lösung und der organisatorischen Auswirkungen	• Technische Anforderungen
4.2	Entscheidungen zu den militärischen/ administrativen Elementen	• SWPÄ-Konzept
4.3	Entscheidungen zu den weiteren Elementen	• Technische Anforderungen
4.4	Begründung der Lösung	—
4.5	Wirtschaftlichkeit	• Kosten-/Nutzenanalyse
5	Spezifikationen für die Entwicklung	• Technische Anforderungen
6	Gesamtverantwortlicher Auftragnehmer	• Angebotsbewertung
7	Weiteres Vorgehen mit Angaben zu Kosten und Terminen
7.1	Überleitungskonzept	• Sonstige Einsatzinformationen
7.2	Plankosten für Entwicklung und Einführung	—
7.3	Zeitplanung für Entwicklung und Einführung	• Projektplan.Aufwands- und Terminplan
8	Bestandteile des Dokuments	—
Tabelle A.13:	Realisierungsplan und Produkte des V-Modells


Entwicklungsphase DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

A.2.3	Entwicklungsphase DV-Vorhaben

Die folgende Tabelle stellt den Aktivitäten des V-Modells die Arbeitsschritte der Entwicklungsphase nach EEDV gegenüber.

Aktivität V-Modell	Arbeitsschritt EEDV
PM 6	Durchführungsentscheidung	Fortschreiben der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Fortschreiben der Planungs- und Steuerungs-unterlagen
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Anpassen des Berichtsverfahrens
PM 8	Projektkontrolle und -steuerung	Vorgaben für die Entwicklung
	—	Vorbereiten der Beschaffung
QS 1.2	Prüfplan erstellen	Festlegen der durch Bedarfsdecker und Bedarfsträger durchzuführenden Tests und Abnahmen
SE 4-SW	SW-Grobentwurf	Durchführen der Entwicklung
SE 5-SW	SW-Feinentwurf
SE 6-SW	SW-Implementierung
SE 7-SW	SW-Integration
SE 8	System-Integration
SE 1.8	Software-Pflege- und Änderungs-Konzept erstellen	Bearbeiten der militärischen/administrativen Elemente
	—	Bearbeiten der weiteren Elemente
QS 2 QS 4	Prüfungsvorbereitung Produktprüfung	Durchführen der bedarfsdecker- und bedarfs-trägerseitigen Tests und Abnahmen
	—	Vorbereiten der Einführung
PM 6	Durchführungsentscheidung	Freigabe von Teilen des Vorhabens für die  Teilnutzung
PM 2	Vergabe/Beschaffung	Auswahl des gesamtverantwortlichen Auftragnehmers für die Einführungsphase
	—	Fortschreiben des AZF-Plans
	—	Erstellen des Phasendokuments "Genehmigung der Inbetriebnahme"
Tabelle A.14:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase DV-Vorhaben (Regelfall)


Einführungsphase DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

A.2.4	Einführungsphase DV-Vorhaben

Die folgende Tabelle stellt den Aktivitäten des V-Modells die Arbeitsschritte der Einführungsphase nach EEDV gegenüber.

Aktivität V-Modell	Arbeitsschritt EEDV
PM 6	Durchführungsentscheidung	Fortschreiben der Entscheidungsdokumentation
PM 1.2	Projektkriterien und Entwicklungsstrategie festlegen	Fortschreiben der Planungs- und Steuerungs-unterlagen
PM 1.3	Projektspezifisches V-Modell erstellen
PM 1.5	Grobplan erstellen
PM 4	Feinplanung
PM 1.1	Projekt einrichten	Anpassen des Berichtsverfahrens
SE 9.1	Beitrag zur Einführungsunterstützung leisten	Abschließendes Bearbeiten der militärischen/ administrativen und der weiteren Elemente
PM 2	Vergabe/Beschaffung	Abschluß des Beschaffungsvertrages, Durchführen der Beschaffung
SE 9	Überleitung in die Nutzung	Überführung des Vorhabens in die Nutzung
	—	Erstellen des Abschlußberichts
Tabelle A.15:	Aktivitäten und Arbeitsschritte in der Einführungsphase DV-Vorhaben (Regelfall)


Nutzung DV-Vorhaben
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

A	Zuordnung der Aktivitäten und Produkte des V-Modells zu den Phasen des AU 220

A.2	DV-Vorhaben

A.2.5	Nutzung DV-Vorhaben

In der Nutzung gilt das V-Modell für die Durchführung von SWPÄ-Maßnahmen (siehe Abschnitt 5).

Wenn das System nicht gemäß V-Modell, sondern nach anderen Regelungen entwickelt wurde, sind bei SWPÄ-Maßnahmen dennoch die Aktivitäten der Submodelle PM, KM und QS des V-Modells durchzuführen.


Produktmuster SWPÄ-Konzept
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.1	Produktmuster SWPÄ-Konzept

Das

SWPÄ-Konzept für

.....................................................................

wird genehmigt:

BT-Amt		BD-Amt
1  Allgemeine Rahmenbedingungen

a.  Vorbemerkungen

(1)	Forderung SWPÄ-Konzept-Erstellung

Das Erfordernis, für das Vorhaben .......... ein SWPÄ-Konzept zu erstellen, ergibt sich aus .......... .

(2)	Geltungsbereich

Hier ist anzugeben, für welche Vorhaben dieses Konzept gilt.

(3)	Krise, Krieg und besondere Einsatzbedingungen

Ergeben sich Besonderheiten, ist dies gegebenenfalls in den folgenden Kapiteln anzumerken.

(4)	Fortschreibung des SWPÄ-Konzepts in der Nutzung

Zuständigkeiten, Mitarbeit und Verfahren sind zu beschreiben.

b.  Bezugsdokumente

nur für das Vorhaben relevante Dokumentation

(1)	Vorhabensunabhängige Dokumente

z. B. AU 220, AU 250, STANAG 4159

(2)	Vorhabensbezogene Dokumente

z. B. Stufenentscheidungen und Phasendokumente gemäß AU 220, wesentliche Management-Entscheidungen, Dokumente gemäß AU 250, Logistische Vorgaben, STAN-Dokumente

c.  Begriffsbestimmungen

Es sind diejenigen Begriffe zu definieren, die im SWPÄ-Konzept verwandt werden und für die Einheitlichkeit des Verständnisses erforderlich sind. Jede Definition ist mit einer Quellenangabe zu versehen.

d.  Vorgaben für die SWPÄ-Organisation

Hier sind im wesentlichen die Bereiche Personal, Ausbildung, Material, Dokumente/Erlasse, Haushaltsmittel, Infrastruktur, militärische Sicherheit, Programmiersprachen, Führung und Einsatz, Logistik, Organisation/STAN zu berücksichtigen. An dieser Stelle ist auf bestehende logistische Verfahren (z. B. Konfigurationsmanagement) hinzuweisen.

2  Beschreibung des DV-Vorhabens/des DV-Anteils in Wehrmaterial

a.  Kurzbeschreibung

Allgemeine Faktoren (beispielsweise Einsatzort, Zeitpunkt/-spanne und Inbetriebnahme) sind zu beschreiben.

b.  Besondere Merkmale, Aufgaben und Fähigkeiten

(1)	Anforderungen an die Verfügbarkeit

(2)	Sicherheits- und Zuverlässigkeitskriterien

(3)	Internationale Vertragsregelungen und Verpflichtungen

(4)	Standardisierungsabkommen (z. B. STANAG 5500)

(5)	Interoperabilität

(6)	Abhängigkeiten von anderen Systemen

3  Bewertung der SW-Anteile hinsichtlich SWPÄ

a.  Identifizieren und Zuordnen von SW-Anteilen

Für einzelne DV-Anteile ist anzugeben, ob SWPÄ durchzuführen ist/erforderlich werden könnte bzw. ob keine SWPÄ notwendig ist. Die Verantwortung für die SWPÄ der entsprechend identifizierten SW-Anteile ist den betroffenen Organisationen (z. B. Behörde, Industrie) zuzuordnen.

b.  Auswirkungen auf die SWPÄ

Es sind Merkmale der Software mit ihren Auswirkungen auf die SWPÄ anzugeben (z. B. Qualität der SW, Programmiersprachen, Dokumentation, SW-Strukturierung, Anwendung von Standards).

4  Forderungen an die SWPÄ-Organisation

Die aus Kapitel 2 und 3 abgeleiteten Anforderungen sind anzugeben (z. B. aus dem geschätzten Aufwand abgeleiteter Personalbedarf; besondere Anforderungen an die SW-Entwicklungsumgebung).

5  SWPÄ-Organisation

a.  Materialverantwortlicher/vorhabenverantwortlicher Bedarfsträger

b.  Aufbauorganisation

(1)	Organisationselemente

(a)	Konfigurationskontrollgruppe (KKG)

−	Auftrag

−	Zusammensetzung, Vorsitz und Stimmrecht

−	Steuerungs-/Koordinierungsaufgaben, Zuständigkeiten

−	Arbeitsweise

−	Unterstützung der Administration

(b)	Software Trouble Board (SWTrBd)

−	Auftrag

−	Zusammensetzung, Vorsitz und Stimmrecht

−	Aufgaben, Zuständigkeiten

•	Steuerungs-/Koordinierungsaufgaben

•	Durchführungsaufgaben

−	Arbeitsweise

−	Unterstützung der Administration

(c)	Programmiereinrichtung/Programmierteam (PT)

−	Auftrag

−	Zusammensetzung, Leitung

−	Durchführungsaufgaben, Zuständigkeiten

•	Bedarfsträger (BT)

•	Bedarfsdecker (BD)

•	Industrie

•	andere Dienststellen

−	Arbeitsweise

−	Unterstützung der Administration

(2)	Beziehungen zu anderen Dienststellen und/oder der Industrie

Hier sind diejenigen Dienststellen und/oder Firmen aufzuführen, die mit der SWPÄ-Organisation befaßt sind, aber keine Durchführungsfunktionen übernehmen.

c.  Ablauforganisation

(1)	SWPÄ-Verfahren

(a)	Einzelschritte

z. B.:

−	Vorlage Softwaremeldung (Problemmeldung/Änderungsantrag)

−	Registrierung Softwaremeldung

−	Analyse/Bewertung (Lösungsmöglichkeiten)

−	Entscheidung

−	Realisierung

−	Qualitätssicherung

−	Freigabe

−	Änderungsmitteilung

−	Verteilung Datenträger/Installation SW

−	Abschlußmeldung, Archivierung

−	Aktualisierung Änderungsstatusliste

(b)	Ablaufdiagramm

(2)	Sonstige Verfahren

Spezielle vorhabensbezogene Regelungen (z. B. für IT-Sicherheit)

d.  Personelle und materielle Voraussetzungen

(1)	Personalbedarf

Hier ist der Personalbedarf für Steuerungs- und Durchführungsaufgaben bezogen auf die Organisationseinheiten (BT/BD) und/oder Industrie anzugeben. Es ist nachzuweisen, wie der Bedarf gedeckt werden wird (wesentlicher Faktor zur Herstellung der Versorgungsreife).

(a)	Umfang/Dotierung

(b)	Ausbildung/Qualifikation

(2)	Materielle Voraussetzungen

(a)	Produkte

Auflistung der Produkte, die gemäß AU 250 während des Vorhabensablaufs vor Übernahme der SW in die Nutzung entstehen müssen und somit Grundlage für die Durchführung von SWPÄ werden.

(b)	Software-Entwicklungsumgebung (SEU)

Produktionsanlagen und SW-Ausstattung der für die SWPÄ vorgesehenen Organisationseinheiten (z. B. Programmiereinrichtung)

(c)	Referenzanlagen/Simulationseinrichtungen

(d)	Infrastruktur

(e)	IT-Sicherheit

z. B. Schlüsselgeräte, Abstrahlsicherheit

(f)	Sonstige Voraussetzungen

z. B. Administration, Logistik

6  Durchführungsplanung

a.  Herstellung der SWPÄ-Bereitschaft

(1)	Zeitplanung für die Aufstellung

−	Personal

−	Infrastruktur

−	Material

−	Ausbildung (BT, BD, anderes Personal)

(2)	Entwicklungsbegleitende Maßnahmen

Z. B. um im Rahmen der Softwareentwicklung die notwendige Qualifikation für die Durchführung von SWPÄ-Maßnahmen in der Nutzung zu erwerben.

b.  Überleitung in die Nutzung

(1)	Zeitplanung

(2)	Beteiligte

(3)	Verfahren

−	Festlegen Baseline

−	Übergabe der Produkte

−	Übernahme des Konfigurationsmanagements

(4)	Datenbestände

(5)	Besonderheiten (z. B. Parallelbetrieb).


PÄ 1: Änderung der Anwenderforderungen
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 1	Änderung der Anwenderforderungen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
KM 2	akzeptiert		Systemarchitektur		—	—
KM 2	akzeptiert		Technische Anforderungen		—	—
KM 2	akzeptiert		Betriebsinformationen		—	—
KM 2	akzeptiert		Anwenderforderungen		PÄ 2-PÄ 5	vorgelegt
—	—		Berichtsdokumente		PÄ 2, PÄ 3, PÄ 8, PM	—
Abwicklung

Aufgrund der Identifikation der Auswirkungen der Änderungen auf die Anwenderforderungen ist das Produkt Anwenderforderungen zu überarbeiten. Eine neue Version des Produkts ist zu erstellen. Die bei der Bearbeitung des Produkts Anwenderforderungen möglichen Auswirkungen und Hinweise auf die Produkte Systemarchitektur, Technische Anforderungen und Betriebsinformationen sind festzuhalten und gegebenenfalls über Berichtsdokumente an die entsprechenden PÄ-Aktivitäten weiterzuleiten. Gegebenenfalls ist ein Forderungscontrolling durchzuführen.

Erläuterung

Weitere Hinweise zur Bearbeitung der Anwenderforderungen sind den Aktivitäten SE 1.1 bis SE 1.6 sowie SE 1.7 (Forderungscontrolling) zu entnehmen. Hinweise zur technischen Strukturierung des Systems (Aktivität SE 2.1) und zur Abbildung der Anwenderforderungen zu Elementen der Systemarchitektur (Aktivität SE 2.4) können bereits hier gesammelt werden und Aktivität PÄ 2 durch Berichtsdokumente zugeleitet werden. Auswirkungen auf die Technischen Anforderungen sind Aktivität PÄ 3 mitzuteilen.

Auswirkungen der Änderungen auf die Betriebsinformationen (speziell die Informationen zum Anwendungshandbuch) sind Aktivität PÄ 8 mitzuteilen.

Als Folge der Überarbeitung der Anwenderforderungen ist im Submodell QS eine Fortschreibung von Prüfspezifikation sowie Prüfprozedur für das System erforderlich.


PÄ 2: Änderung der Systemarchitektur
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 2	Änderung der Systemarchitektur

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
KM 2	akzeptiert		Technische Anforderungen		—	—
KM 2	akzeptiert		Betriebsinformationen		—	—
KM 2	akzeptiert		Schnittstellenübersicht		—	—
KM 2	akzeptiert		Schnittstellenbeschreibung		—	—
KM 2	akzeptiert		Integrationsplan		—	—
KM 2	akzeptiert		Systemarchitektur		PÄ 3-PÄ 6	vorgelegt
PÄ 1	—		Berichtsdokumente		PÄ 3, PÄ 4, PÄ 6, PÄ 8, PM	—
Abwicklung

Aufgrund der Identifikation der Auswirkungen der Änderungen auf die Systemarchitektur ist das Produkt Systemarchitektur zu überarbeiten. Eine neue Version des Produkts ist zu erstellen. Die bei der Bearbeitung des Produkts Systemarchitektur möglichen Auswirkungen und Hinweise auf die Produkte Technischen Anforderungen, Schnittstellenübersicht, Schnittstellenbeschreibung und Integrationsplan sind festzuhalten und gegebenfalls über Berichtsdokumente an die entsprechenden PÄ-Aktivitäten weiterzuleiten.

Erläuterung

Weitere Hinweise zur Bearbeitung der Systemarchitektur sind den Aktivitäten SE 2.1 bis SE 2.4 zu entnehmen.

Auswirkungen auf die Technische Anforderungen sind Aktivität PÄ 3 mitzuteilen. Hinweise zur Schnittstellenbeschreibung (Aktivität SE 2.5) und zur Integrationsplanung (Aktivität SE 2.6) können bereits hier gesammelt werden und den Aktivitäten PÄ 4 und PÄ 6 über Berichtsdokumente zugeleitet werden.

Auswirkungen der Änderungen auf die Betriebsinformationen sind der Aktivität PÄ 8 mitzuteilen.

Als Folge der Überarbeitung der Systemarchitektur ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 3: Änderung der Technischen Anforderungen
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 3	Änderung der Technischen Anforderungen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
PÄ 2	akzeptiert		Systemarchitektur		—	—
KM 2	akzeptiert		Schnittstellenbeschreibung		—	—
KM 2	akzeptiert		Betriebsinformationen		—	—
KM 2	akzeptiert		Technische Anforderungen		PÄ 5, PÄ 6	vorgelegt
PÄ 1, PÄ 2	—		Berichtsdokumente		PÄ 4, PÄ 8, PM	—
Abwicklung

Aufgrund der Identifikation der Auswirkungen der Änderungen auf die Segment- und SW/HW-Struktur ist das Produkt Technische Anforderungen zu überarbeiten. Eine neue Version des Produkts ist zu erstellen. Die bei der Bearbeitung des Produkts Technische Anforderungen möglichen Auswirkungen und Hinweise auf die Schnittstellenbeschreibung sowie die Betriebsinformationen sind festzuhalten und gegebenfalls über Berichtsdokumente an die entsprechenden PÄ-Aktivitäten weiterzuleiten.

Erläuterung

Weitere Hinweise zur Bearbeitung der Technischen Anforderungen sind den Aktivitäten SE 2.1 und SE 3 zu entnehmen.

Hinweise zur Schnittstellenbeschreibung und zu den Betriebsinformationen können bereits hier gesammelt werden und den Aktivitäten PÄ 4 und PÄ 8 über Berichtsdokumente zugeleitet werden.

Als Folge der Überarbeitung der Technischen Anforderungen ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 4: Änderung der Schnittstellenübersicht und Schnittstellenbeschreibung
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 4	Änderung der Schnittstellenübersicht und Schnittstellenbeschreibung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
PÄ 2	akzeptiert		Systemarchitektur		—	—
KM 2	akzeptiert		Integrationsplan		—	—
KM 2	akzeptiert		Schnittstellenübersicht		PÄ 5	vorgelegt
KM 2	akzeptiert		Schnittstellenbeschreibung		PÄ 5	vorgelegt
PÄ 2, PÄ 3	—		Berichtsdokumente		PÄ 6, PM	—
Abwicklung

Aufgrund der Identifikation der Auswirkungen der Änderungen auf die System-, Segment- und SW/HW-Struktur sind die Produkte Schnittstellenübersicht und Schnittstellenbeschreibung zu überarbeiten. Eine neue Version der Produkte ist zu erstellen. Die bei der Bearbeitung möglichen Auswirkungen und Hinweise auf den Integrationsplan sind festzuhalten und gegebenfalls über Berichtsdokumente an Aktivität PÄ 6 weiterzuleiten.

Die über die Berichtsdokumente mitgeteilten Hinweise aus den Aktivitäten PÄ 2 und PÄ 3 bestimmen die zu modifizierenden Kapitel in den Produkten Schnittstellenübersicht und Schnittstellenbeschreibung. Die Beschreibung einer Schnittstelle hat unter Berücksichtigung der Art der Schnittstelle und der beteiligten Funktionseinheiten die relevanten Angaben zu Verwendung, Syntax und Semantik der Schnittstelle zu erfassen.

Erläuterung

Als Folge der Überarbeitung der Schnittstellenübersicht und der Schnittstellenbeschreibung ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 5: Änderung der Software
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
PÄ 2	akzeptiert		Systemarchitektur		—	—
PÄ 3	akzeptiert		Technische Anforderungen		—	—
PÄ 4	akzeptiert		Schnittstellenübersicht		—	—
PÄ 4	akzeptiert		Schnittstellenbeschreibung		—	—
KM 2	akzeptiert		Integrationsplan		—	—
KM 2	akzeptiert		SW-Architektur		PÄ 6	vorgelegt
KM 2	akzeptiert		SW-Entwurf		—	—
KM 2	akzeptiert		Datenkatalog		KM 4	vorgelegt
KM 2	akzeptiert		Implementierungsdokumente		PÄ 7	vorgelegt
—	—		Berichtsdokumente		PÄ 6, PÄ 8, PM	—
Abwicklung

Aufgrund der in den vorausgegangenen PÄ-Aktivitäten vorgenommen Änderungen sind die SW-Architektur, der SW-Entwurf, der Datenkatalog und die betroffenen Implementierungsdokumente zu ändern. Anschließend sind Selbstprüfungen seitens der Entwickler durchzuführen.

Daher besteht diese Aktivität aus den folgenden Aktivitäten:

−	SW-Architektur ändern (Aktivität PÄ 5.1),

−	SW-Entwurf ändern (Aktivität PÄ 5.2),

−	Datenkatalog ändern (Aktivität PÄ 5.3),

−	SW-Implementierung ändern (Aktivität PÄ 5.4),

−	Selbstprüfung durchführen (Aktivität PÄ 5.5).


PÄ 5.1: SW-Architektur ändern
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

PÄ 5.1	SW-Architektur ändern

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
PÄ 2	akzeptiert		Systemarchitektur		—	—
PÄ 3	akzeptiert		Technische Anforderungen		—	—
PÄ 4	akzeptiert		Schnittstellenübersicht		—	—
PÄ 4	akzeptiert		Schnittstellenbeschreibung		—	—
KM 2	akzeptiert		Integrationsplan		—	—
KM 2	akzeptiert		SW-Architektur		PÄ 5.2, PÄ 5.3, PÄ 6	vorgelegt
—	—		Berichtsdokumente		PÄ 6, PÄ 8, PM	—
Abwicklung

Aufgrund der in den vorausgegangenen PÄ-Aktivitäten vorgenommen Änderungen sind die Stellen in der SW-Architektur zu identifizieren, die modifiziert werden müssen. Alle erforderlichen Änderungen sind vorzunehmen.

Die von den Änderungen betroffenen Module sind dem Projektmanagement über Berichtsdokumente anzuzeigen.

Erläuterung

Weitere Hinweise zur Bearbeitung der SW-Architektur sind den Aktivitäten SE 4.1-SW sowie SE 4.2-SW zu entnehmen.

Hinweise zur Integrationsplanung und zu den Betriebsinformationen können hier gesammelt und der Aktivität PÄ 6 bzw. PÄ 8 durch Berichtsdokumente zugeleitet werden.

Als Folge der Überarbeitung der SW-Architektur ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 5.2: SW-Entwurf ändern
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

PÄ 5.2	SW-Entwurf ändern

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 1	akzeptiert		Anwenderforderungen		—	—
PÄ 3	akzeptiert		Technische Anforderungen		—	—
PÄ 5.1	akzeptiert		SW-Architektur		—	—
PÄ 4	akzeptiert		Schnittstellenübersicht		—	—
PÄ 4	akzeptiert		Schnittstellenbeschreibung		—	—
KM 2	akzeptiert		Betriebsinformationen		—	—
KM 2	akzeptiert		SW-Entwurf		PÄ 5.3, PÄ 5.4, PÄ 5.5	vorgelegt
—	—		Berichtsdokumente		PÄ 8, PM	—
Abwicklung

Aufgrund der in der SW-Architektur vorgenommenen Änderungen ist der SW-Entwurf zu modifizieren. Der Einfluß der durchgeführten Änderungen auf den ermittelten Betriebsmittel- und Zeitbedarf ist zu überprüfen.

Erläuterung

Weitere Hinweise zur Bearbeitung des SW-Entwurfs sind den Aktivitäten SE 5.1-SW sowie SE 5.2-SW zu entnehmen.

Hinweise zu den Betriebsinformationen können hier gesammelt werden und der Aktivität PÄ 8 durch Berichtsdokumente zugeleitet werden.

Als Folge der Überarbeitung des SW-Entwurfs ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 5.3: Datenkatalog ändern
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

PÄ 5.3	Datenkatalog ändern

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 5.1	akzeptiert		SW-Architektur		—	—
PÄ 5.2	akzeptiert		SW-Entwurf		—	—
KM 2	akzeptiert		Datenkatalog		PÄ 5.4, KM 4	vorgelegt
Abwicklung

Aufgrund der in dem SW-Entwurf vorgenommenen Änderungen ist der Datenkatalog zu modifizieren. Der Einfluß der durchgeführten Änderungen auf das Datenmodell, das den Implementierungsdokumenten zugrundeliegt, ist zu überprüfen.

Erläuterung

Weitere Hinweise zur Bearbeitung des Datenkatalogs ist der Aktivität SE 5.1-SW zu entnehmen.


PÄ 5.4: SW-Implementierung ändern
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

PÄ 5.4	SW-Implementierung ändern

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	—		Änderungsauftrag		—	—
PÄ 5.2	akzeptiert		SW-Entwurf		—	—
PÄ 5.3	akzeptiert		Datenkatalog		—	—
KM 2	akzeptiert		Implementierungsdokumente (SW-Modul)/SW-Modul		PÄ 5.5	in Bearb.
KM 2	akzeptiert		Implementierungsdokumente (Datenbank)/Datenbank		PÄ 5.5	in Bearb.
—	—		Berichtsdokumente		PM	—
Abwicklung

Aufgrund der im SW-Entwurf vorgenommenen Änderungen ist ein codiertes Modul bzw. eine realisierte Datenbank einschließlich zugehörigem Implementierungsdokument zu modifizieren.

Erläuterung

Weitere Hinweise zur Bearbeitung der Module und Datenbanken sind den Aktivitäten SE 6.1-SW, sowie SE 6.2-SW zu entnehmen.

Als Folge der Überarbeitung der Module und Datenbanken ist im Submodell QS eine Fortschreibung der betroffenen Prüfspezifikationen sowie Prüfprozeduren erforderlich.


PÄ 5.5: Selbstprüfung durchführen
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 5	Änderung der Software

PÄ 5.5	Selbstprüfung durchführen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PÄ 5.2	akzeptiert		SW-Entwurf		—	—
PÄ 5.4	in Bearb.		Implementierungsdokumente (SW-Modul)/SW-Modul		PÄ 7	vorgelegt
PÄ 5.4	in Bearb.		Implementierungsdokumente (Datenbank)/Datenbank		PÄ 7	vorgelegt
Abwicklung

Selbstprüfungen seitens des Entwicklers sind durchzuführen. Sollten diese nicht zum gewünschten Ergebnis führen, müssen durch Debugging die Ursachen des Fehlverhaltens analysiert und entsprechende Korrekturmaßnahmen in die Wege geleitet werden.

Erläuterung

Weitere Hinweise zur Bearbeitung der Module und Datenbanken sind den Aktivitäten SE 6.3-SW sowie SE 6.4-SW zu entnehmen.


PÄ 6: Änderung des Integrationplans
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 6	Änderung des Integrationplans

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PÄ 2	akzeptiert		Systemarchitektur		—	—
PÄ 3	akzeptiert		Technische Anforderungen		—	—
PÄ 5	akzeptiert		SW-Architektur		—	—
KM 2	akzeptiert		Integrationsplan		PÄ 7	vorgelegt
PÄ 2, PÄ 4, PÄ 5	—		Berichtsdokumente		—	—
Abwicklung

Aufgrund der in den PÄ-Aktivitäten vorgenommen Änderungen an den fachlichen und technischen Anforderungen und Konzepten ist der Integrationsplan zu überarbeiten.

Es ist zu identifizieren (entsprechend den Berichtsdokumenten), welche Modifikationen im Integrationsplan vorzunehmen sind.

Erläuterung

Weitere Hinweise zur Integration ist den Aktivitäten SE 2.6 sowie SE 4.3-SW zu entnehmen.


PÄ 7: Integration
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 7	Integration

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PÄ 5	akzeptiert		Implementierungsdokumente (SW-Modul)/SW-Modul		—	—
PÄ 5	akzeptiert		Implementierungsdokumente (Datenbank)/Datenbank		—	—
PÄ 6	akzeptiert		Integrationsplan		—	—
KM 2	akzeptiert		HW-Einheit		—	—
KM 2	akzeptiert		Nicht-IT-Anteile		—	—
—	—		System (installierbar)		PÄ 9	vorgelegt
Abwicklung

* Integration

Die geänderten bzw. unverändert gebliebenen Module und Datenbanken sind zur SW-Einheit zu integrieren. Als Zwischenstufen sind Teilstrukturen der SW-Einheit möglich, die sich durch Integration von SW-Modulen, Datenbanken, SW-Komponenten und bereits integrierter Teilstrukturen ergeben.

Die geänderten bzw. unverändert gebliebenen SW-Einheiten sind zusammen mit den HW-Einheiten und evtl. Nicht-IT-Anteilen zum Segment zu integrieren. Die geänderten Segmente sind zusammen mit den unverändert gebliebenen Segmenten zum System zu integrieren.

* Selbstprüfungen

Vom Entwickler sind Selbstprüfungen der Teilstrukturen bzw. der SW-Einheiten, der Segmente und des Systems vorzunehmen.

* Bereitstellung eines installierbaren Systems

Das System ist in einer installierbaren Form (z. B. auf geeigneten Datenträgern wie Disketten, CD-ROM) zur Verfügung zu stellen.

Erläuterung

Hinweise zur Integration der Module und Datenbanken zu SW-Einheiten ist Aktivität SE 7-SW zu entnehmen, zur Integration der SW-Einheiten zum System Aktivität SE 8.


PÄ 8: Änderung der Betriebsinformationen
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 8	Änderung der Betriebsinformationen

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
KM 3	akzeptiert		Betriebsinformationen		PÄ 9	vorgelegt
PÄ 1−PÄ 3, PÄ 5	—		Berichtsdokumente		—	—
Abwicklung

Aufgrund der in den PÄ-Aktivitäten vorgenommenen Änderungen an den fachlichen und technischen Anforderungen und Konzepten sind die Auswirkungen auf die Betriebsinformationen zu bestimmen. Modifikationsvorschläge kommen von den Aktivitäten PÄ 1, PÄ 2, PÄ 3 und PÄ 5 durch Berichtsdokumente ein.

Nachstehende Produkte werden überarbeitet und der Aktivität PÄ 9 "Überleitung in die Nutzung" bereitgestellt:

−	Informationen zum Anwenderhandbuch,

−	Informationen zum Diagnosehandbuch,

−	Informationen zum Betriebshandbuch,

−	Sonstige Einsatzinformationen.


PÄ 9: Überleitung in die Nutzung
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

B	SWPÄ

B.2	Die Aktivitäten des operativen Moduls "Pflege/Änderung"

PÄ 9	Überleitung in die Nutzung

Produktfluß

von					nach
Aktivität	Zustand		Produkt		Aktivität	Zustand
PÄ 8	akzeptiert		Betriebsinformationen		—	—
PÄ 7	akzeptiert		System (installierbar)		—	—
—	—		System (installiert)		Extern (AG)	—
Abwicklung

Diese Aktivität umfaßt Tätigkeiten, die notwendig sind, um das geänderte System an der vorgesehenen Einsatzstelle zu installieren und in Betrieb zu nehmen. Falls mehrere Einsatzstellen vorgesehen sind, ist die Aktivität entsprechend mehrfach einzuplanen und an den verschiedenen Einsatzstellen durchzuführen.

Erläuterung

Weitere Hinweise zur Überleitung in die Nutzung sind Aktivität SE 9 zu entnehmen.


Definitionen (AU250/2 - Anhang)
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

C	Definitionen

Bw-IT-Standards

Bw-IT-Standards sind für den Geschäftsbereich des BMVg festgelegte IT-Standards.

De-facto-Standards

De-facto-Standards sind IT-Standards, denen aufgrund ihrer weiten Verbreitung und Akzeptanz am Markt der Status von Standards zukommt. De-facto-Standards können von einzelnen Herstellern durchgesetzt oder von industriellen Gremien (z. B. OSF, OMG) ausdrücklich im Sinne einer marktorientierten Standardisierung entwickelt sein. Beispiele für De-facto-Standards eines Herstellers sind Windows, Lotus-Notes, für De-facto-Standards industrieller Gremien TCP/IP, CORBA.

Geschäftsbereich des BMVg

Der Geschäftsbereich des BMVg umfaßt das Ministerium und die Bundeswehr (Streitkräfte und Wehrverwaltung).

IT-Ausstattungsvorgaben

IT-Ausstattungsvorgaben spezifizieren IT-Ausstattungen auf der Basis von IT-Planungsvorgaben (funktionale Vorgaben) und Bw-IT-Standards.

IT-Planungsvorgaben

Unter IT-Planungsvorgaben werden eindeutig und systematisiert formulierte Funktionalitäten verstanden, die in einem definierten Umfeld (z. B. Organisationseinheit) in bestimmten Arbeitsabläufen für häufig und gleichermaßen zu vollziehende Tätigkeitskomplexe, Einzel- und elementare Tätigkeiten bei der Lösung bestimmter Aufgaben/Aufgabenklassen benötigt werden.

IT-Normen

Nationale oder internationale Vereinbarungen, die von nationalen oder internationalen Institutionen (zivielen oder militärischen) ausdrücklich als Normen erarbeitet werden. Zivile Normen werden z. B. von ISO, EN, DIN und sonstigen Institutionen, militärische Normen von der NATO oder nationalen militärischen Gremien festgelegt.

IT-Standards

IT-Standards beziehen sich auf Vorgehensweisen, Schnittstellen, Architekturen, Abläufe, Terminologie, Produkte des IT-Gebiets. Bei den IT-Standards wird unterschieden zwischen IT-Normen und De-facto-Standards.


Abkürzungsverzeichnis (AU250/2 - Anhang)
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

D	Verzeichnisse

D.1	Abkürzungsverzeichnis

ASB	Abschlußbericht

AZF-Plan	Arbeitszeit- und Finanzplan

DV	Datenverarbeitung

EBMat	Entwicklung und Beschaffung von Wehrmaterial

EEDV	Entwicklung, Einführung und Nutzung von Datenverarbeitungsvorhaben

GAM-T17	Guerre Air Maritime Technique

GIB	Genehmigung der Inbetriebnahme

GTIB	Genehmigung der Teilinbetriebnahme

KKG	Konfigurationskontrollgruppe

IT	Informationstechnik

IVK	Informationsversorgungskonzept

MoU	Memorandum of Understanding

MTWF	Militärisch-Technisch-Wirtschaftliche Forderung

OTF	Organisatorisch-Technische Forderung

PÄ	Pflege/Änderung

TaK	Taktisches Konzept

TSK	Teilstreitkraft

TTF	Taktisch-Technische Forderung


Abbildungsverzeichnis (AU250/2 - Anhang)
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

D	Verzeichnisse

D.2	Abbildungsverzeichnis

Abbildung 1.1:	Zuordnung von Wehrmaterial und DV-Vorhaben zu AU 220 und AU 250

Abbildung 1.2:	Zusammenhang IT-Leitlinie, AU 220 (Teil III, EEDV) und AU 250

Abbildung 1.3:	Anwendung des V-Modells bei der Vergabe von Einzelaufträgen

Abbildung 2.1:	SE-Aktivitäten und die Phasen des EEDV bei einer inkrementeller Entwicklung

Abbildung 2.2:	Forderungscontrolling

Abbildung 5.1:	Vorgehensweisen bei der Produktfortschreibung


Tabellenverzeichnis (AU250/2 - Anhang)
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

D	Verzeichnisse

D.3	Tabellenverzeichnis

Tabelle 2.1:	Regelzuordnung von Aktivitäten des V-Modells zu den Phasen des AU 220

Tabelle 3.1:	Mindestbedarf an Dokumentation für die Erstellung von Prototypen

Tabelle 4.1:	Gegenüberstellung Anwenderforderungen vs. Systemanforderungen

Tabelle 6.1:	Zuordnung der Phasen und der Stufenentscheidungen/Phasendokumente

Tabelle 7.1:	Baselines gemäß STANAG 4159 und zugehörige Produkte des V-Modells

Tabelle 7.2:	Konfigurationsmanagement-Plan gemäß STANAG 4159 und Entsprechung im V-Modell

Tabelle A.1:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 1 (Regelfall)

Tabelle A.2:	Taktisches Konzept und Produkte des V-Modells

Tabelle A.3:	Aktivitäten und Arbeitsschritte im Phasenvorlauf Wehrmaterial Teil 2 (Regelfall)

Tabelle A.4:	Taktisch-Technische Forderung und Produkte des V-Modells

Tabelle A.5:	Aktivitäten und Arbeitsschritte in der Definitionsphase Wehrmaterial (Regelfall)

Tabelle A.6:	Endgültigen Spezifikationen und Produkte des V-Modells

Tabelle A.7:	Militärisch-Technisch-Wirtschaftliche Forderung und Produkte des V-Modells

Tabelle A.8:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase Wehrmaterial (Regelfall)

Tabelle A.9:	Aktivitäten und Arbeitsschritte im Phasenvorlauf DV-Vorhaben (Regelfall)

Tabelle A.10:	Informationsversorgungskonzept und Produkte des V-Modells

Tabelle A.11:	Organisatorisch-Technische Forderung und Produkte des V-Modells

Tabelle A.12:	Aktivitäten und Arbeitsschritte in der Definitionsphase DV-Vorhaben (Regelfall)

Tabelle A.13:	Realisierungsplan und Produkte des V-Modells

Tabelle A.14:	Aktivitäten und Arbeitsschritte in der Entwicklungsphase DV-Vorhaben (Regelfall)

Tabelle A.15:	Aktivitäten und Arbeitsschritte in der Einführungsphase DV-Vorhaben (Regelfall)


Literaturverzeichnis (AU250/2 - Anhang)
Teil 2	Anhang zu den behördenspezifischen Ergänzungen (AU250/2)

D	Verzeichnisse

D.4	Literaturverzeichnis

/AU 220/	Allgemeiner Umdruck Nr. 220, Bestimmungen für die Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben. September 1994.

/AU 253/	Allgemeiner Umdruck Nr. 253, Zuordnungshandbuch GAM-T17 (V2) − V-Modell. Februar 1997.

/AW SWPÄ-BWB/	Arbeitsweisung zur Softwarepflege/-änderung im Bereich des BWB. BWB FE VI 2-10-02-05. 21.9.1990.

/AWT 591/	Arbeitsweisung Technik 591, Leistungsbeschreibungen. BWB AT I 1, Az. 10-15-91. 26.07.1988.

/EBMat/	Kapitel 5 − 11 des Allgemeinen Umdrucks Nr. 220, Bestimmungen für Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben.

/EEDV/	Kapitel 12 − 17 des Allgemeinen Umdrucks Nr. 220, Bestimmungen für Planung, Entwicklung, Beschaffung, Einführung und Nutzung von Wehrmaterial und Datenverarbeitungsvorhaben.

/IG 1514/	Instruction Générale No 1514, Guide pour la conduite des programmes darmement.
No 1514 MIN/DEF du 7 mai 1988-Edition 2 du 17 janvier 1992.

/IT-Leitlinie/	Leitlinie für Einsatz/Nutzung der Informationstechnik (IT) im Geschäftsbereich des Bundesministers der Verteidigung. BMVg Org 8, Az. 10-01-06. Februar 1992.

/MIL-STD-498/	MIL-STD-498, Software Development and Documentation.
Dezember 1994.

/STANAG 4159/	STANAG 4159 − NATO Materiel Configuration Management Policy and Procedures for Multinational Joint Projects. September 1991.

/VMBl 1989/	Rahmenregelung für die Softwarepflege/-änderung in der Bundeswehr (SWPÄ-Bw). VMBl 1989.