T.2 Projektspezifische Anpassung des V-Modells

  T.2 Project-Specific Adjustments of the V-Model

Inhalt		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 Verknüpfungen mit der V-Modell Mailingliste

T.2 Projektspezifische Anpassung des V-Modells

• 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. standardized pre-tailoring
  2. tailoring with deletion conditions.

  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.

T.2.1 Erstellung des projektspezifischen V-Modells

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 PM4 - 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 3. Ü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. standardized pre-tailoring and
2. tailoring with deletion conditions,

werden im weiteren näher vorgestellt. Voraussetzung für diese Verfahren ist die Berücksichtigung der Mindestanforderungen.

Abbildung T.2: Anwendung des Tailoring

T.2.1.1 Berücksichtigung der Mindestanforderungen

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:

Mindestanforderungen im Submodell SE
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	Anf. 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 SE6.1-SW - SW-Module codieren und/oder SE6.2-SW - Datenbank realisieren sind durchzuführen.
SE 7.3-SW	Zur SW-Einheit integrieren Die Zusammenführung der in Aktivität SE4.1-SW - SW-Architektur entwerfen 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 SE7.3-SW - Zur SW-Einheit integrieren.

Mindestanforderungen in den Submodellen QS, KM und PM
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	PM1.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	PM1.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	PM4 - Feinplanung Die Planung ist im Projektverlauf fortzuschreiben.
PM 8	PM8 - 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.

Hinweis: Die Tailoringverfahren "Standardisiertes Vortailoring" und "Tailoring mit Streichbedingungen", die in den weiteren Abschnitten beschrieben sind, berücksichtigen die o. g. Mindestanforderungen.

T.2.1.2 Standardisiertes Vortailoring

Folgende Vorhabenklassen sind definiert:

• Administrative Vorhaben,
• Technisch-wissenschaftliche Vorhaben,
• Auswahl, Beschaffung und Anpassung von Fertigprodukten.

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.

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 Tailoring-Formblätter)), 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):

1. Es ist eine Kritikalitätsstufung (mit mindestens zwei Stufen) vorgenommen worden.
2. Es werden Datenbanken eingesetzt.
3. Es liegt eine besonders hohe Komplexität der Funktionalität vor.
4. Die Datenstrukturen sind besonders komplex.
5. Die Wartbarkeitsanforderungen sind besonders hoch.

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.

T.2.1.3 Tailoring mit Streichbedingungen

• Bezug auf Aktivität bzw. Produkt (Verweis)
• Streichgrund (Text)

Beispiel: Ausschreibungsrelevante Streichbedingung

SE1.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 3. Übersicht des Projekthandbuchs wird folgendes dokumentiert: SE1.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

SE5.2 - Betriebsmittel- und Zeitbedarf analysieren wurde zu Projektbeginn als prinzipiell sinnvoll eingestuft und in das Kapitel 5. 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 SE5.2-SW für diese SW-Module auszuführen. Um abweichend vom Projekthandbuch auf Aktivität SE5.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 3. Übersicht des Projekthandbuchs wird folgendes dokumentiert: SE5.2 - 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:

1. Wird der Grund zur Streichung einer Aktivität für das Projekt verwendet, so ist er im Kapitel 3. Übersicht des Projekthandbuchs mit "AT" markiert aufzunehmen. Die Aktivität wird im projektspezifischen V-Modell gestrichen.
2. Soll der Grund zur Streichung einer Aktivität während des Projektverlaufes verwendet werden können, so ist er im Kapitel 3. Übersicht des Projekthandbuchs mit "TT" markiert aufzunehmen. Die Aktivität ist in das projektspezifische V-Modell zu übernehmen.
3. Wird der Grund nicht zur Streichung einer Aktivität für das Projekt verwendet, so kann er im Kapitel 3. Ü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 Streichbedingungen 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.

T.2.1.4 Berücksichtigung von Entwicklungsstrategien beim Tailoring

Abbildung T.4: Anwendung der Streichbedingungen

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 PM2 - Vergabe/Beschaffung und SE1.7 - Forderungscontrolling durchführen 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 (KM1.2 - KMeinrichten und KM3 - Änderungsmanagement (Konfigurationssteuerung))

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.

T.2.1.5 Anwendung der Tailoringverfahren

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 Streichbedingungen herangezogen werden.
6. Entwicklungsstrategie festlegen
   Die Entwicklungsstrategie (siehe Handbuch Szenarien) 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 5. 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 3. Ü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 Streichbedingungen 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

T.2.2 Prüfung des projektspezifischen V-Modells

• 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 2. 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 - Erfüllung der IT-Mindestanforderungen des Bundesrechnungshofes durch das V-Modell) veröffentlicht.

  Die Gründe, die zu Verletzung der in Abschnitt T.2.1.1 Berücksichtigung der Mindestanforderungen 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 3. Übersicht des Projekthandbuchs als auch bei der Beschreibung der Produktflüsse und der Abwicklungstexte (falls im Kapitel 5. 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.

T.2.3 Dokumentation des projektspezifischen V-Modells

• Aktivitäten und Produkte.
• Streichbedingungen für das Projekt.

T.2.3.1 Aktivitäten- und Produktbeschreibungen

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

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 SE1 - System-Anforderungsanalyse:

• Streichungen von nicht zutreffenden Teilen der Aktivitätenbeschreibung vorgenommen,
• notwendige sprachliche Anpassungen vorgenommen,
• der Durchführende der Aktivität benannt und,
• 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

T.2.3.2 Aufzeichnung der Streichbedingungen für das Projekt

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	treichgrund 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 3. Übersicht des A HREF="../d-pjman.htm">Projekthandbuchs beschrieben.

Verknüpfungen mit der V-Modell Mailingliste

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

This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks