Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Tailoring  Homepage  
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

    Die Anpassung des generischen V-Modells an das konkrete Projekt erfolgt über nachstehende Schritte: Die genannten Schritte werden unter dem Begriff Ausschreibungsrelevantes Tailoring(1) zusammengefaßt.

    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 5. Projektspezifisches V-Modell des Projekthandbuchs dokumentiert. Die Gründe, die zu dieser Entscheidung führten, werden als Streichbedingungen im Kapitel 3. Ü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 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
    Abbildung T.2: Anwendung des Tailoring

    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:

    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.

    Tabelle T.1: Mindestanforderungen im Submodell SE

    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.

    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.

    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:

    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:

    Diese Vorhabentypen werden in Abschnitt T.3 IT-Vorhabentypen näher charakterisiert und beschrieben.

    Die folgende Abbildung verdeutlicht die Aufteilung:

    Abbildung T.3
    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.
    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 Projekthandbuch 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.

    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:

    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:

    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

    Das V-Modell ermöglicht die Anwendung einer Reihe von alternativen Entwicklungsstrategien (siehe Handbuch Szenarien). 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.

    Abbildung T.4
    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

    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: 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:

    Abbildung T.5
    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
    Abbildung T.6: Darstellung der unterschiedlichen Tailoringverfahren

    T.2.2 Prüfung des projektspezifischen V-Modells

    Die Prüfung des projektspezifischen V-Modells besteht aus mehreren Schritten:

    T.2.3 Dokumentation des projektspezifischen V-Modells

    Es werden zwei Möglichkeiten für die Dokumentation der Aktivitäten und Produkte angeboten: Die nächsten Abschnitte geben Hinweise hierzu.

    T.2.3.1 Aktivitäten- und Produktbeschreibungen

    Es werden zwei Möglichkeiten für die Dokumentation der Aktivitäten und Produkte angeboten: 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 SE1 - System-Anforderungsanalyse:

    Abbildung T.7
    Abbildung T.7: Beispiel einer Aktivitätenanpassung

    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 3. Ü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 treichgrund für das Technische Tailoring
    Aktivität- bzw. Produktname - d. h. es liegt kein Streichgrund vor

    Tabelle T.3: Streichbedingungen AT, TT

    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

    Mail 0628 - Re: Tailoring / Individuelle Anpassungen (628)
    Mail 0260 - Re: Midestanforderungen (260)
    Mail 0256 - Re: Midestanforderungen (256)
    Mail 0251 - Midestanforderungen (251)

    Hinweise:

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

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